don't click here

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

Discussion in 'General Sonic Discussion' started by Clownacy, Mar 30, 2022.

  1. Billy


    RIP Oderus Urungus Member
    Colorado, USA
    Indie games
    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!
    • Like Like x 1
    • Agree Agree x 1
    • List
  2. Devon


    A̸ ̴S̴ ̵C̵ ̷E̶ ̸N̸ ̴D̶ ̵E̶ ̸D̶ Tech Member
    your mom


    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()".
    Last edited: Sep 14, 2023
    • Like Like x 3
    • Informative Informative x 1
    • List
  3. Clownacy


    Tech Member
  4. Devon


    A̸ ̴S̴ ̵C̵ ̷E̶ ̸N̸ ̴D̶ ̵E̶ ̸D̶ Tech Member
    your mom
    I personally don't really think the functions for handling solid/platform objects were included in Sonic's file.
  5. Brainulator


    Regular garden-variety member Member
    This has since been corrected; thankfully, the prototypes have linker data that is missing in the final.
    • Informative Informative x 1
    • List
  6. BenoitRen


    Tech Member
    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.

  7. MainMemory


    Kate the Wolf Tech Member
    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).
    • Informative Informative x 1
    • List
  8. BenoitRen


    Tech Member
    Is the different sprite format why no one has anything to say to what I posted?
  9. BenoitRen


    Tech Member
    Do you happen to have the file names for Sonic 3 & Knuckles? It would help with my decompilation. :)
  10. Clownacy


    Tech Member
    Code (Text):
    1. ACTTBL.SN3
    2. ACTTBL_E.SN3
    3. ACTTBL_N.SN3
    4. ADVA.SN3
    5. DATA.SN3
    6. DATAP.SN3
    7. DSELECT.SN3
    8. S3BS00.SN3
    9. S3BS01.SN3
    10. S3BS02.SN3
    11. S3BS03.SN3
    12. S3BS05.SN3
    13. S3BS06.SN3
    14. SONIC.SN3
    15. SPECIAL.SN3
    16. TBL.SN3
    17. VSSCREEN.SN3
    18. ZONE00.SN3
    19. ZONE01.SN3
    20. ZONE02.SN3
    21. ZONE03.SN3
    22. ZONE05.SN3
    23. ZONE06.SN3
    24. ZONE0E.SN3
    25. ZONE0F.SN3
    26. ZONE10.SN3
    27. ZONE11.SN3
    28. ZONE12.SN3
    29. ZONE13.SN3
    30. ACTTBL.SN4
    31. ACTTBL_E.SN4
    32. ACTTBL_N.SN4
    33. ADVA.SN4
    34. DATA.SN4
    35. DATAP.SN4
    36. DSELECT.SN4
    37. PAT.SN4
    38. S4ZN00.SN4
    39. S4ZN01.SN4
    40. S4ZN02.SN4
    41. S4ZN03.SN4
    42. S4ZN04.SN4
    43. S4ZN05.SN4
    44. S4ZN06.SN4
    45. S4ZN07.SN4
    46. S4ZN08.SN4
    47. S4ZN09.SN4
    48. S4ZN0A.SN4
    49. S4ZN0B.SN4
    50. S4ZN0C.SN4
    51. S4ZN13.SN4
    52. S4ZN14.SN4
    53. S4ZN15.SN4
    54. S4ZNED.SN4
    55. S4ZNVS.SN4
    56. SONIC.SN4
    57. SPECIAL.SN4
    58. TBL.SN4
    59. VSSCREEN.SN4
    60. ZONE00.SN4
    61. ZONE01.SN4
    62. ZONE02.SN4
    63. ZONE03.SN4
    64. ZONE04.SN4
    65. ZONE05.SN4
    66. ZONE06.SN4
    67. ZONE07.SN4
    68. ZONE08.SN4
    69. ZONE09.SN4
    70. ZONE0A.SN4
    71. ZONE0B.SN4
    72. ZONE0C.SN4
    73. ZONE0E.SN4
    74. ZONE0F.SN4
    75. ZONE10.SN4
    76. ZONE11.SN4
    77. ZONE12.SN4
    78. ZONE13.SN4
    79. ZONE14.SN4
    80. ZONE15.SN4
    81. ZONE16.SN4
    82. ZONE17.SN4
    83. ZONEEND.SN4
    Presumably, '*.SN3' files are for Sonic 3, and '*.SN4' files are for Sonic & Knuckles.
  11. BenoitRen


    Tech Member
    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.
  12. Kilo


    That inbetween sprite from S&K's title screen Tech Member
    S1 - Metal Sonic's Challenge, Sonic 1 Rev01 ASMX Disasm
    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.

    Attached Files:

    Last edited by a moderator: Feb 2, 2024
  13. GoldS


    "azar" is Rocky (from azarashi, earless seal) and "niwa" is Cucky (from niwatori, domestic chicken)
    • Like Like x 2
    • Informative Informative x 2
    • List
  14. Brainulator


    Regular garden-variety member Member
    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...
  15. Kilo


    That inbetween sprite from S&K's title screen Tech Member
    S1 - Metal Sonic's Challenge, Sonic 1 Rev01 ASMX Disasm
    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.

    Attached Files:

    Last edited by a moderator: Feb 2, 2024
  16. BenoitRen


    Tech Member
    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. :)
  17. Devon


    A̸ ̴S̴ ̵C̵ ̷E̶ ̸N̸ ̴D̶ ̵E̶ ̸D̶ Tech Member
    your mom
    What's the context of their usage?
  18. BenoitRen


    Tech Member
    In Sonic CD, function dodai_init, there's a bit of code that creates an object:
    Code (Text):
    2.   if ((wk = pActwk->userflag.b.l) != 0) {
    4.     if (actwkchk(&pNewact) != 0) {
    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;
    14.       /* snip */
    15.     }
    16.   }
    Then we have function dai_fout:
    Code (Text):
    2. static void dai_fout(sprite_status* pActwk) {
    3.   short s;
    5.   if (pActwk->cdsts) {
    6.     s = time_flag + pActwk->cdsts * 3;
    7.     flagwork[s] &= 127;
    8.   }
    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. }
    • Informative Informative x 1
    • List
  19. Devon


    A̸ ̴S̴ ̵C̵ ̷E̶ ̸N̸ ̴D̶ ̵E̶ ̸D̶ Tech Member
    your mom
    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.
  20. Brainulator


    Regular garden-variety member Member
    The SMPS 68K source code uses "fout" for fade out, though that's a completely different set of code.