Everything That I Know About Sonic the Hedgehog's Source Code

Definitely interesting to see the official terminology used. Why did I think "the Sonic 2 patent" was for the Aquatic Ruin Zone loop that also has a path through it? Bad memory?

Sillier note, I'm sure you're supposed to pronounce "sloop" as s-loop (it's even "S. loop" in the flow chart), but I can't help but read it as if it were a sound effect. Sloop!

 

I personally concluded to "action number" when I saw that the file that contained the code for updating objects in Sonic CD Gems Collection was called "ACTION.C", with the main function that iterates through each object and calls their code "action()".

 

I personally don't really think the functions for handling solid/platform objects were included in Sonic's file.

 

This has since been corrected; thankfully, the prototypes have linker data that is missing in the final.

 

I'm trying to come up with what would be the official-sounding, or representative, type names for some of the data structures of Sonic CD, so here's some thoughts:

From the patent text, we have "sprite status table". I thought a "table" in assembler is what's called an "array" in C, but it seems to refer to any collection of data, even what's called a "struct" in C. But if that's true, then every data structure is a table, so it's kind of redundant. In light of this, I'd call the data type "sprite status".

Each sprite status has a pointer to what's called a "pattern table". In the C code, this data structure is little more than a wrapper around an array, as the data members consist of a counter and an array. Curiously, the array itself is defined as an anonymous union of an array with 20 elements and an array of unknown size. The names of the arrays are spra and spr, respectively, suggesting that this is not a pattern table, but a sprite table.

As for the data structure contained in the array, it doesn't seem to be the pattern itself, but data associated to it. It consists of four numbers called xoff, yoff, etc and index. I'm guessing this is what the community calls a "mapping"? The collection of which is used to make one sprite. Which would mean that the data structure holding them together can't be a sprite table (as it's not a collection of sprites), but is indeed a pattern table.

But calling the data structure "pattern table" sounds too generic. "sprite patterns", maybe? Or "sprite pattern table"?

When it comes to naming the data structure that has pattern data, there are no hints at all. As far as I know, "mapping" is a term not based on any information related to the source code. If I had to choose something, though, "pattern mapping" seems to fit.

Thoughts?

 

It is worth noting that Sonic CD's PC and Gems ports use a completely different sprite format than the original MCD version (which used the same formats as Sonic 1).

 

Is the different sprite format why no one has anything to say to what I posted?

 

Do you happen to have the file names for Sonic 3 & Knuckles? It would help with my decompilation.

 

Weird, there doesn't seem to be an equivalent to Sonic 1's AC.SN1, which contains the game's code. I'm guessing it's split up into SONIC.SN4, SPECIAL.SN4, the zone-specific files, and a couple for the versus mode.

 

I'm going to argue against this. In the Mega Drive version, priority data is actually embedded in the block data, as the blocks are the actual "tilemap" in the whole scheme of the chunk system, so they're what contains info on the tiles for the VDP, including priority. The reason J2ME has it separated is because the blocks are PNGs, which can't hold priority metadata, at least not to my knowledge.

On a side note, the original BREW version of Sonic 1 in which J2ME is based off of was recovered in November. This is important because it has the Special Stages which had to be cut from the western J2ME release either due to processing or file size limitations, as well as other cut backs such as splitting the game in 2 parts. Unfortunately when extracting the files there is no graphics or MIDI data, but there is something called filelist.txt which as you'd expect contains a list of files the game needs to load. It seems to be incomplete for whatever reason, but it might help in putting the pieces of this puzzle back together. Here are the contents:

Code (Text):

1. dai3.gif
2. dai3_0x27.gif
3. dai3_0x13.gif
4. dai2_0xE0.gif
5. dai2_0xF0.gif
6. kazari.gif
7. kassya.gif
8. mizu.gif
9. mizu_0x09.gif
10. yari.gif
11. awa.gif
12. objawa.gif
13. bou.gif
14. ben.gif
15. water.gif
16. water2.gif
17. z_dai3.gif
18. z_dai2_0xE0.gif
19. z_dai2_0xF0.gif
20. z_kazari.gif
21. kassya.gif
22. z_mizu.gif
23. mizu_0x09.gif
24. yari.gif
25. awa.gif
26. objawa.gif
27. z_dai3_0x27.gif
28. z_dai3_0x13.gif
29. bou.gif
30. z_ben.gif
31. water.gif
32. water3.gif
33. fun.gif
34. brkabe.gif
35. pedal.gif
36. step.gif
37. elev.gif
38. sisoo.gif
39. paka2.gif
40. ele.gif
41. mawaru.gif
42. yukai.gif
43. dai4.gif
44. dai_.gif
45. fire6.gif
46. mogura.gif
47. fish2.gif
48. uni.gif
49. brobo.gif
50. uni.gif
51. brobo.gif
52. buta.gif
53. buranko_.gif
54. noko.gif
55. door.gif
56. belt.gif
57. shooter.gif
58. beltc.gif
59. yukae.gif
60. yukai.gif
61. beltcon_0.gif
62. beltcon_1.gif

There's still a good chance that the files can be recovered though, from what it seems like in the decompilation work I did, all the graphics and audio data are stored in something called a "scratchpad".

Well scratch what I said about the game not being split into 2. Trying to load any zones past Spring Yard prompts you to download the files off of SEGA's servers. And we're about 17 years past due on Sonic Cafe's discontinuation.

Final edit: So I think I figured out why filelist is incomplete. A lot of these names seem to be assets of the zones that need to be downloaded. So what it likely uses this for is going through SEGA's servers to find these files specifically. While everything else is already in the ROM.

Alright I do apologize for double posting, but I have edited the above post into oblivion, and this is kind of a whole different point on the subject anyways. I decided to go through and make a spreadsheet assigning source code names for objects utilizing both J2ME and the S2NA symbols. Out of 140 objects we have 90 of their original names, 70%. Only 83 (59.3%) of those I am 100% sure on and didn't extrapolate their name either due to their content, or if their sprites were bunched together in J2ME. Take a look, and feedback is appreciated.

 

"azar" is Rocky (from azarashi, earless seal) and "niwa" is Cucky (from niwatori, domestic chicken)

 

I think:

• Object $1C is bgspr, per Sonic 2 Nick Arcade's edit mode file
• Object $2E is probably item2, per Sonic CD Gems Collection and Sonic & Knuckles Collection
• Object $37 is flyring, per Sonic CD Gems Collection and Sonic & Knuckles Collection

Actually, the Nick Arcade debug list has several objects that might be missing from your list...

 

Ah! Thanks for pointing this out. In that case the SLZ fire launcher's sprite itself is probably called mfire rather than the object. I'll wait to see if more people come around with suggestions and post a more complete sheet down the road.

Edit: Nope mfire is something else, J2ME attached it to the wrong thing. I kind of just skimmed over S2NA if I'm being honest, my signature is very relevant here.

Alright, I decided to actually take the time and sort through those debug tables and it is definitely much more cleaned up.
The only thing left to figure out are things that either are spawned by other objects, like projectiles and explosions. Things that aren't for normal gameplay like title screen elements, credits elements, etc.
I also changed bosses from red to orange, we do know by the Green Hill boss and Final Zone boss that it's "boss" followed by the zone number. Now here's the issue though. While it's been known for decades that Sonic 1's level order was changed, the bosses were made in the middle of finalizing the level order, so there's a chance that the number that follows could reflect the final level order, especially since their order in the code does follow the final level order, rather than the early level order.

 

A term I encounter a lot in Sonic source code symbols is "fout". What does it mean? Could it be short for "frameout"?

In one of my native languages it means "error" or "wrong", but I doubt that's what it means here.

 

What's the context of their usage?

 

In Sonic CD, function dodai_init, there's a bit of code that creates an object:

Code (Text):

1.  
2.   if ((wk = pActwk->userflag.b.l) != 0) {
3.  
4.     if (actwkchk(&pNewact) != 0) {
5.  
6.       dai_fout(pActwk);
7.     }
8.     else {
9.       pNewact->actno = 10;
10.       pNewact->xposi.w.h = pActwk->xposi.w.h;
11.       pNewact->yposi.w.h = pActwk->yposi.w.h - 16;
12.       ((char*)(pNewact))[61] = -16;
13.  
14.       /* snip */
15.     }
16.   }

Then we have function dai_fout:

Code (Text):

1.  
2. static void dai_fout(sprite_status* pActwk) {
3.   short s;
4.  
5.   if (pActwk->cdsts) {
6.     s = time_flag + pActwk->cdsts * 3;
7.     flagwork[s] &= 127;
8.   }
9.  
10.   frameout(pActwk);
11. }

Looking around a bit more, it looks like my hunch may be right. Function mecasnc3_rght is responsible for handling Metal Sonic in R3 going right, and this is the last part:

Code (Text):

1.   if (pActwk->xposi.w.h < 1320)
2.     empatchg(pActwk, msc_pchg);
3.   else
4.     mecasnc3_fout(pActwk);

Function mecasnc3_fout:

Code (Text):

1. void mecasnc3_fout(sprite_status* pActwk) {
2.   emie3end = 255;
3.   emie3clrsetx(zone3colora);
4.   frameout(pActwk);
5.   jmp_flg = 1;
6. }

 

Yeah, it looks like it is short for "frameout". With "dodai_init", it looks like it deletes itself if it fails to spawn in pNewact. "dai_fout" also clears the "spawned" flag in its object state/respawm table entry alongside deleting itself.

 

The SMPS 68K source code uses "fout" for fade out, though that's a completely different set of code.