Spring theory

A cool feature introduced in Sonic 2 is that if a vertical spring has bit 0 of its subtype set, characters bounce away from it in a 3D twirling animation, rather than the usual bouncing sprite.

This works by enabling "flip mode" on the player object, which temporarily wrests away control over the mapping frame from the animation function, instead forcing the player to perform a full twirl before returning to the walking animation. If the spring in question is a red spring, the player will perform two twirls to account for the longer air time. Springs placed through debug mode will always make the player twirl, except in Marble Garden Zone for some reason.

The bouncing sprite however, is a perfectly normal animation, and a serious contender for the most boring one ever:

byte_12BDB: dc.b  $2F, $8E, $FD,   0

All it does is show the bouncing sprite for 49 frames*, after which it switches over to the walking animation. Incidentally, that's about how long you ascend for when you bounce off a yellow spring. Note that this doesn't account for the longer air time you get from red springs, or having your flight cut short due to a low-hanging ceiling.

It gets worse. If the ceiling is low enough that the player lands back on the spring before the bouncing animation ends, the animation will abruptly end while the player is still rising. This happens because the spring object writes to byte $20 of the player's SST, but not byte $21. Since $20 keeps the same value it already had, no animation change is detected, allowing the original animation to continue.

Once the animation is over and the player is back in their walking sprites, the animation change is once again detected, causing the bouncing animation to resume next time the player lands on the spring.


* The animation was probably meant to be 48 frames long, but the $FD control code doesn't start the new animation immediately, and so the previous sprite gets displayed for an extra frame.