Sonic CD Quirks/Deconstruction

Brainulator · Dec 22, 2022

I wonder what this would look like if the code were referenced and in a more complete/functional state.

Lurker · Dec 22, 2022

Brainulator said:

I wonder what this would look like if the code were referenced and in a more complete/functional state.
Click to expand...

Someone on Twitter made a reconstruction:
https://twitter.com/SCDDeconstruct/status/1605553041268056065?s=20&t=FagNGfJUFyY31BEZrVwoVw

Devon · Dec 22, 2022

That someone is me, by the way; I run that account. I forgot to crosspost the video here lol

Brainulator · Dec 23, 2022

I feel a bit of a delay in between seeking out the PCM versus CD-DA data, but for what it's worth, that actually sounds pretty nice, awkward cutting off aside.

Devon · Dec 26, 2022

The 1996 PC version of Sonic CD adds additional code in the floor collision function that fixes a slight visual and physics bug for when you're on a flat surface, but the left sensor is detecting a block with a steep enough angle.

I will use Sonic 1 as a quick example to illustrate my point, as that is what's most convenient at this moment. Here, I have placed these 2 blocks next to each other. The left block has a flat surface after the sloped part.

Under normal circumstances, when both sensors are on a flat surface, it'll use the angle from the left sensor. In this case, if Sonic's left sensor is on that left block, his angle will be set to the angle of that slope.

With the fix in place, Sonic can walk on that flat bit on the left block just fine.

This fix is NOT present in the Sega CD version of the game.

Here's the bug in action with Lapper and Mercury's overlay script running. Look at Sonic's left floor sensor as it approaches the surface of the left block.

By the way, I ported the fix to 68000 assembly. In the floor mode, place this between where the sensors are checked (after the 2 calls to FindFloor) and the call to the function that picks a sensor to use ("bsr.w Sonic_Angle" in Sonic 1):

Code (Text):

cmpi.b #-1,(a4) ; Is the left sensor's angle set to snap to a flat surface?

beq.s .NoFix ; If so, branch

move.w d0,d2 ; Are we on a completely flat surface?

or.w d1,d2

bne.s .NoFix ; If not, branch

cmpi.b #-$10,(a4) ; Is the left sensor's angle set to a steep enough angle?

bge.s .NoFix ; If it's not steep enough, branch

cmpi.b #-$40,(a4)

blt.s .NoFix ; If it's too steep/out of range, branch

st (a4) ; Force left sensor's angle to snap to a flat surface

.NoFix:

Bobblen · Dec 26, 2022

I'm fascinated by the fact that the 96 pc port is basically a rev 02. Most of the pc ports I've looked at barely go to the trouble of feature parity!

Devon · Dec 26, 2022

Continuing the topic of collision detection changes, the Sega CD version of Sonic CD adds additional code that fixes a bug when Sonic is standing on top of a column with a negative height (starts from the top and points downwards).

In this example, Sonic is standing on top of a block that's solid in the top half, so each column in the block has a negative height. The block's angle is also set to 0x80, which would normally make Sonic go upside down when he touches it.

Without this fix, Sonic would react like this when colliding with that log.

None of the other Genesis titles fix this bug.

Blue Spikeball · Dec 26, 2022

Funny how they fixed details like those, yet missed more obvious bugs introduced by the port like special stage palette issues.

Devon · Dec 26, 2022

Let's talk about level map data. The original Sega CD version allocates double the memory for map data from Sonic 1, and thus allows for levels to be double the height... kinda, not really actually...

The collision detection takes advantage of this, bar Tidal Tempest, which is set to the original limitations due to level wrapping.

...except that the drawing functions don't, and still retain the original limits.

The map data itself also does not go beyond the original limitations, either. There is not a single stage that is taller than 0x800 pixels.

As a side note, when calculating the X position index for getting map data, it limits it down to 0-0x7F, which is not correct, because each row in the map data is actually 2 64 chunk wide rows interlaced with each other, with the first for plane A, and the second for plane B. The limit should be 0x3F.

Now, let's discuss how the 1996 PC version handles getting map data for collision. It's a bit of a doozy.

A few things were added. Such as preventing the position from going negative in Palmtree Panic Act 1 and Metallic Madness. There's also what appears to be a first attempt to port over the original m68k code that's bugged, and is made redundant by what's next.

The original AND masks are used for calculating the position indices, but are effectively overridden. The PC version doesn't not actually have the double allocated map memory and sticks to the Sonic 1 limitations. What was originally a Tidal Tempest only limitation is effectively put into use in all levels with the "iYwork &= 7" line, and it also fixes the horizontal out of bounds issue by adding "iWork &= 0x3F".

Finally, it... does the negative position check again for Palmtree Panic Act 1, which is completely redundant considering that the calculated indices won't even be negative.

Devon · Dec 27, 2022

I probably mentioned this elsewhere and forgot, but I found this darkly amusing. According to the Gems Collection symbols, the official names of the functions that removes animals and enemies according to the type of future are "friend_suicide" and "enemy_suicide" respectively, and they are found in a file called "SUICIDE.C".

Of course, I understand that these were written by Japanese developers, and they most likely didn't understand the implications, but holy shit, lol. This is basically Sonic CD's "Genocide City" moment in a way.

Speaking of which, when a badnik is removed when a good future is achieved, they're supposed to play the explosion sound effect if they were on screen. However, the check for if they're on screen is called AFTER they are destroyed, so the on screen flag is cleared, and the sound is never played.

As a side note, the PC/Gems Collection version of Sonic CD moves the A+B+C button check for when your paused to restart the level outside of the pause check, which would make it possible to press A+B+C to restart the level even when not paused...

However, the PC and GameCube versions only allocate 1 button for jumping, and the PS2 version only allocates A to the cross button and B to the rest of the face buttons, so it's not possible to trigger anyways.

The music pause function in the PC version is also bugged. It uses an incorrect operator when checking if the flag is already set, and also gets the check for if the invincibility or speed shoes music is playing in the past backwards, as "sub_sync(0x90)" is for pausing PCM music.

The only reason why music pausing even works is because the pause handler manually calls "CDPause()" itself. "sub_sync" doesn't even handle command IDs 0x90 and 0xD5 in the port!

The music unpause function has the first check correct, but the invincibility/speed shoes music check when in the past is still wrong.

And again, IDs 0x91 and 0xD6 aren't even handled in sub_sync, so this is all redundant anyways.

Clownacy · Dec 28, 2022

Ring Sound Bug
Here's a relevant cross-post of an old bug explanation of mine:

Every time the player collects a ring, the game plays the ring sound on a different speaker, alternating between left and right. Sonic CD's SFX sound driver does this in a boneheaded way. The way that it's done in Sonic 1/2/3 is that there are two separate ring sounds, and the driver decides which one is played when a ring is collected. Both versions of the ring sound are different: playing on a different speaker (of course), running on a different FM channel, and even having slightly different durations (except for in Sonic 3).

If the two sounds were to use the same FM channel, then you would only ever be able to hear one of them at a time. This means that if you were to grab two rings in quick succession, then instead of hearing the ring sound coming from both speakers, you'd only hear it in one.

This is what Sonic CD screws up, but the reason behind it is the real dumb part:

Instead of the driver alternating between the two ring sounds, Sonic CD makes the sounds themselves do it: whenever a ring is collected, the game always tries to play the ring sound that uses the rightmost speaker, and this sound then uses a custom command which I've named 'smpsDoRing':

Code (Text):

; FM4 Data

RingR_FM4:

smpsDoRing

smpsSetvoice $00

smpsPan panRight, $00

dc.b nE5, $05, nG5, $05, nC6, $1B

smpsStop

What this command does is force the game to start playing the left ring sound every other time it is used. This has the effect of making the left ring sound play every other time a ring sound plays.

This should work, right? Nope, it doesn't.

Because every attempt to play the ring sound will first cause the right ring sound to play, the developers needed to make the left ring sound stop the right ring sound from playing, so that playing the left ring sound doesn't cause the right ring sound to play too. To do this, they made both ring sounds play on the same FM channel. This causes the two sounds to always cancel-out each other when they play, making it impossible to hear both speakers play the ring sound when collecting two rings at once.

This issue is at its worst when the player quickly collects a line of rings, as each ring sound will be abruptly cut-off by the next one, meaning that the only ring sound that the player will get to hear finish is the last one. This can be heard as early as the very start of the first level of the game. In Sonic 1/2/3, this is not the case: the left ring sound can only be cut-off by the left ring sound, and the right ring sound can only be cut-off by the right ring sound, meaning that ring sounds only get cut off every two rings that the player collects, not one.

Sound Priority Bug
Sonic CD's sound driver has a second bug: SMPS has a sound priority system, which prevents lower-priority sounds from interrupting higher-priority sounds. This is useful, for example, for preventing the ring-pickup sound from stopping and interrupting the much-louder ring-loss sound. The way this is done is with a big array, where each value in the array belongs to a certain sound ID. So, for instance, sound 0x90 would get the first value in the array, 0x91 would get the second value, etc. The problem is that Sonic CD only has enough entries in this table for sound IDs 0x90 through to 0xDF, despite using a higher sound ID for the 'stop all sounds' command. This means that, when the game uses the 'stop all sounds' command, the driver will read a nonsensical priority value from past the end of the priority array. If the nonsensical priority value is lower than the value priority of the sound that is currently playing, then the stop-all-sounds command will not take effect.

This might sound like a non-issue: what are the chances of this having a noticeable effect? When does the game even submit a stop-all-sounds command anyway?

During time travel - that's when. And of course this bug happens to be an important part of it.

Yes, you read that right: the time travel scene depends on this bug in order to work properly. As the screen fades to white, the game submits a stop-all-sounds command, but because the time travel sound's priority is higher than the command's broken priority, it doesn't actually do anything. If this bug were to be fixed, then the time travel sound would abruptly cut-off long before it normally ends.

I discovered both of these bugs while making my replacement Sonic CD SFX sound driver. It's based on Sonic & Knuckles' driver, which lacks this bug, causing the time travel sound to end early. Replacing this bug exactly as it is in Sonic CD's driver does not work, as the nonsensical priority data after the end of the priority array is actually the start of sound 0x90's track data (the skidding sound). Because the data of a sound varies from driver to driver, this bug simply cannot be accurately recreated in a different driver by making the priority table too short.

So how did I eventually recreate this bug in my replacement driver? I copied the raw data of sound 0x90 from the original driver and added it to the end of my driver's priority table. I essentially turned a part of sound 0x90 into priority data. With this, the behaviour caused by the bug is retained without the actual bug existing.

If you're wondering why I was creating a replacement for Sonic CD's SFX sound driver, it was so I could restore the original jump sound. You can read more about it here.

rata · Dec 29, 2022

Of all the flaws Sonic CD has, I must be the only one that prefers its jump sound. I find it less ear piercing that the squarewave one.

Clownacy · Dec 29, 2022

rata said:

Of all the flaws Sonic CD has, I must be the only one that prefers its jump sound. I find it less ear piercing that the squarewave one.
Click to expand...

You're not: I've been getting YouTube comments that say the same for years.

Devon · Dec 29, 2022

@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 the drowning sound (0xDF) a priority value.

Team Andromeda · Dec 29, 2022

Its funny untill now, I never noticed it had sound bugs. Still for me the best 2D sonic game ever LOL

Devon · Jan 1, 2023

And now, why it's not good practice to copy and paste functions across files...

Introducing, "block_chk". This function is part of feature where you can place a 16x16 block wherever in a level. It's used in Collision Chaos to erase glass bumper blocks (they're not objects, they're embedded into the stage chunks), and also was used by the prototype waterfall and earthquake effects. This function specifically checks if the position the block is to be placed at is on screen. If it isn't, then the drawing isn't performed, just the data setting.

When they ported over the function initially, it seems they accidentally implemented the comparisons incorrectly. This can be seen in R11A, for example, where it's not used:

For Collision Chaos, though, they did fix the comparisons. Otherwise, the glass bumpers wouldn't have functioned correctly, after all. But, now there's this situation where the function is broken in certain stages, and fixed in others.

Devon · Jan 25, 2023

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:

Unreferenced bridge object in the v0.02 Prototype

So, in the v0.02 prototype of Sonic CD, object ID 0x25 just points to a blank object. However, there is leftover code that was assigned to that ID. By adding the pointer back in, it can be seen that object 0x25 was a log bridge! The graphics for it were already found, and in fact, are also loaded into VRAM. The mappings were also referenced in the debug mode object list. If you restore the bridge pointer and re-enable debug mode, you can place bridges.

Interesting thing to note is that bridges were actually placed in the level earlier in the development, but got dummied out, with a row of those invisible platforms being put in its place.

Also, if you set its subtype value to be nonzero, it does this:

SyntaxTsu · Jan 25, 2023

Devon said:

Interesting thing to note is that bridges were actually placed in the level earlier in the development, but got dummied out, with a row of those invisible platforms being put in its place.

Also, if you set its subtype value to be nonzero, it does this:

Click to expand...

This reminds me of how the bridges in AIZ and HCZ are coded to break; would be cool to see this restored and recoded fully!

JayKuriN · Jan 26, 2023

Devon said:

So, in the v0.02 prototype of Sonic CD, object ID 0x25 just points to a blank object. However, there is leftover code that was assigned to that ID. By adding the pointer back in, it can be seen that object 0x25 was a log bridge!
Click to expand...

I don't quite recall how far I got on my personal disassembly of R11B from 0.02, It was subpar for the time since this was over a year ago by this point, late 2021. What I do remember specifically, is a fuckton of unreferenced pieces of object code (or seeming like such). I might go through and look through it again. I also remember specifically that object ID 06 was weird, so was ID 0C. I don't know if the time zone matters so I'll assume it does not for now, but pattern I did notice was that most of them seemed to check a value before jumping to execution. If you do know what this is, could you explain?

Devon · Jan 27, 2023

JayKuriN said:

I also remember specifically that object ID 06 was weird, so was ID 0C.
Click to expand...

Object 06 is just a test badnik object (it's called "test_act" in the source code, according to the Gems Collection symbols). It can still be found in the final.

Object 0C is a completely erased object that was called "exit2_set", which is related to those splashes that appear when you exit through tunnel that has water on top. My best guess is that it would've triggered a splash on collision (the unused earthquake object had the player collide with an object called "jisin_set", which spawned another object called "jisin" that actually performed the crumbling). However, instead, they opted to have a door that makes the splash instead if it's set to do so. All the code for "exit2_set" has been erased, but its pointer was kept in, so it just points to whatever is after it, a.k.a. the tunnel door collision check routine, and they kept it like that all the way to the final version.

JayKuriN said:

What I do remember specifically, is a fuckton of unreferenced pieces of object code (or seeming like such)
Click to expand...

That may have all been the bridge object. The code for it is *massive*. It has 17 routines! Otherwise, with R11B, I have not found anything that's not in R11A.

I will bring to light these 2 small objects that I also found in R11A that are also unreferenced, but they don't really do much of anything.

Code (Text):

UnkObject1:

moveq #0,d0

move.b oRoutine(a0),d0

move.w .Index(pc,d0.w),d0

jmp .Index(pc,d0.w)

; ---------------------------------------------------------------------------

.Index:

dc.w UnkObject1_Init-.Index

dc.w UnkObject1_Main-.Index

; ---------------------------------------------------------------------------

UnkObject1_Init:

addq.b #2,oRoutine(a0)

move.l #MapSpr_UnkObject1,oMap(a0)

move.b #4,oSprFlags(a0)

move.b #1,oPriority(a0)

move.b #$10,oWidth(a0)

move.w #$400,oTile(a0)

move.w #$C00,oTile(a0)

move.w #$1400,oTile(a0)

move.w #$24FC,oTile(a0)

move.l (objPlayerSlot.oX).w,d0

addi.l #$A0000,d0

move.l d0,oX(a0)

move.l (objPlayerSlot.oY).w,d0

subi.l #$320000,d0

move.l d0,oY(a0)

rts

; ---------------------------------------------------------------------------

UnkObject1_Main:

move.l (objPlayerSlot.oX).w,d0

addi.l #$A0000,d0

move.l d0,oX(a0)

move.l (objPlayerSlot.oY).w,d0

subi.l #$320000,d0

move.l d0,oY(a0)

move.b #0,oAnim(a0)

lea (Ani_UnkObject1).l,a1

jsr AnimateObject

jmp DrawObject

rts

; ---------------------------------------------------------------------------

...

; ---------------------------------------------------------------------------

Ani_UnkObject1:

dc.w .Ani0-Ani_UnkObject1

dc.w .Ani1-Ani_UnkObject1

dc.w .Ani2-Ani_UnkObject1

.Ani0:

dc.b $1D, 0, 1, $FF

.Ani1:

dc.b 0, 0, $FF

even

.Ani2:

dc.b 0, 1, $FF

even

; ---------------------------------------------------------------------------

MapSpr_UnkObject1:

dc.w .Spr0-MapSpr_UnkObject1

dc.w .Spr1-MapSpr_UnkObject1

.Spr0:

dc.b 1

dc.b $F8, 5, 0, 0, $F8

.Spr1:

dc.b 1

dc.b $F8, 5, 0, 4, $F8

Code (Text):

UnkObject2:

moveq #0,d0

move.b oRoutine(a0),d0

move.w .Index(pc,d0.w),d0

jmp .Index(pc,d0.w)

; ---------------------------------------------------------------------------

.Index:

dc.w UnkObject2_Init-.Index

dc.w UnkObject2_Main-.Index

; ---------------------------------------------------------------------------

UnkObject2_Init:

addq.b #2,oRoutine(a0)

move.l #MapSpr_UnkObject2,oMap(a0)

move.b #4,oSprFlags(a0)

move.b #1,oPriority(a0)

move.b #$10,oWidth(a0)

move.w #$47A,oTile(a0)

move.l (objPlayerSlot.oX).w,d0

addi.l #$32,d0

move.l d0,oX(a0)

move.l (objPlayerSlot.oY).w,d0

subi.l #$320000,d0

move.l d0,oY(a0)

rts

; ---------------------------------------------------------------------------

UnkObject2_Main:

move.l (objPlayerSlot.oX).w,d0

addi.l #$320000,d0

move.l d0,oX(a0)

move.l (objPlayerSlot.oY).w,d0

subi.l #$320000,d0

move.l d0,oY(a0)

lea (Ani_StaticObj).l,a1

jsr AnimateObject

jmp DrawObject

rts

; ---------------------------------------------------------------------------

...

; ---------------------------------------------------------------------------

Ani_StaticObj:

dc.w .Ani0-Ani_StaticObj

dc.w .Ani1-Ani_StaticObj

dc.w .Ani2-Ani_StaticObj

dc.w .Ani3-Ani_StaticObj

dc.w .Ani4-Ani_StaticObj

dc.w .Ani5-Ani_StaticObj

.Ani0:

dc.b $1D, 0, $FF

even

.Ani1:

dc.b $1D, 1, $FF

even

.Ani2:

dc.b $1D, 2, $FF

even

.Ani3:

dc.b $1D, 3, $FF

even

.Ani4:

dc.b $1D, 4, $FF

even

.Ani5:

dc.b $1D, 5, $FF

even

; ---------------------------------------------------------------------------

MapSpr_UnkObject2:

dc.w .Spr0-MapSpr_UnkObject2

dc.w .Spr1-MapSpr_UnkObject2

dc.w .Spr2-MapSpr_UnkObject2

.Spr0:

dc.b 2

dc.b $F0, 7, 0, 0, $F0

dc.b $F0, 7, 0, 0, 0

.Spr1:

dc.b 2

dc.b $F0, $D, 0, 8, $F0

dc.b 0, $D, 0, 8, 0

.Spr2:

dc.b 2

dc.b $F0, $D, 8, 8, $F0

dc.b 0, $D, 8, 8, 0

even

Those 2 objects are basically the same, they just set themselves to Sonic's position, offseted. They don't do anything else. The only difference is their mappings and animation data. I currently do not know if there are any graphics data that would fit them. The first object is found with all the badniks, and the second one is found among the springboard, unused seesaw, bridge, spikes, and unused swing.

Also, here are some unused mappings after the second unreferenced object's mappings:

Code (Text):

MapSpr_Unknown:

dc.w .Spr0-MapSpr_Unknown

dc.w .Spr1-MapSpr_Unknown

dc.w .Spr2-MapSpr_Unknown

dc.w .Spr3-MapSpr_Unknown

.Spr0:

dc.b 4

dc.b $F0, 3, 0, 0, $F0

dc.b $F1, 3, 0, 0, $F8

dc.b $F2, 3, 0, 0, 0

dc.b $F3, 3, 0, 0, 8

.Spr1:

dc.b 4

dc.b $F0, $C, 0, 4, $F0

dc.b $F8, $C, 0, 4, $F1

dc.b 0, $C, 0, 4, $F2

dc.b 8, $C, 0, 4, $F3

.Spr2:

dc.b 4

dc.b $F0, $C, 8, 4, $F3

dc.b $F8, $C, 8, 4, $F2

dc.b 0, $C, 8, 4, $F1

dc.b 8, $C, 8, 4, $F0

.Spr3:

dc.b 2

dc.b $F0, 3, 0, 0, $F4

dc.b $F0, 3, 0, 0, 4

And also this set of mappings data that doesn't even have an index table attached:

Code (Text):

dc.b 1

dc.b $F8, 5, 0, 0, $F8

dc.b 1

dc.b $F8, $D, 0, 4, $F0

dc.b 1

dc.b $FC, 0, 0, $C, $FC

dc.b 1

dc.b $F0, 3, 0, $D, $FC

dc.b 1

dc.b $F0, 3, 0, $11, $FC

dc.b 1

dc.b $F8, 5, 8, 0, $F8

dc.b 1

dc.b $F8, $D, 8, 4, $F0

dc.b 1

dc.b $FC, 0, 8, $C, $FC

dc.b 1

dc.b $F0, 3, 8, $D, $FC

dc.b 1

dc.b $F0, 3, 8, $11, $FC

Again, not sure if there are any graphics that would fit them.

JayKuriN said:

pattern I did notice was that most of them seemed to check a value before jumping to execution. If you do know what this is, could you explain?
Click to expand...

If you are referring to this:

Code (Text):

ObjMosqui:

move.b obj.oSubtype(a0),d0

bmi.w ObjMosquiBroken

bra.w ObjMosquiNormal

; ---------------------------------------------------------------------------

ObjPataBata:

move.b obj.oSubtype(a0),d0

bmi.w ObjPataBataBroken

bra.w ObjPataBataNormal

; ---------------------------------------------------------------------------

ObjAnton:

move.b obj.oSubtype(a0),d0

bmi.w ObjAntonBroken

bra.w ObjAntonNormal

; ---------------------------------------------------------------------------

ObjTagaTaga:

move.b obj.oSubtype(a0),d0

bmi.w ObjTagaTagaBroken

bra.w ObjTagaTagaNormal

; ---------------------------------------------------------------------------

ObjTamabboh:

move.b obj.oSubtype(a0),d0

bmi.w ObjTamabbohBroken

bra.w ObjTamabbohNormal

Then as you can see, it's using the subtype variable to distinguish between a busted badnik and a normal one. They basically made the 2 types separate objects, just tied under a singular ID, distinguished by the subtype ID. In the final, they merged them and placed checks whereever needed.

If you are not referring to this, could you provide examples of what you mean?

Sonic CD Quirks/Deconstruction

Useful Searches