Strategies for collisions with background
Posted: Mon Mar 21, 2016 1:48 pm
I'm trying to figure out a clever way of checking collision between a sprite and background.
It's different from checking if two sprites are collidong : each sprite has a bounding box, I just have to check that they don't overlap.
For the background, I have a 2D array that follows the tilemap of the level. To make it simple let's say they are 1 if the tile is solid, 0 if not.
Let's say the collision array is like that
Each value represents a 16x16 tile.
If the player is at pos (120, 16) and is 10 pixels wide. Does it fall ?
If compute its coordinates in tile units : it goes from 120/16 = 7 to 129/16 = 8. Collision value at position (7, 1) is 0 but at position (8, 1) it's 1 : there's collision and the sprite doesn't fall.
What bothers me is that it's slow : I have to do these calculations for the 4 edges of the bounding box (actually, according to horizontal and vertical movement, only 2 are necessary), for all the sprites. And if the sprite is 32 pixels long, I have twice more values to read.
I was wondering if game developpers from the 8/16bits years had developped some clever technique ?
For example, I was thinking about using a table where free tiles would be associated to values representing the space before the first obstacle in each 4 directions, so that only one value should be read for a given sprite (at the cost of more calculations), I don't know if it's worth implementing.
Or is it better to store the collisions with background using bounding boxes, like for sprites, and using quadtrees ?
I'd be much interested with concrete examples of game that actually implemented such or such methods.
Thanks in advance for sharing your knowledge
It's different from checking if two sprites are collidong : each sprite has a bounding box, I just have to check that they don't overlap.
For the background, I have a 2D array that follows the tilemap of the level. To make it simple let's say they are 1 if the tile is solid, 0 if not.
Let's say the collision array is like that
Code: Select all
0000000000
1100000011
1111111111If the player is at pos (120, 16) and is 10 pixels wide. Does it fall ?
If compute its coordinates in tile units : it goes from 120/16 = 7 to 129/16 = 8. Collision value at position (7, 1) is 0 but at position (8, 1) it's 1 : there's collision and the sprite doesn't fall.
What bothers me is that it's slow : I have to do these calculations for the 4 edges of the bounding box (actually, according to horizontal and vertical movement, only 2 are necessary), for all the sprites. And if the sprite is 32 pixels long, I have twice more values to read.
I was wondering if game developpers from the 8/16bits years had developped some clever technique ?
For example, I was thinking about using a table where free tiles would be associated to values representing the space before the first obstacle in each 4 directions, so that only one value should be read for a given sprite (at the cost of more calculations), I don't know if it's worth implementing.
Or is it better to store the collisions with background using bounding boxes, like for sprites, and using quadtrees ?
I'd be much interested with concrete examples of game that actually implemented such or such methods.
Thanks in advance for sharing your knowledge
