We all know that what makes a Sonic game deserve that title is the physics, not the blue sprite, so I want to code a character that's as fun to control as his MD/GEN counterpart, but the problem is that I don't have the same CPU power as the original games. I don't think this is a reason to be extremely worried about, because the Master System games for example had very different physics but were still enjoyable in their own way (it wasn't frustrating that Sonic didn't move exactly like he did on the 16-bit games, at least not for me).
Recently I've been reading the Sonic Physics Guide, to know the basics about how the 16-bit games work. I found that many of the solutions I had thought of were similar to what was presented in that guide, but there are several details that are hard to figure out without deeper investigation, such as when each type of force is or isn't applied, the exact values of those forces and things like that, so it was a very interesting read.
So after looking at the original physics, my conclusion is that the constant multiplications needed to convert the speed into horizontal and vertical components (and everything else that deals with sines and cosines) are probably the the most CPU-intensive parts. I don't remember if the 68000 has built-in multiplication, but the 6502 (the NES CPU) certainly doesn't, so I'd like to keep multiplications to a minimum.
Anyway, the reason for this thread is asking you guys what kinds of simplifications you think could be done in order to reduce the CPU load while processing the Sonic object, without sacrificing the fun. If anyone knows a bit about how the SMS games work as opposed to the 16-bit ones and wants to share, that would be great. I don't want to copy the 8-bit games exactly though, because I want to do things they don't, like making jumps perpendicular to the floor.
I think I'm going to use the quadrant thing, where different modes (floor, right wall, ceiling, left wall) are used to keep Sonic attached to the "ground" depending on his angle. I'm thinking about not converting the ground speed into horizontal and vertical components though, and just using it directly as fully horizontal or fully vertical, depending on his angle, while the other coordinate just follows the ground. Maybe with careful calibration of the resistance of the slopes it will not feel so different. About the perpendicular jumps, that can possibly be done using look-up tables for each possible angle, since the initial force for the jump should be constant.
If you have any interesting ideas, let me know. Also, if you foresee any problems that these simplifications might generate, that will be nice to read too. Thanks in advance for any suggestions!