So here's sonic "behind the scenes", this visually shows how sonic works, these are debug modes I built into the engine as I developed it because without it, doing stuff like this is utterly impossible.
Right at the start of the video there's a little pause while I try to remember what keys were what, but I start turning stuff on and off and you can see that as I do it.
Sonic has 2 "layers", the background which shows the mountains, water and clouds, the megadrive has support for 2 tile map layers so that's a physical limitation of the hardware. The foreground layer is more capable than the background layer.
In addition to the layer, the megadrive hardware has a set of registers that allow you to scroll the tile map, you can scroll the whole thing left, right, up and down or you can scroll individual lines. There's a weirdness between the western releases and Japanese releases, I implemented the clouds as they appear in the Japanese release, they scroll in 3 layers, the western release all clouds scroll together.
as the background progresses down, there's a couple of "bands" for the mountains and then the water scrolls on a line by line basis. The speed at which all these elements scroll is very carefully set in the original game and it was an utter c**t to replicate properly, but the result is that it produces an incredibly cool depth to the game and it literally comes for free as the hardware manages it.
The water (and waterfalls) shimmer, this is a trick that was common on old consoles where all the graphics use an indexed palette, there are a whole load of technical limitations because for a tile or sprite you use one row of the palette which means that you're limited to 15 colours + transparent, but different sprites can use different palettes so you can get quite colourful on screen.
Again, the water shimmering was a complete c**t to replicate, when I started the game I used SDL and all it actually does is draw sprites, but, that was a mistake because trying to replicate the line by line scrolling and the palette cycling is incredibly difficult to do at speed even on a modern computer, I had to disable hardware acceleration in SDL because it (quite rightly) wanted to use OpenGL/DirectX to draw the sprites on screen, which means they're in VRAM for fast drawing but it's very slow to update VRAM sprites on the fly, the result is if you run this with hardware acceleration on, the frame rate drops to 1 FPS, yes, the megadrive can beat a modern computer with a modern GPU.
I won't make that mistake again, next time I will create my own graphics engine with frame buffer, meaning I can do whatever operations I need to do by directly manipulating pixels, I can do that incredibly quickly on the PC and then I'll simply tell SDL to draw my buffer as one big sprite.
The palette cycling trick is also how the SEGA animation is done, believe it or not there's just a single image that doesn't change, the palette is cycling to create the light effect and then make it solid.
Back to the game....
So with the foreground and background layers off, I turn on the solid debug. The level is simply an array that contains tile indices, each tile has a corresponding graphic tile (i.e what you see) and an index to a "solid". Anywhere where there is terrain, there's a solid tile, so here you can see sprites and tiles only, sonic has "sensors" that are used to determine if he's hit something or whether he's standing on ground or not. He has 2 feet sensors that point down, they're positioned slightly to the left and right of centre (not to the extents of the sprites, even in the original game you can see this when standing near objects, the purple rock in GHZ is an example where he appears over the edges, they use a 3D effect to make it look like the rock has depth, it's incredibly subtle and very deliberate.
His ground sensors are always firing regardless of what he's doing, they ensure he stands on top of the ground and they make it possible for him to fall when he's not on solid ground.
There's a left and right sensor that are only active when he's moving in that direction, so that he stops when he hits a wall.
The solid information is very simple, it just contains enough information to describe the shape of the solidity of a tile, you can see this on screen when I switch stuff on and off, this solidity basically mirrors the graphic visually, so with just solids on you can see his world as how he interacts with it.
What you also see in this is that lots of stuff in the game isn't part of the tile map, anywhere you see a colourful graphic, that's a sprite. The megadrive has a load of limitations on sprites, you have a maximum of 80 per screen and that's further complicated by the fact that for any given scan line you can only display 8 sprites, if you try to draw more than that, then any sprites after the 8 will not be draw for that scan line.
This quirk is used on the title screen to make sonic appear above and below the banner, they purposefully put blank sprites on the screen to allow that to happen, it's real out of the box thinking. It's also used in the water levels to create a flickering effect.
It also causes visual errors on screen although they're hard to see, but if there are quite a lot of sprites on screen and sonic loses his rings, parts of rings won't be drawn as there are too many sprites per scan line, in reality you don't notice it, if you captured the screen though you would see this in action.
So things like the rope bridge and the collapsing ledges are not part of the tile map, they're drawn as sprites and each sprite object manages collisions with sonic, for objects and enemies the collision works the other way around, it's not sonic hitting an object (like it's sonic hitting the terrain), it's actually the object hitting sonic which makes sense for enemies, but it's less obvious for things like the collapsing terrain or bridges where logically you would think it's sonic that would be hitting the bridge.
this is necessary because each object has a different way in which it interacts with sonic, so the collision is done in reverse and when he does collide with something the object moves sonic or in the case of an object tells sonic he's standing on something, when sonic is standing on an object his ground sensors are inactive, it's the responsibility of the object to determine when he's not standing on it anymore and to reactivate his ground sensors so that he falls.
The different colours of solids determine how the solidity affects sonic, a red block is solid only from the top, meaning that if a red block is above sonic he can jump up and he will only collide with it when he's heading towards the ground, so this enables him to jump up and only platforms. Blue blocks are solid from all directions, meaning if he hits one from any direction he'll be stopped in his tracks.
One of the cleverest parts of the game is that sonic has 360 degrees of freedom, unlike Mario, sonic can run up walls. This is achieved with a really neat trick that basically comes for free...
He doesn't have 360 degrees of freedom! He lives in a very one dimensional world, but, the trick is that when he's on terrain that is >45, then they simply swap the sensors, his ground sensors instead of pointing down, now point right and it uses the wall collision instead of ground collision, this continues to change as he goes though all degrees, and this is what allows him to traverse the loops.
The loops are another neat trick because they need to be solid all the way around to allow him to enter, traverse and exit the loop, but if they're fully solid then he wouldn't be able to enter and exit, so the game uses a trick where it duplicates the entire level map but that particular section is diffeerent depending on which side of the loop he is, you can see when he runs around the loop as he passes the top the level map changes and the exit of the loop becomes avaialble, run the other way and the same thing happens.
There's a lot of information on how sonic works as people reverse engineered it, but this was not a trivial task getting to this point, things like the platforms are not described anywhere and I literally sat there for days trawling through the disassembly of the ROM figuring out how bits worked, but this has been an incredibly interesting and rewarding project, I've spent 30 years wondering just how they pulled this game off and even now I'm in awe of just what they did, and when I say they, I mean Yugi Naka, he wrote it all on his own without much corporate interest, SEGA didn't particularly care for what he was doing (and SEGA America were baffled by it and really had zero interest in it).
Miyamota (who's a designer and not a coder) is a well known name, but I bet nobody here had ever heard of Yugi Naka until I mentioned him, Miyamota hasn't got s**t on Naka.
I am tempted to start a thread on the Frogger project now! 
