I am trying to build a Sonic physics engine, and the problem of how to implement collision has left me a bit stumped. I first thought about doing it like the classic games and using height arrays and per-tile angles, but calculating the angles turned out to be complicated. So now I'm thinking about using a simple bitmap (probably will be a PNG with two colors) for collision, and calculating the height by scanning the pixels along the ground sensor lines from the Physics Guide, and then calculating angles with atan2 or something like that. (and still doing the quadrant-switching that the SPG describes) My question is: what problems could this method cause? Is there a better way to do this that I'm missing?
One way to do it would be to make individual collision masks for every 128*128(256*256) tile ,which would be just a monochrome bitmaps. The angle can be calculated determining the height of the 16 pixels surrounding the point you want to calculate the angle for, averaging both sides and applying atan2. This is the way it is done in S3HD tech demo. If the physics there are not perfect that is not the method's fault but the engine being incomplete and the masks drawn by hand. The other one(recommended) is to do it like in the original with 16*16 collision masks. Depending on how you do the collision distance and angle calculation(hint:in a separate function and not hardcoded) you can make a prototype with the big masks method and then just change a couple of things to make the other version work. Also you don't have to worry about performance, both work just fine on low end CPUs, even with realtime angle calculations.
It really depends on a bunch of factors. For instance, if you're using Game Maker, you have no control over the format of the resources, so bitmaps could use a lot of memory.
