Is there a source code for Sonic's tile collision?

[psycopathicteen]

I know Sonic-Retro has a long article explaining of how the tile collision works in the Sonic. I'm still curious at the exact implementation of it. Is the code for doing collision really long and complicated, or did they use tricks to simplify it, such as a few basic routines that were repeatedly used?

[segaloco]

Your best bet is checking out disassemblies. There are some pretty good long-standing community disassemblies of various Sonic titles, community in that at some point they passed into provision of Sonic Retro themselves and have gotten numerous touchups and analysis from various folks. Something I hope to eventually do with my own stuff.

Anywho, Sonic 1 is probably the simplest to start with: https://github.com/sonicretro/s1disasm

My brief recollection (haven't touched Sonic engine stuff in years) is that alongside visual background tile memory, there is a similar "tile" system for collision maps, with larger collision chunks being made up of smaller primitives. Collision between objects I couldn't say, usually games have some sort of bounding box incursion calculation but when you get into "correcting" a collision, things get a lot more variable, you've got a matter of things like nudge priorities (which thing "gives" when they overlap), where in code to record a collision vs act on it. By comparison, NES stuff I've looked at tends to include the logic of responding to a collision *as* a function of the collision routine running, rather than recording that collision for some dedicated handler to iterate over later. In other words, the collision routine with an enemy runs the damage routine on a player, rather than simply telling the player hey you collided with actor <xyz> or filling up a collision queue and letting the things colliding decide what that means to them later. Efficiency considered though it makes sense.

I know the SonED tool had a collision editor of some kind, that's where I'm remembering the particulars from. There's some more recent tool, SonLVL, that seems to be pretty popular, it probably also has collision management for backgrounds and could illuminate some of the finer points.

[tokumaru]

As much as I love the 16-bit Sonic games, I'm not sure that they're particularly good references for collision logic. Since the very first game, there have been some weird aspects (such as when walking off the ledge of a rising slope and the pointy ground pierces Sonic's foot between the two floor sensors), and by Sonic 3, after all updates made to the engine, it wasn't uncommon for characters to go through walls and get stuck when moving really fast - this was common enough that Sega warned players about this in the game's manual, claiming that these were traps set up by Robotnik.

I don't think Sonic does anything special regarding collisions, they apparently use the straightforward approach of giving each block a height map (16 values indicating the height of each column of pixels), and using sensor lines extending from objects at specific points to read these maps. Sonic's magic IMO is in the 360 degree physics, where walls and ceilings can behave like the floor depending on objects' angles and speeds.

[segaloco]

I don't think Sonic does anything special regarding collisions, they apparently use the straightforward approach of giving each block a height map (16 values indicating the height of each column of pixels), and using sensor lines extending from objects at specific points to read these maps. Sonic's magic IMO is in the 360 degree physics, where walls and ceilings can behave like the floor depending on objects' angles and speeds.

This is what I've heard as well, that the real secret sauce in Sonic is the trig driven smooth arc calculations, momentum overcoming gravity, I recall reading an interview where either Yuji Naka or an associate implied the development of these smooth arc calculations are largely responsible for the development of the engine gaining traction.

[psycopathicteen]

From experimenting with different collision approaches, I came to the realization that even though Sonic's approach with 2 slope detectors is good for curvy ground, it's not so good for zigzag shaped ground.

[tokumaru]

Yes, if you have pointy ground tiles, the highest point will slip between the two sensors and the object will sink lower than it should.

For pixel-perfect collision, you may have to check all pixel columns between the two sensors and use the highest one to calculate the vertical position of the object.

[segaloco]

Well and in reality too zigzaggy of a collision surface sounds like the surface might benefit from smoothing. Since the goal is just to keep an object positioned relative to a surface, a surface calling for a more variable collision definition is probably variable in nature itself. Take for instance the grassy surface of * Hill Zone levels. The grass tends to be spiky, sure, to replicate the pattern of blades and clumps, but the collision doesn't need to actually replicate this intimate level of "jaggedness", indeed you are recreating the ground surface *below* the grass, which is much less likely to be jagged. I actually can't think of too many scenarios where you'd have a height map that looks like say a sawtooth wave or something like that, that would be very annoying to calculate and if the space between peaks is small enough, the net result is no different than having a line instead, the colliding entity doesn't really have any chance of slipping down into those cracks, you're just complicating the processing at that point.

[Dwedit]

Sonic 2's Emerald Hill Zone Act 2 has these strange little ramps, you don't get launched off them, you need to jump yourself. Not intuitive at all, but having the forward and upward momentum does indeed somehow allow you to get a slight vertical boost to make it onto a difficult platform.