Sonic CD Quirks/Deconstruction

Which version would you say is glitchier, the original or the remaster?

 

Interesting. I've never seen a lot of those. The only one I'm familiar with is the one saying "Internal RAM is not initialized". It was dumb too, because you could not play the game unless you initialized the RAM. I didn't know the first thing about RAM. I didn't understand the Sega CD control panel. I thought the game just wasn't working and ended up exchanging my copy for another one. I can't be the only one who ran into that as a kid.

 

If pl_suu is the amount of lives, then the Special Stage caps it at 250. No cap seems to exist in the rest of the code.

 

In the PC/Gems version, pl_suu is an unsigned char. However, when it is decreased, it's cast to a signed char to check if it has become negative.

This would mean that the life counter can exceed 127, but as soon as you lose a life, you're right back at zero.

 

One thing that genuinely surprised me about the Sonic CD manual is that at no point is the save system actually described in it, at least for the US. The Japanese manual does have a section about it.

 

Now that I've decompiled the PC/PS2 version of the Special Stage, I thought I'd revisit this with the C version.

The timer update function in the port is called time_dec:

Code (Text):

1. void time_dec() {
2.   if (spgmmode & 2)
3.   {
4.     time_time_attack();
5.     return;
6.   }
7.   --tcnt20;
8.   if (tcnt20 == 0)
9.   {
10.     tcnt20 = 20;
11.     dec();
12.   }
13.  
14.  
15.   if (tdecflg != 0)
16.   {
17.     --tdecflg;
18.     dec();
19.   }
20. }

Just like the Mega CD version, it counts down one second every 20 frames (remember that the Special Stage is 20 FPS). The second counter, which decreases a second as long as it's not zero, is called a flag for some reason. (Side note: the port really likes to use 'flag' variables with more than two values)

This second flag counter is set by "sibuki" functions. Apparently this means "splash" in Japanese.

The splash has three states in the port. The first state is function sibuki0:

Code (Text):

1. void sibuki0(sprite_status_sp* sibukiwk) {
2.  
3.   sibukiwk->pattbl = mpsibuki;
4.   sibukiwk->sx_posi.w.h = 256;
5.   sibukiwk->sy_posi.w.h = 344;
6.   patinit(sibukiwk, 0);
7.   *(short*)(sibukiwk->actfree) = 14;
8.   ++sibukiwk->exeno;
9.   key_set(162);
10.   if (!(spgmmode & 2)) tdecflg = 10;
11.   sibuki1(sibukiwk);
12. }

The animation of the large splash is set to last 14 frames just like in the original, and tdecflg is set to 10, so the fast countdown is, just like in the original slightly shorter than the animation's duration.

The second state is what actually does the bookkeeping for the animation, a function called sibuki2:

Code (Text):

1. void sibuki1(sprite_status_sp* sibukiwk) {
2.   if (--*(short*)(sibukiwk->actfree) != 0) return;
3.   if (actwk[0].scno_ce != 3) { sibukiwk->actflg |= 1; return; }
4.   patinit(sibukiwk, 1);
5.   sibukiwk->exeno = 2;
6. }

I have no idea what scno_ce is, so I have no idea what it's checking Sonic for. But apparently it delays the transition tot he next state, handled by function sibuki3:

Code (Text):

1. void sibuki2(sprite_status_sp* sibukiwk) {
2.   if (actwk[0].scno_ce != 3) sibukiwk->actflg |= 1;
3.   else if (sibukiwk->patno == 0) tdecflg = 2;
4. }

I think this handles setting the counter to 2 frames on every animation loop, but I don't know enough about the code to dissect this function.

There's also a function that clear the splash:

Code (Text):

1. void sibuki_clr() {
2.   if (actwk[2].actno != 0) actwk[2].actflg |= 1;
3. }

This gets called from functions evt01, evt04 and jumpset. The latter is obvious, so what about the first two? They're part of a series of collision events, and the game decides which to call based on... Sonic's scno_ce value! So, it'd seem that colliding with certain things stops the splashing.

 

We all know how in the C port of Sonic CD each stage version has its own DLL/ELF, right? This inevitably leads to some duplicate code.

I'm going through all the code for R1, and each stage version seems to have its own version of the code that handles scrolling. It's annoying. Why did they do it like that? Even the code for the two futures of a stage has differences, and that's supposed to be the same stage internally.

 

There's a reason 99% of the mods you see are for the rsdk remake. I always assumed that decision was done to suit how the hardware accessed data, but have no idea if that's actually true!

 

(wait wtfs stopping the RAM from loading a selected area of the same variables once and keeping it through all of the game and only loading swappable modules of data when needed)

 

You'd think with a game that uses swappable assets as a core game mechanic they would, well, swap the assets and keep the core game, but I guess not! Weird...

 

You can't explain what I'm seeing by them using a build system that includes the code in each file, though. When I said each stage version has its own version, I meant that they all have a different version!

For example, in function scr_set, R11A zeroes the flags in a one-liner:

Code (Text):

1. scrh_flag = scrv_flag = scr_die.b.h = scr_timer.b.h = zone_flag.b.h = 0;

R11B decides to do it in several lines:

Code (Text):

1. scrh_flag = 0;
2. scrv_flag = 0;
3. scr_die.b.h = 0;
4. scr_timer.b.h = 0;
5. zone_flag.b.h = 0;

R12B uses a combination of those approaches:

Code (Text):

1. scrh_flag = scrv_flag = 0;
2. scr_die = zone_flag = 0;
3. scr_timer = 0;

And that's only scratching the surface. The above example accomplishes essentially the same thing, but other functions have notable differences (most often the scroll function). Sometimes they only have one line change, and sometimes they don't exist/are stubbed.

 

With Sonics 1-through-3 (and most Mega Drive games) I get the impression the designers and artist went away, made some assets, and then sent it over to Yuji Naka to merge together. This was before sensible version control - you just passed floppy disks around in the office.

I can see them running into an issue with this with Sonic CD - there are four timezones to maintain per stage, maybe it's more efficient to hand your designers a stripped-down copy of the code so they can handle their own "section" of the game. Perhaps they were expecting each section to be larger than a floppy disk, and thus a lot more awkward to pass around.

The net result is you get multiple copies of the same code, but as it's on a CD, there's plenty of space so it doesn't matter.


Or it could be a loading issue. Perhaps storing the data as they did reduces the need to spin the disc. Or maybe they thought that would be the case, idk.