3 ms·

I think the most interesting part of the guide was that the 'physics' engine is _very pseudo physics- I would not have imagined that to handle running on walls

I think the most interesting part of the guide was that the 'physics' engine is _very pseudo physics- I would not have imagined that to handle running on walls or ceilings would involve switching the logic to disjoint modes (four quadrants approach) and moving the base sensors to accommodate the mode. In fact, I wouldn't imagine that the physics logic would require all the sensors that it does to get the feel of the game right. I can only imagine how much tweaking had to be done for all the values to play nicely and be enjoyable- perhaps a less heuristic-based implementation doesn't offer as much control or was too process intensive? Also a surprise to see that angle values were stored directly at grid pixel locations.

Mahn 11y ago
It's certainly true that the CPU (a Motorola 68k clocked at ~7.60 MHz) didn't leave much space for process intensive operations; one misstep in your code and the entire game would lag and slowdown. Developers of Sega Genesis games were in fact discouraged of using DIV (division) instructions because they took so many cycles. Fortunately most games could do with bit shifts, IIRC the Sonic games almost never used DIV instructions and did fine.
- pcwalton 11y ago
  Most programs even today don't do many integer divisions (which is why ARM doesn't even support them, for example). Compilers are really good at eliminating them.