Sonic CD Quirks/Deconstruction

A limitation that would need to be overcome is adapting the graphics operation render(s) to Genesis sprites. While the graphics operation arranges the rendered tiles top to bottom, then left to right like sprites do, the maximum sprite size is 4x4 tiles (32x32 pixels). A single metal panel is larger than that, so multiple sprites are needed to build one. The rendered tiles would need to be rearranged to fit with the multiple sprite setup for the most optimal sprite usage. Otherwise, you'd be looking at a lot of 1 tile wide sprites...

 

I also forgot to mention the fact that to use the graphics operation, the ASIC needs to have access to Word RAM and have all the data needed for the transformation (stamps, map, trace table) in it, alongside space for dumping the render into, all in Word RAM.

Normal stages are all loaded into the entirety of Word RAM and run from it, which means that Word RAM absolutely cannot be touched by the CD side. Using Genesis RAM to hold the code and data would be totally unreasonable, especially since the stages themselves use a great deal of Genesis RAM for variables and buffers. The safest bet would be to port Naka's codebase to the Sub CPU and having to transfer things like controller input, graphics (Sonic's sprite graphics would need to be constantly updated, alongside plane, scroll, and sprite data), and FM the sound effect queue between the 2 sides, also using Word RAM and the communication registers. This is actually how the special stages work, albeit implemented in a pretty lackluster and hackish way (gameplay update timing is tied to the stage rendering).

That's a good amount of work required, especially with a team who was clearly pretty new to Sega CD development, using someone else's codebase that they had to learn and port over to the Sega CD at the start of development, under a deadline. At least with the special stages, they were able to just develop their own codebase from scratch and plan it out with the graphics operation in mind. With Naka's code, they probably didn't even want to bother and just get the game out.

 

The Genesis can access PRG-RAM if it has bus access, alongside Word RAM and the other hardware registers. The Sub CPU is the one that handles actually working with the CD hardware, so in mode 1, it's a matter of getting the BIOS and your system program loaded. In mode 1, the cartridge is in its usual place in memory, while the Sega CD's Main CPU side memory is shifted to $400000 (see the /CART pin, which in turn also dictates if a cartridge or the Sega CD's boot ROM is booted). Once that's set up, the Sub CPU is free to do whatever with the CD hardware: access the CD drive, use the PCM chip, use the graphics operation, etc.

I made a quick demo a while ago that shows the graphics operation and PCM chip working in mode 1, and even works on hardware:

 

They don't. In fact, I can't even find the tiles for those in any of the stage MMD files, not even in any prototypes! I did find the mappings data in the Tidal Tempest files (they are in frames 0xAD to 0xB4), but other than that...

I DO see them in the 1996 PC version's sprite data, though! In fact, a quick question: were some of the sprite rips for Sonic CD just done with the PC version and also labelled as from the MCD version, since the PC version is a direct port?

 

Not the first time this has been the case. These sprites have been featured in sprite sheets for a good while now, but don't even exist in the game since 510, and yet, they show up in the PC version. They do exist in v0.02, but these were in sheets before that got released.

 

Made my own rips of Sonic's sprites in the final's regular stages.

Spoiler: Palmtree Panic (Act 1 and 2)

Spoiler: Tidal Tempest

Spoiler: Metallic Madness

Spoiler: All other stages

v0.02 rip

Spoiler

510 rips

Spoiler: Palmtree Panic (Act 1 and 2)

Spoiler: Tidal Tempest

Spoiler: Metallic Madness

Spoiler: All other stages

v0.51 rips

Spoiler: Palmtree Panic (Act 1 and 2)

Spoiler: Tidal Tempest

Spoiler: Metallic Madness

Spoiler: All other stages

712 rips

Spoiler: Palmtree Panic (Act 1 and 2)

Spoiler: Tidal Tempest

Spoiler: Metallic Madness

Spoiler: All other stages

1996 PC version rip

Spoiler

510, 0.51, 712, and the final sprite sets are almost the same as reach other, minus some missing sprites, and also flipped balancing and skidding animations. The Tidal Tempest set are very much based on v0.02's set, with the mappings for the 3D rolling sprites being left over.

 

I haven't seen this documented anywhere, but there's a THIRD unused hanging sprite (on the very left here). The unused hanging sprites are found in Tidal Tempest (which seems to be a hub for these unused sprites in the final, with leftover mappings as far back as v0.02).



In the Wacky Workbench sprite data, all 3 are replaced with the final sprites, even in the 510 prototype, so it's possible that this set is the pre-510 version, before they were redrawn.

Also, funny thing about these sprites. On TCRF and Retro's wiki, they were portrayed as a single sprite, colored blue, and a few sprite sheets I've seen color the second frame white. The game data shows that the first frame is black and white, and the second frame is yellow and black.

 

So, the game features a downward speed cap of 16 when you are in the air, so that it would prevent you from clipping through floors or messing up vertical wrapping if you were to fall for an extended period of time.

However, this only applies when Sonic is in a normal state, where he uses the standard movement+gravity routine to handle falling. However, like in the other Genesis games, in his hurt state, they use a different gravity value than the one hardcoded in the standard function, so they just use the standard non-gravity movement routine and handle apply gravity manually, and they did not put the speed cap there.

In the 510 prototype, in the beginning section of Tidal Tempest Act 2, there used to be enemies, and it's possible to get knocked back by one and glitch the vertical wrapping and die:


The enemies placed in that area were removed, presumably for that reason.

In the final, if you time and position yourself right in Wacky Workbench, you can get knocked back and clip through the floor:

 

I made some hackish modifications to @Lapper and @Mercury's collision overlay for Sonic 1 and got it working in Collision Chaos Act 1 Present:


Wanna mention the pinball flippers. There's actually 2 sets of slope data for them: one for when you're falling/standing, and one for when you're moving upwards, specifically for hitting them from below.


However, it should be worth noting that collision detection is only done at the center of Sonic's feet/head, and does not take into account his full hitbox width. As a result, the collision width of the flippers are effectively shrunken down like so:




Also, bumper hitboxes and Sonic's hitbox are larger in the 2011 remake than in the original version:


Another fun one: the game still retains the code from Sonic 1 that shrinks Sonic's object collision hitbox if he's ducking... except that they forgot to update the sprite frame ID. As a result, it doesn't work as intended, and the hitbox will shrink when an angled walking sprite is displayed.

An addendum to this: turns out this is only an issue if you roll into a monitor from the left side. This is actually because the point where it would activate the solid collision, but not the destruction collision is actually rested up against the side of the monitor. In solid object collision, if that happens and you are left to the object, it's considered a collision. This happen because it checks if the distance from the object on the left is > 0. On the right side, it checks if the distance is >= 0 instead (Sonic 1, on the contrary, checks > 0 for the right side, too).

 

As it is documented, later prototypes of Sonic CD included PCM music data that would bridge the CDDA music loop and make it seem seamless.



Both the v0.51 and 712 prototypes feature this data, but it turns out that v0.51 actually has (unused) code that handles playing them!

Spoiler: The code

What's going on is that, basically, it waits for CDDA music to be playing. Once it does, it stops it and starts playing the PCM loop section. While the PCM music is playing, it waits for the CD drive to be fully stopped. Once it has, it prepares to play the CDDA music by seeking to it via MSCPLAY1, and then pausing as soon as it even starts playing. The PCM music sets a special flag when it's done playing. This routine checks that flag after the CDDA music has been paused, and if it's been set, it unpauses the CDDA music and lets it play, and then the cycle repeats.

However, this routine is bugged. Since it immediately resets the routine cycle after unpausing the CDDA music, it'll activate the check for if CDDA music is playing, and if so, it'll just play the PCM loop section again. The result of this is that the PCM loop section will just play over and over again. Even then, it only plays Palmtree Panic's CDDA music, indicating to me that this routine isn't finished. This code is not referenced by anything and goes totally unused, as far as I know.