I am just wonder... I have tilebased movement with keyboard right now with no animations and the movment is jurky. From recent posts in here I''d figure I''d try out 3d tilebased engine and although it works find with collision the movement is sooo ugly. It looks like the 3d character is just skipping around becuase I just have the player''s location equal the center position of the tile. Does anyone know how to make smooth transitions from tile to tile. I am not looking for if up arrow is press then the postion is +.01 becuase then i would either need to make more tiles for collision or just get rid of tilebased collsion altogether.... And thats something I dont want todo becuase it works sooo perfectly, just check if next tile is walkable (without worring about complex 3d prograaming for coliision)

there is no need to give up the tile based collision method, it just requires the use of a transition animated sequence(which can still be based on the center of a tile, just offset to give the illusion of movement) and having moving objects occupy both the tile they are coming from as well as the tile they are going to until their move has completed.

Also search for AABB collision tests (axis-aligned bounding boxes). Very easy to test if theres an overlap (just 4 if tests) and you already have all the data present with your tiles, all you''ll need to add is a width for the moving object (which is probably the same size as a tile at the moment).

I''m working on a tile-based game now, and I have a problem for simply checking for overlap.

If a block is sliding along a surface and reaches a corner that allows the block to move beyond, that last little bit of corner might be ignored in the collision. This is because checking for overlap as collision detection might not detect the block colliding with that last bit of corner.

This might allow the player to cut corners to get ahead of pursuers.

So I try to predict collisions and force the block to take calculated slides along surfaces until I know it has reached the corner, and then I check again for the intended movement possibility.

I don''t know if this is overkill. But it is resulting in its own set of problems. Particularly, truncation failing to detect a perfect corner-corner collision.

The leap-frogging problem you describe is pretty common, to fix it you need to use swept collision volumes.

If you imagine being a point at A, then moving to point B, your swept volume becomes a line joining A to B. Extending that to swept circles or boxes is slightly tricky since it gives odd shapes.

One method that can be good is to make a swept line for every corner of the box, and test those against the edges of the tiles. This is more work (and line-line testing is a bit more work) but it does give a nice robust collision detection.

try jump''n''run dev #1 - tilebased collision detection and response


http://jnrdev.weed-crew.net/jnrdev1

main site: http://jnrdev.weed-crew.net

I''ve been working in 2D, and I''ve been enhancing the same tile collision algorithm since about 1993 (although I haven''t touched it much in the past 2 years). It''s probably the most confusing piece of code in the Scrolling Game Development Kit, but if you like, you can see what I did . The source is downloadable. Visit the home site at http://gamedev.sf.net/. It handles sloped hills and ceilings. It also allows sprites moving at any speed to slip into a passageway exactly 1 tile tall (same height as the player). But it can only do this horizontally -- it''s hard to slip into a vertical passage 1 tile wide because of decisions that had to be made when the sprite approaches a corner at an exact diagonal. Had to choose whether to have a preference to slide horizontally or vertically. You wouldn''t think that collision detection would become the most difficult or complicated aspect of a game, but when you try to do it perfectly and correctly, I guess it often does.

"All you need to do to learn circular logic is learn circular logic"

i''ll take a look at your code if i have time.

i''m always open to better techniques for jnrdev.