## Re: [AL] Tile Collision Detection

 Re: [AL] Tile Collision Detection From: Todd A. Zircher - 1998-03-02 22:26:06 ```Chris Frolik wrote: > > The tiles are 32 x 32 pixels... Everything is working well except > for collisions between the tank and the tiles... I'm having problems > with this, however. Sometimes the tank gets stuck in a wall, and the > collisions aren't very accurate (the tank sometimes bounces back > prematurely or too late). One technique to look into is backwards plotting the tank to the 'point of impact', and placing it there with it's new (reserve) vector. Given a northwest moving tank that intersects a wall tile/tank: *-----* *-----* | | | | A | tile| B | tile| | *-----* | | *--|--* | *-----* | tank| *-----* | | | | *-----* | tank| | | *-----* Place it back at the point of impact with a southwest vector for the next frame. While this can cure tanks inside of walls, it also creates an interesting 'scuffing' effect when a tank appears to decelerate before bouncing off the wall. -- TAZ ```

 Re: [AL] Tile Collision Detection From: Joshua Heyer - 1998-03-02 07:04:21 ```---Chris Frolik wrote: > > In my 2D top down game, I currently have 3 basic types of tiles. Blank > tiles, wall tiles, and bouncy wall tiles. Wall tiles are 80% elastic > (players bounce off with 80 percent of their original velocity, in a new > direction), and bouncy wall tiles are 200% elastic (players bounce off with > twice their original velocity). The player's sprite is a tank, which is > about a 20 x 20 square. The tiles are 32 x 32 pixels. The tank can be > rotated using the left and right keys, and thrust is applied using the > up/down keys (The tank is considered to be a "hovercraft", so if you apply > thrust in one direction, the tank will continue to move in that direction > until it hits a wall). Everything is working well except for collisions > between the tank and the tiles. To test for this, I decided to test 8 > points on the tank (the 4 corners and the midpoint of each side). If the > tile at one these points is a wall, then the tank's x or y velocity is > reversed (negated). I'm having problems with this, however. Sometimes the > tank gets stuck in a wall, and the collisions aren't very accurate (the tank > sometimes bounces back prematurely or too late). > > If anyone has a suggestion as to how I should do this (or even better, some > example code) I would appreciate the help. > > Thanks, > > --Chris Frolik > frolikcc@... > If the maps are just a grid of 32x32 tiles, you should be able to determine whether or not a point is colliding with a tile easily enough; just divide the pixel coords for the tank by 32 (shift right 4). Check the tile, if it's a wall tile use the tank coords mod 4 to get the offset into the tile & check the tank against the tile there. The tank shouldn't get stuck, but if you have problems, try this: Each time around, check for a collision after you add the movement vector to the position & take whatever action is appropriate. Each time around, check for a collision also BEFORE you add the movement vector. If there is a collision then, you can skip the collision detection afterwards, assuming that whatever was supposed to be done to the tank has already been done. So unless you're managing to move the tank more than one tile at a time without checking for collisions, every thing should come out right. This sounds good anyway, I'm really not too sure about it right now ;). -- Joshua Heyer _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com ```
 Re: [AL] Tile Collision Detection From: Nick Kochakian - 1998-03-02 13:00:34 ```> In my 2D top down game, I currently have 3 basic types of tiles. Blank > tiles, wall tiles, and bouncy wall tiles. Wall tiles are 80% elastic > (players bounce off with 80 percent of their original velocity, in a new > direction), and bouncy wall tiles are 200% elastic (players bounce off with > twice their original velocity). The player's sprite is a tank, which is > about a 20 x 20 square. The tiles are 32 x 32 pixels. The tank can be > rotated using the left and right keys, and thrust is applied using the > up/down keys (The tank is considered to be a "hovercraft", so if you apply > thrust in one direction, the tank will continue to move in that direction > until it hits a wall). Everything is working well except for collisions > between the tank and the tiles. To test for this, I decided to test 8 > points on the tank (the 4 corners and the midpoint of each side). If the > tile at one these points is a wall, then the tank's x or y velocity is > reversed (negated). I'm having problems with this, however. Sometimes the > tank gets stuck in a wall, and the collisions aren't very accurate (the tank > sometimes bounces back prematurely or too late). > > If anyone has a suggestion as to how I should do this (or even better, some > example code) I would appreciate the help. > > Thanks, > > --Chris Frolik > frolikcc@... > Here's something that'll help you: IF o1.x(fir) < 8 + o2x(i) AND o1.x(fir) > 0 + o2x(i) AND o1.y(fir) < 8 + o2y(i) AND o1.y(fir) > 0 + o2y(i) THEN o1 is object one o2 is object two hope this helps! nickk@... http://dn3.home.ml.org ```
 Re: [AL] Tile Collision Detection From: Todd A. Zircher - 1998-03-02 22:26:06 ```Chris Frolik wrote: > > The tiles are 32 x 32 pixels... Everything is working well except > for collisions between the tank and the tiles... I'm having problems > with this, however. Sometimes the tank gets stuck in a wall, and the > collisions aren't very accurate (the tank sometimes bounces back > prematurely or too late). One technique to look into is backwards plotting the tank to the 'point of impact', and placing it there with it's new (reserve) vector. Given a northwest moving tank that intersects a wall tile/tank: *-----* *-----* | | | | A | tile| B | tile| | *-----* | | *--|--* | *-----* | tank| *-----* | | | | *-----* | tank| | | *-----* Place it back at the point of impact with a southwest vector for the next frame. While this can cure tanks inside of walls, it also creates an interesting 'scuffing' effect when a tank appears to decelerate before bouncing off the wall. -- TAZ ```