|Posted: 20áSeptemberá2004 at 09:55 | IP Logged
I suggest you to make an 21x21 array to check the kind of tile (walkable, one way, water...). That makes the 11x11 grid plus the "half tile" positions.
When loading each screen, you fill in that array with the proper values. The things that move/can be moved (green blocks, enemys, etc...) become sprites, and the things that don't move (bricks, water, bridges, etc...) become part of the scenery.
To check collision detection (when moving), you simply check against the first array (the 21x21). Of course, you'll have a double maintenance. By example, each time Lolo moves a green block, the array changes; each time Lolo builds a bridge, the array changes, etc... But that shouldn't slow things too much.
To check sprite collision (fire & player, enemy & player, enemy & shot, and so on...) you'll probably have to check every sprite with every other sprite (that shouldn't be too slow, there are just a few sprites involved).
I used this method in a "sort-of" remake of Rick Dangerous: I had a linked list with all the interactive objects of the game. One pointer goes across the list; for each node, another pointer goes across the list until the end. If there is an overlap, check which kind of sprites (items, enemies, player, etc...) are colliding and resolve the situation. That way, no collision is checked twice.
I can send you source code if you are interested (it's very well documented, as it was "kind-of" homework; but all documentation is in Spanish).
Apologies about my english! I hope that helps! :)