This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - AaroneusTheGreat
Pages: 1 ... 5 6 [7] 8 9 ... 20
91
« on: May 14, 2010, 01:50:49 am »
DOA has seen a pretty good bit of progress lately, I've added two new levels, three new enemies, you can now get some items from the wall in the mini game (not completely done), the mini game now has a point system for each kill, and stage based enemy spawning, meaning it spawns more enemies each time it lets out a new wave, and has pauses between waves so that the player can buy ammo and weapons.
I still need it to cost points for the items you get from the walls in the mini game, so that it's got a bit more interest than just shooting everything in sight and getting whatever weapon you want. Also I need to add an item for the ammo for the revolving gun, as it is you can use that weapon, but there is no ammo to pick up, so it's useless after you run out of ammo.
I plan on adding a new weapon to the game, probably something that shoots projectiles you can see, I'm thinking something like an energy cannon.
The enemies I added are evil soldiers, and evil scientists, and a really tall robot thingy with guns. I'll post a screenshot when I get a chance. Basically before the soldiers and scientists were on your side, now some of them aren't. I plan on having a transition in the storyline explaining this later.
I'll keep you updated when I get more done.
92
« on: May 13, 2010, 12:00:32 am »
Bwang, I figured it might effect the speed of the engine if you had to use overdraw (the only way I know of to make transparent wall textures) because of the need to continue looping after a wall intersection. But thanks for trying anyways, it's cool that you're listening to my suggestions, as off base as they might be sometimes.
93
« on: May 11, 2010, 11:56:58 pm »
I've always wondered if there was a way you could have a sub class of sprites in a ray caster that didn't stay perpendicular to the camera, who's orientation would be set, and therefore would be stretched according to perspective like a wall. This would come in handy because it would be flat and have transparency, allowing for objects like a chain link fence or iron bars blocking a path. Would this be easy to do? I only know the very basics of ray casting, and only in the context of a fixed angle ray caster.
94
« on: May 07, 2010, 11:28:54 am »
render() takes the width and height of the screen as two of its parameters. Are you also able to set where on the screen buffer the viewing area is rendered? Also if you make a structure out of your parameters for the rendering engine, it could speed up the engine a bit, because you'd be actually passing one void pointer to the function, like so: typedef struct
{
int screen_width,
int screen_height,
//pointer to sprite array, however that's defined//
// same for texture array//
int screen_position_x,
int screen_position_y
// etc//
}
render_structure;
render_structure rend_struct;
render(rend_struct);
This way when you pass rend_struct, C actually sees rend_struct as a pointer to a place in memory, and you're actually only passing one void pointer through the stack, which if I'm not mistaken is only one char.
95
« on: May 06, 2010, 02:34:50 pm »
I really like the way you've handled that, it makes it much easier to use the same screen buffer to put stats and such on the screen as well as the rendered scene. If you want to I could try to help you optimize the code to make it faster. Also are you going to keep the variable viewing screen size in the finished program? If you are, the client code could adjust the viewing area to meet it's own processing needs. That way, games with more complicated AI and such would be able to make up for the processing time for that by decreasing the screen size. It would make your engine extremely flexible.
96
« on: May 01, 2010, 04:47:23 am »
wow stunning work. I can't believe what this thing is capable of! 
97
« on: April 29, 2010, 12:37:51 am »
Wow this has to be the most impressive raycasting I've seen on a calculator yet. Good work Bwang. I can't wait for this project to be released. It could be the reason I end up buying an nSpire.
98
« on: April 24, 2010, 12:39:55 am »
Haha I made a typo when posting, I meant to say multidirectional.  I had the same problem as kev, also some old dos games simply won't run on windows XP because of a change in the way XP's dos handling handles certain math functions. I had an old raycasting game called Iron Assault, and it wouldn't run or anything unless you configured XP's dos emu with a special setting, or used dosbox. Bwang, good luck with your studies, that always comes first. No matter how epic a project you may be working on for a calc.
99
« on: April 23, 2010, 02:51:58 pm »
In the original doom, if you were aiming in the direction of an enemy on a higher platform, you would shoot at that enemy. It may be different on the wii port, but on the original pc game that's how it was IIRC.
Bwang, how is it going with the multidimensional sprites?
100
« on: April 23, 2010, 03:41:24 am »
I'm not so sure that the effect of walls at different heights would be lost if you can't look up and down, the original doom featured this but didn't have the ability to look up and down.
101
« on: April 19, 2010, 01:16:41 am »
I'm not really sure why that would work, but if it does I guess roll with it. You said it "kind of works" what do you mean by kind of?
102
« on: April 18, 2010, 12:27:33 pm »
I may have found the issue, I don't know for sure though.
in this section of code,
for (y = sfstart; y <= sfend; y++) {
setPixelBuf(scrbuf, x, y, 8);
//very large value since sprites always cover floors
zbuf[x][y] = 1000;
if (res == 2 && x < w - 1) {
setPixelBuf(scrbuf, x + 1, y, 8);
zbuf[x + 1][y] = 1000;
}
}
you are testing if the "res" variable is equal to 2 after you assign a value to "zbuf", which is addressed with the var "x" which is incremented by res, so potentially, if you're incrementing by two, you could possibly step out of the bounds of the array, maybe if you restructure it like so:
for (y = sfstart; y <= sfend; y++) {
//very large value since sprites always cover floors
if (res == 2 && x < w - 1) {
// i did it this way because it appears that you're wanting it to set the z buffer and the pixelbuf thingy at both x and x+1 on res == 2
setPixelBuf(scrbuf, x , y, 8);
zbuf[x][y] = 1000;
setPixelBuf(scrbuf, x + 1, y, 8);
zbuf[x + 1][y] = 1000;
}
else if (res == 1 && x < w) // it only seems to be either or, but I decided to use an else if in case it wasn't
{
setPixelBuf(scrbuf, x , y, 8);
zbuf[x][y] = 1000;
}
}
You do something similar here:
for (y = swstart; y <= swend; y++) {
int color = tex[(int) texY][texX];
if (side == 1) color = color / 2;
setPixelBuf(scrbuf, x, y, color);
//set the zbuffer
zbuf[x][y] = perpWallDist;
if (res == 2 && x < w - 1) {
setPixelBuf(scrbuf, x + 1, y, color);
zbuf[x + 1][y] = perpWallDist;
}
texY += texD;
}
I would change it in the same manner as the one above:
for (y = swstart; y <= swend; y++) {
int color = tex[(int) texY][texX];
if (side == 1) color = color / 2;
//set the zbuffer and the pixel buffer
if (res == 2 && x < w - 1) {
// same as above, I assumed that you wanted to set both x and x+1 in the pixelbuffer thingy and the zbuffer.
setPixelBuf(scrbuf, x, y, color);
zbuf[x][y] = perpWallDist;
setPixelBuf(scrbuf, x + 1, y, color);
zbuf[x + 1][y] = perpWallDist;
}
else if (res == 1 && x < w)
{
setPixelBuf(scrbuf, x, y, color);
zbuf[x][y] = perpWallDist;
}
texY += texD;
}
Seeing as you're only adjusting the variable "zbuf" at two points in your code, I think these two places are going to be where the problem lies.
hope this helps.
103
« on: April 18, 2010, 12:14:35 am »
bwang, any time you write data to floats, if you write integer type values like
float var;
var = 1;
then the compiler could possibly see 1 as an integer and tries to treat "var" as such.
try something like this instead
float var;
var = 1.0;
C can be very frustrating in that regard.
I really didn't see anything else that stuck out to me why it would only happen when you changed datatypes though.
Also, I had great difficulty following parts of your code at first, it would really help me if you went through and commented sections of your code describing what each chunk is supposed to accomplish, so that I may be able to spot whats going on.
Good job so far with what you're doing. If you want me to look at anything else then please let me know. You can pm me with code snippets and general questions and such. Good luck.
104
« on: April 14, 2010, 09:14:45 pm »
I'm not sure I'd call that trivial, good work! 
105
« on: April 14, 2010, 05:30:32 pm »
Here's a screenshot of the new menu. Also it shows a bit of the minigame behavior. What you see is the basic functionality, buying weapons and such comes later.  There are a few restarts, because I was testing the menu system while making the screenshot, but you get the idea.
Pages: 1 ... 5 6 [7] 8 9 ... 20
|
Show Posts