Sonic CD Quirks/Deconstruction

@Clownacy I went ahead and reposted the ring sound bug and sound priority bug explanations on my Sonic CD Deconstructed account, and provided additional examples to help explain them. I should note that the "stop all sounds" command is played every time it exits an MMD file, not just when leaving the time warp cutscene.



As an addendum, they also forgot to assign sound effect 0xDF (drowning) a priority value.

 

3D ramp/loop

I made a video about how a 3D ramp/loop works in Palmtree Panic Act 1 Present:


Additional notes:

• Gravity is only disabled if Sonic is going fast enough (at least 8 upwards). If he slows down, then gravity is enabled, which is why when you let go of the jump button, he starts falling.
• He will also only be boosted forwards if he's moving fast enough.

Metal Sonic projector sprite cropping

The Metal Sonic projector's sprites have the 1st row of pixels cropped out in the 1996 PC version:


This actually extends to the 2011 remake a little, where a couple sprites have that cropping issue, but others are just fine:

 

Explosions and flowers are flipped depending on the direction of the badnik in the original version of Sonic CD.



This is because the way the explosion and flower are spawned are by sequentially changing their object ID and resetting their routine ID back to the initialization one. However, during re-initialization, it fails to reset the flip flags, and that's why it does that.





Usually, using OR to combine bits with previously set ones are used by stage objects placed in the stage layout to retain settings set by the layout data. They probably just copied that line without much thought into the explosion and flower objects.

This does not happen in the 2011 remake.

 

Here are some videos of the final boss with hitboxes visible in the original Sega CD version and the RSDK version; the hitboxes are quite different.

 

There are some invisible blocks placed in Metallic Madness.


They don't exist in the 2011 remake.

 

I would like to make a correction, as these are incorrect, actually. The track structure address is actually incremented before calling the update function, and on top of that, each song adds in a dummy slot for the removed rhythm channel, so things are actually kept aligned properly. My apologies!

 

So, I've been learning how to use After Effects, and I came up with this demonstration on how the Sega CD is used to render a special stage.



This example demonstrates how the Sega CD renders a special stage. The way scaling and rotation works on the Sega CD is that it uses a table of values to dictate how to scan a source image. For each row in the rendered image, it takes an entry from the table. Each table entry consists of a starting coordinate and delta values. It plots the scanner at the starting coordinate, and for each pixel in the rendered row, it moves the scanner by the amount set in the delta values. In this specific example, the first 3 rows are effectively nulled out due to rendering errors caused by the fact that it's rendering so far away for those rows (although, the 4th row is also erroneous, although it doesn't seem like it was noticeable enough for the developers).

 

Another After Effects test, this time a 2D visualization of the Special Stage 6 demo

 

Here's an extra tidbit with this

The past is also affected by this:


And, of course, if we look back at 510, we have a match:

 

The points chaining system in the 2011 remake of Sonic CD is bugged. This is due to the fact that the chain doesn't get updated until a points object disappears, causing an inconsistent points chain if you rack them up too quickly.



This is the code responsible for it. Object[26] is what keeps track of the chain. As you can see, it doesn't get updated until the points object has despawned, causing the issue shown above.



The way the chain gets reset if the player lands on the ground or on top of an object is also weird. When a points object despawns, the chain counter is set to a "gravity" value depending if the player is grounded or not, and then checks if it changed in the next frame.



For instance, if you start a chain by hitting a badnik, landing on the ground and jumping before the points despawns, and then hitting another enemy after it despawns, the chain will continue. Here, a spring was added to easily demonstrate this.



It also creates inaccurate behavior where, unlike the original Sega CD version (by extension, Sonic 1), you cannot continue a chain if you roll into an enemy and then jump into another.



For reference, here's the original's behavior.

 

There is a bug where a Tamabboh's missiles will despawn if it flies past a block with solidity.



This is due to an oversight where it checks for floor collision (aka, it checks for collision with a block downwards) even if it's moving upwards. When it moves high enough past a block with solidity for the downwards check to register as touching the floor, it despawns.



The first bit just checks if the missile is on screen, and if not, despawn it. Then comes the floor collision check without an additional check to see if it's moving downwards.

Here is a visualization of this. Notice how the left missile despawns once the bottom of its collision sensor touches the block with solidity.

 

The 2011 remake doesn't accurately handle ring bonus chaining when hitting multiple ring UFOs in a row. That's because the remake merely just doubles the ring count for each subsequent rings UFO that is destroyed.



In the original, it uses a separate counter for the chain bonus, which is initialized as 20, and doubles for each subsequent rings UFO, which is then added to the ring counter.





Here is a demonstration.

 

If you have an astute eye, you can see that the drowning countdown numbers are actually bubbles that come out of Sonic's mouth. (Yes this is in all the Genesis titles, but it's also in CD, so...)



Also, the colors are a bit messed up here in Sonic CD for when the number forms. The reason for this is because they are using the wrong palette line. The number itself uses line 1 for the yellows, but it seems they got a bit lazy and also made the bubble formation use it as well, when they were designed for line 0, using Sonic's blues.



The reason why this is because in prototypes, the fully formed number graphic weren't yellow like in Sonic 1, but rather also appeared like a bubble, so it used line 0. When the numbers went back to being yellow, they went back to line 1, but took the formation with it.



The code changes between v0.51 and the final are highlighted here. When the number gets spawned, its palette line is set from the start, and also changed the initialization code to OR the tile ID instead of directly setting it so that the palette line change can go into effect.





Interesting thing to note is that these graphics appear to stem from a later prototype of Sonic 1. The numbers originally being bubbles makes the whole thing with them coming out of Sonic's mouth make more sense.



The 2011 remake mostly fixes this, but the lightest shade of blue was accidentally left as the regular one instead of the underwater one, so it appears more purple instead of baby blue.

 

If your Backup RAM (used for storing save data) data is corrupted, in English, it will display this error message, implying that "Robotonic" messed with it.



In Japanese, it's the same message, but "Robotonic" is referred to as Eggman instead.



The other error messages aren't as amusing. I will note that the game will only be playable in the event that the Backup RAM is full. The other errors just freeze at the message.



(The same messages in Japanese, plus a bonus alternate message in the European version)

 

Hey, did you know that checkpoints don't exist or even function at all in the past or future time zones? In fact, the game even has code that forces Sonic to spawn at the beginning of the stage if you're not in the present when he dies.



Here's a bonus fun fact. In Palmtree Panic act 1, in the present, the checkpoint object is set to ID 0x13, but in the other time zones, they are set to ID 0x2B. The checkpoints in the present for that stage wouldn't have even shown up for the other time zones because of this!

 

The reason the sprite is messed up is because another object's graphics overwrite it in VRAM. However, this is not the case in act 3. However, due to a bug, this object in the 510 prototype uses the wrong tile ID for the sprite.

This is the bugged code in question, where it checks the zone ID instead of the act ID:


Here it is fixed: