OpenGL 2D Collision Detection
Hey guys!
Basically, for my degree, I need to create a 2D track-based game using openGL and C++, and I was looking for tutorials/information on two collision detection techniques.
1 - Colour Detection. I basically want to read the colour of the surface beneath my car (so either track, or grass) and slow him down if he's on grass, or stop him in front of a wall, etc.
2 - Bounding Boxes. I've found a few tutorials about this, but I was wondering if anybody could throw any more at me =)
There is no reason to look at the colour of the surface, your game already knows which parts of the surface are track or grass, your game is drawing them after all. OpenGL is for graphics, don't use OpenGL for collision detection, just use good old standard C++ logic for that. Have each entity in the game hold an X and Y coordinate, as well as a width and height value, then you have your bounding box, and you can calculate whether or not any of the boxes intersect whenever you update the game state, it nothing but simple arithmetics. If most of your entities have irregular shapes, you might be better off using a bounding sphere (or bounding-circle in the case of 2D)
As for changing the speed of the cars based on the kind of surface they are driving on:
How to solve this really depends on how the tracks/maps are implemented, you could use some kind of tile engine i guess, and then either generate the maps when the game starts, or load them from a file. Then you can use the same approach as above, if the bounding-box (or sphere) of the car, intersects with the bounding box of the tile, set the speed of the car according to the type of the tile (grass, dirt, tarmac etc).
If you plan to have many entities loaded at a time, like, thousands, then you will need to optimize on this, alot. But if you're just planning to run 800x600 with 10 by 10 tiles and a few cars and particles (Which shouldn't be part of the collision checking, needless to say) then the above approach should be just fine.
How I need a drink, alcoholic in nature, after the heavy lectures involving quantum mechanics.
For a simple project such as this I would agree that Axis-Aligned Bounding Boxes (AABB's) and/or bounding spheres should be sufficient for collision detection. For more complex algorithms you might look into swept sphere which is good for contact with triangles within a larger world, Object-Oriented Bounding Boxes (OOBB's) which better encapsulate objects, or separating axis theorem using AABBs or OOBBs.
Collision is usually broken into a few phases. The first is usually the broad phase which is the trivial rejection test - IE: Simple AABB or sphere tests. Once that passes you would normally move to the narrow phase which are the more expensive yet more accurate tests. Some systems uses several more phases to narrow down when they start using the expensive algorithms. Also many make use of spatial trees so as to minimize the input set and thus save time.
