Here's a paper BuilderBoy wrote one time (and I hope he doesn't mind my publishing it here):
Collisions (by BuilderBoy):
In most every physics based game, you will need a way to tell when you character runs into something. Whether that entails being able to stand on a platform, stopping when you hit a wall, or falling into a Portal.
First off, it is often better to detect whether or not your next position is a hit, rather than to move your object, see if its hit, and then move it back (although it can make more sense). Collision methods vary highly based on your terrain, and your character design.
Tiled Collision (pixel by pixel)
In Portal, the terrain is made up of tiles and the character is a single tile. To check whether or not the next position will be inside a wall, i go through several steps:
If MovingDown
Check pixels below each bottom corner
Else
Check pixels above each top corner
End
if Either pixel checked is solid
Set Y velocity to 0
End
If the same is done for the x direction, you would get a diagram that looks somthing like this
---------
--*---*--
-*00000*-
--00000--
--00000--
--00000--
-*00000*-
--*---*--
---------
Which shows the pixels you would test for all posible directions. Note that this design fails once velocity is greater than 1 pxl/frame. If you are programing in an enviromnent that doesnt permit you the luxury of such fine movement, some modifications will have to be made:
If MovingDown
Check pixels on bottom corners
Else
Check pixels on top corners
End
While Either pixel is solid
Move character in increments of 1 in the oposite direction of velocity
End
---------
---------
--*000*--
--00000--
--00000--
--00000--
--*000*--
---------
---------
Instead of checking to see if the next position is solid, and preventing the character from ever going there, this method uses a different aproach. Move the character always, and if they are inside an object, move the character in the oposite direction until they are no longer inside the wall. It works for high velocities, but can make other physics difficult in certain scenarios (I don't use this method in Portal because the physics involving Portals would get a lot more complicated, with time fragments and such...)
Rough Terrain:
With rough terrain, it adds a level of difficulty in any game. Especialy because it often also needs another level of physics to calculate the rebound angle or somthing (elastics will be covered in the next section). The principles behind collision is very much the same however. If you want to be simple, set the collision points of your character to the 4 corners of its bounding box, and have it behave just like a tile. The collsion methods from the previous section should work well assuming you have an accurate way to test pixels of the screen. If you can make sure pxlTest will not accidentaly detect your own pixels, or that the character doesnt destroy its own terrain, pxlTest is a very very fast way to test solidity in Basic games. You can also write your own pxlTesting roughtine if you are using tilemaps and matrixes, and would look somthing like this:
*pxl to be tested x,y
*assuming tiles of 8x8 starting
[A](iPart(x/8)+1,iPart(y/8)+1
And if you are using Axe, since all data is in a list, more somthing like this:
*Assuming map width of 12
{L1+(x/8)+(y/8*12)}
*which simplifies to
{y*12+x/8+L1} (i belive, axe optimisations are not my strong suit)
If your character is not a tile, collision become a little more time consuming, but not exceedingly more difficult. Originaly, we were only testing 2 pixels per direction, but if we had a 8x8 sphere, we might want to up that to 6pxls per direction. SOmthing like this
------------
------------
-----OO-----
---OOOOOO---
---OOOOOO---
--OOOOOOOO--
--OOOOOOOO--
--*OOOOOO*-- 1
---OOOOOO--- Not a surface because there is no ledge for the sphere to rest on
---*-OO-*--- 2
-----**----- 3
------------
The genral rule is that you would need 2 pxlTests for every level of pixels your character could stand on. Since the original character was a box, there was only 1 surface, the bottom, and we tested both sides. But on this sphere, we have 1 2 3 surfaces on any given side
Hope that helps. Also, there are a few concepts you need to be familliar with to understand some of the posts in the thread, such as multiple buffers, simple physics and tilemapping, all three of which have their respective tutorials in the Tutorial page. I wrote the buffer one, BuilderBoy wrote the physics ones, and Yunhua98 wrote the tilemapping one, so yeah. Good luck!
