Tile Engine

You need to keep the sprite x, y somewhere. Then, you can get the tile coordinates by x/tile_width, y/tile_height but he will be offset by x%tile_width, y%tile_height. Your character won''t always be on only a single tile, he may overlap multiple tiles.

If you try to take the map x, y and convert it to sprite x, y then your character will only move one tile at a time. Instead of the method above, you can also store his map x, y and his offset: how far he is from a corner of the tile or something.

I had a similar problem in my first tile-engine exploits. When I first began playing with them, I used an 2D array to hold the tile ID''s, and the player moved a whole tile at a time, but this was way unusable, so I had him move 1/10th of a tile each move, this was great, but killed the relationship between the player''s x,y and the tile collision routines.

I solved this by using the method Forneiq suggests,
(e.g. PlayerTileX = Player.XPixel/TileWidth)
in combination with another routine that used % to test whether the player was over halfway across a tile, which the collision test would then use 1 +(Player.XPixel/TileWidth) to test for collisions.

Damn, that killed my brain when I came up with it.

Waassaap!!

I''ve had great success with tile engines and collision detection. What I do is that I have the sprites''s x and y position in the tilemap''s world space. That is to say that if a tilemap is 100 tiles by 50 tiles, and each tile is 16 x 16 pixels in actual size, then the world would be 1600 by 800 pixels in size. I would then determine which tile in my 2D array (I actually use a 1D array, but that''s besides the point) my sprite was colliding with by dividing the sprite''s x and y coordinates by 16 (I shifted to the right by 4, it''s faster.)

Another important fact in collision is the order in which you move your character and check for collision. In the last couple of system''s I''ve written, I''ve advanced my sprite it''s velocity while checking for collision.

I would basically do the following
xPos += xVel;
if(TileMap[yPos >> 4][xPos >> 4] == COLLIDABLE_TILE)
if(xVel > 0) xPos = (int)xPos & ~0x0F; // basically (xPos - xPos % 16)
else if(xVel < 0) xPos = ((int)xPos & ~0x0F) + 16; // on other side of tile.

Basically, if you''ve wondered into a tile, your velocity determines which side of the tile you end up on. So if you are moving to the right, you can only end up on the left side of a tile. The coordinate of that tile would be your xPos - (xPos % 16)

The same goes for the y direction.

This system allows you to move sprites around as freely as super mario. If you wanna see this system in action, check out the following demo I wrote at:

http://home.att.net/~nitrosr/gamedemo/gamedemo.zip

It''s got some timing problems, so it may or may not come out choppy depending on what your vsync settings are at. The graphics are ripped using a SNES emulator, and the actual board is designed by my little brother. He''s real good, so good luck surviving this thing.

left,right - run
down - duck (you MUST use the duck to finish the board
space - jump

Daniel "NitroSR" Piron

Your demo doesn''t work for me NitroSR. I just get loads of gibberish at the top of my screen (I can make out some feet walking though).

When I took a screenshot with HyperSnap DX though, it was completly fine - so it''s probably my dodgy graphics card.

Oh well, guess I''ll have to knock something up with your equations to try them out.


Waassaap!!

Sorry to hear the demo is bein'' bitchy on you. I am using the 320 x 240 resolution which is apparently being abandoned by video card makers because it looks absolutely terrible on anything bigger than a 14" monitor with 11" view space, and no one is using it anymore. But due to my source graphics I needed to use this resolution. It''s my fault for not including a 640 x 480 version which just doubles the size of the graphics, I could still probably do this.


Has anyone else had this problem?