[akOOma]

Here's my collision detection routine (collision between NPCs and nonwalkable tiles). It doesn't work. But I can't see the problem. So, could anyone show me at least the bug in that function??

[Bjorn]

I'd say you might be looking for collisions in places without map data when checking this "!map_data[npc1.x_pos + nx][npc1.y_pos + ny]". Might it be that?

[akOOma]

Just for info:

if map_data[x][y] is true => walkable
if map_data[x][y] is false => not walkable

With this for loop I test all 8 fields arround the npc which he could collide

@Bjørn: No, that ain't the bug. Even when the npc is in the center of the map, this routine doesn't work.
_________________
Keep on codin'
-----------------

-----------------
Just another post to increase my rank...

[Rooter]

wait so is a 1 returned if their is a collision or if there isnt?

x1 = sprite_x_wide * npc1.x_pos + npc1.x_pix;
y1 = sprite_y_wide * npc1.y_pos + npc1.y_pix;
x2 = sprite_x_wide * (npc1.x_pos + nx);
y2 = sprite_y_wide * (npc1.y_pos + ny);

if (!((x1 > x2 + sprite_x_wide) || (x2 > x1 + npc_sprite_x_wide)))
if (!((y1 > y2 + sprite_y_wide) || (y2 > y1 + npc_sprite_y_wide)))
return 1;

what exactly is the point of this code? as far as i can tell you are testing the sprite against itself... why? that code just looks odd, heh.

[Rainer Deyke]

Let me see if I understand this correctly.

npc1.x_pos is the position of the npc in tile coordinates.
npc1.x_pix is the position of the npc in pixel coordinates relative to npc1.x_pix.
sprite_x_wide is the width of a tile in pixels.
npc_sprite_x_wide is the width of an npc in pixels.
x1 is the calculated position of the top-left corner of the npc in pixel coordinates.
x2 is the calculated position of the top-left corner of the tile in pixel coordinates.

You just want to check if a collision occured.
npc1.x_pix is in the range from -sprite_x_wide to +sprite_x_wide.

Assuming all of this is true:

1. You should use return type 'bool', not 'short'. Minor style issue.
2. You should check if npc1.x_pos + nx and npc1.y_pos + ny are in range before checking !map_data[npc1.x_pos + nx][npc1.y_pos + ny]. Safety issue - not doing so may result in an access violation if the npc is at the edge of a map.
3. You should use >= instead of > in the checks at the bottom of the code. Otherwise an npcs will be unable to squeeze between two tiles if the width of the npc is the same as the tile size.

I can't find any other problems with this code (other than the overall design, which I decline to comment on). Could you be more specific about how this code fails? Could the bug be somewhere else?

[Happy]

See, you still use tile coordinates because you're still using a map [array]. Why should you change the way you do map collisions?

[Rainer Deyke]

[Happy]

[Bjorn]

In our engine, we also calculate the tile where the player would be going and then check if he can go to that tile. That's a tile*tile engine though.

In the original code, a bounding box is checked against a 3x3 tile block around the npc (or at least I think that's what it means to do). It's not a big loop and I wouldn't call it bad design so quickly. It does assume that the bounding box will be smaller than 3x3 tiles, I think.

A hibrid solution would be to take the direction of the npc and calculate the new part of its bounding box. This would be a thin line at the side, or two on diagonal movement. Then, for each tile within that area, check if it's an obstacle. The efficiency would be lineary dependable on the size of the bounding box.

[DrunkenCoder]

My guess is that the logic if flawed. Im guessing that what you want todo is to check if the sprite overlaps the nonwalkable tile.

That should look something like (insted of the nested ifs):

[akOOma]