Ludus, on 14 May 2013 - 17:09, said:
Anthony Serrano, on 14 May 2013 - 12:45, said:
In the case of Sonic, for example, normal movement includes loops, corkscrews, and similar objects wherein Sonic is running vertically or upside-down, and which therefore do not work well without some form of conditional gravity.
I believe that in the 2D Sonic games all of the weird terrain such as loops and corkscrews were done through the use of scripted events (Sonic's speed would have been calculated at the beginning of the loop to determine where he should fall off the loop if he wasn't going fast enough. Gravity would have no effect during these scripted events, of course) - so there was no advanced collision detection that needed to be done. So despite popular belief, Sonic was much like every other platformer of the time.
Your belief would be incorrect.
Loops, at least, are handled by the standard movement code that allows Sonic to walk along arbitrarily-sloped surfaces; tile metadata in Sonic includes the surface slope, so while sonic is in motion, the game checks the slope of the tile he's standing, and depending on the value changes which direction it looks for ground tiles in (either below Sonic, above him, to his left, or to his right). This is why the Sonic engine can support loops that aren't perfect circles, loops with arbitrary angles of approach and exit, and round objects that Sonic runs along the outside of.
However, if Sonic's run speed drops below a specific value, he is no longer considered to be "on the ground" (and the ground direction is reset to look beneath Sonic), and gravity is applied to him.
Similarly, for the corkscrews in Sonic 2 Emerald Hill Zone, which aren't scripted, but are instead special-cased versions of the normal movement code that override the normal "on the ground"-state positioning code to convert Sonic's run speed into position updates in unconventional ways. When Sonic enters one while in the "on the ground" state, he will continue moving forward, and his animation frame and position will be updated based on his current run speed. If his run speed drops below the threshold, however, he will fall right off, no matter where on the corkscrew he is, because the corkscrew doesn't collide with "in the air" Sonic - which is also why you can't jump onto a corkscrew. The coding for the vertical corkscrews in Sonic 3 operate along similar principles, though rather more complex.
You probably just assumed they're scripted because you've never tried to manually decelerate Sonic while moving on such an object, which let me assure you actually does work in-game.