don't click here

Sonic CD Quirks (Sega CD Version)

Discussion in 'Engineering & Reverse Engineering' started by Devon, Jul 11, 2022.

  1. It was just a shame the ASIC chip was never used in-game. Look at the last boss to Sonic CD, those metal panels should have smoothly rotated using the ASIC chip and stuff like that.
     
  2. Pobert-Eii

    Pobert-Eii

    Member
    108
    100
    43
    I thought it was weird the metal panels were not ASIC effects... perhaps RAM issues or sumn
     
  3. Devon

    Devon

    There's nothing left but faith Tech Member
    865
    600
    93
    A limitation that would need to be overcome is adapting the graphics operation render(s) to Genesis sprites. While the graphics operation arranges the rendered tiles top to bottom, then left to right like sprites do, the maximum sprite size is 4x4 tiles (32x32 pixels). A single metal panel is larger than that, so multiple sprites are needed to build one. The rendered tiles would need to be rearranged to fit with the multiple sprite setup for the most optimal sprite usage. Otherwise, you'd be looking at a lot of 1 tile wide sprites...
     
    Last edited: Nov 18, 2022
  4. The game should have been designed and built with ASIC use in mind, more so on the boss stages . It's very sad that the only teams that looked to use the ASIC child in a traditional 2D side scrolling game on the Mega CD were Travelers Tails and Core in Puggsy and Son Of Chuck
     
  5. Devon

    Devon

    There's nothing left but faith Tech Member
    865
    600
    93
    I also forgot to mention the fact that to use the graphics operation, the ASIC needs to have access to Word RAM and have all the data needed for the transformation (stamps, map, trace table) in it, alongside space for dumping the render into, all in Word RAM.

    Normal stages are all loaded into the entirety of Word RAM and run from it, which means that Word RAM absolutely cannot be touched by the CD side. Using Genesis RAM to hold the code and data would be totally unreasonable, especially since the stages themselves use a great deal of Genesis RAM for variables and buffers. The safest bet would be to port Naka's codebase to the Sub CPU and having to transfer things like controller input, graphics (Sonic's sprite graphics would need to be constantly updated, alongside plane, scroll, and sprite data), and FM the sound effect queue between the 2 sides, also using Word RAM and the communication registers. This is actually how the special stages work, albeit implemented in a pretty lackluster and hackish way (gameplay update timing is tied to the stage rendering).

    That's a good amount of work required, especially with a team who was clearly pretty new to Sega CD development, using someone else's codebase that they had to learn and port over to the Sega CD at the start of development, under a deadline. At least with the special stages, they were able to just develop their own codebase from scratch and plan it out with the graphics operation in mind. With Naka's code, they probably didn't even want to bother and just get the game out.
     
    Last edited: Nov 18, 2022
  6. Hivebrain

    Hivebrain

    Administrator
    3,000
    99
    28
    53.4N, 1.5W
    Github
    Does a Mega Drive ROM alone have any kind of access to Mega-CD hardware? I've heard of games being able to play CD audio, but I mean no CD, just the cartridge.
     
  7. Devon

    Devon

    There's nothing left but faith Tech Member
    865
    600
    93
    The Genesis can access PRG-RAM if it has bus access, alongside Word RAM and the other hardware registers. The Sub CPU is the one that handles actually working with the CD hardware, so in mode 1, it's a matter of getting the BIOS and your system program loaded. In mode 1, the cartridge is in its usual place in memory, while the Sega CD's Main CPU side memory is shifted to $400000 (see the /CART pin, which in turn also dictates if a cartridge or the Sega CD's boot ROM is booted). Once that's set up, the Sub CPU is free to do whatever with the CD hardware: access the CD drive, use the PCM chip, use the graphics operation, etc.

    I made a quick demo a while ago that shows the graphics operation and PCM chip working in mode 1, and even works on hardware:
     
    Last edited: Nov 18, 2022
    • Informative Informative x 4
    • Like Like x 1
    • List
  8. Pobert-Eii

    Pobert-Eii

    Member
    108
    100
    43
    Does any animation data remain for these sprites? The way they're arranged suggest to me that it might've used the Mega Drive's built in sprite flipping.
    [​IMG]
     
  9. Devon

    Devon

    There's nothing left but faith Tech Member
    865
    600
    93
    They don't. In fact, I can't even find the tiles for those in any of the stage MMD files, not even in any prototypes! I did find the mappings data in the Tidal Tempest files (they are in frames 0xAD to 0xB4), but other than that...

    I DO see them in the 1996 PC version's sprite data, though! In fact, a quick question: were some of the sprite rips for Sonic CD just done with the PC version and also labelled as from the MCD version, since the PC version is a direct port?
     
    Last edited: Nov 27, 2022
    • Informative Informative x 1
    • List
  10. Brainulator

    Brainulator

    Regular garden-variety member Member
    Are they in any prototypes, by chance?
     
  11. Devon

    Devon

    There's nothing left but faith Tech Member
    865
    600
    93
     
  12. Pobert-Eii

    Pobert-Eii

    Member
    108
    100
    43
    ...okay, that is really weird.
    I recall the original PC version being very popular before the release of the remake, with cnet still hosting downloads of the original trial for several years. There were programs created specifically to make the original PC version run on modern systems at the time.
     
  13. Devon

    Devon

    There's nothing left but faith Tech Member
    865
    600
    93
    Not the first time this has been the case. These sprites have been featured in sprite sheets for a good while now, but don't even exist in the game since 510, and yet, they show up in the PC version. They do exist in v0.02, but these were in sheets before that got released.

    [​IMG]
     
  14. Brainulator

    Brainulator

    Regular garden-variety member Member
    This is what happens when you reply to older versions of posts. Oops.
     
  15. Devon

    Devon

    There's nothing left but faith Tech Member
    865
    600
    93
    Made my own rips of Sonic's sprites in the final's regular stages.
    [​IMG]
    [​IMG]
    [​IMG]
    [​IMG]

    v0.02 rip
    [​IMG]

    510 rips
    [​IMG]
    [​IMG]
    [​IMG]
    [​IMG]

    v0.51 rips
    [​IMG]
    [​IMG]
    [​IMG]
    [​IMG]

    712 rips
    [​IMG]
    [​IMG]
    [​IMG]
    [​IMG]

    1996 PC version rip
    [​IMG]

    510, 0.51, 712, and the final sprite sets are almost the same as reach other, minus some missing sprites, and also flipped balancing and skidding animations. The Tidal Tempest set are very much based on v0.02's set, with the mappings for the 3D rolling sprites being left over.
     
    Last edited: Nov 27, 2022
    • Like Like x 6
    • Informative Informative x 4
    • Useful Useful x 1
    • List
  16. Devon

    Devon

    There's nothing left but faith Tech Member
    865
    600
    93
    I haven't seen this documented anywhere, but there's a THIRD unused hanging sprite (on the very left here). The unused hanging sprites are found in Tidal Tempest (which seems to be a hub for these unused sprites in the final, with leftover mappings as far back as v0.02).

    [​IMG]

    In the Wacky Workbench sprite data, all 3 are replaced with the final sprites, even in the 510 prototype, so it's possible that this set is the pre-510 version, before they were redrawn.

    Also, funny thing about these sprites. On TCRF and Retro's wiki, they were portrayed as a single sprite, colored blue, and a few sprite sheets I've seen color the second frame white. The game data shows that the first frame is black and white, and the second frame is yellow and black.

    [​IMG]
     
    Last edited: Nov 27, 2022
    • Informative Informative x 6
    • List
  17. Devon

    Devon

    There's nothing left but faith Tech Member
    865
    600
    93
    So, the game features a downward speed cap of 16 when you are in the air, so that it would prevent you from clipping through floors or messing up vertical wrapping if you were to fall for an extended period of time.

    However, this only applies when Sonic is in a normal state, where he uses the standard movement+gravity routine to handle falling. However, like in the other Genesis games, in his hurt state, they use a different gravity value than the one hardcoded in the standard function, so they just use the standard non-gravity movement routine and handle apply gravity manually, and they did not put the speed cap there.

    In the 510 prototype, in the beginning section of Tidal Tempest Act 2, there used to be enemies, and it's possible to get knocked back by one and glitch the vertical wrapping and die:
    [​IMG]

    The enemies placed in that area were removed, presumably for that reason.

    In the final, if you time and position yourself right in Wacky Workbench, you can get knocked back and clip through the floor:
    [​IMG]
     
    • Informative Informative x 9
    • Like Like x 3
    • List
  18. Devon

    Devon

    There's nothing left but faith Tech Member
    865
    600
    93
    I made some hackish modifications to @Lapper and @Mercury's collision overlay for Sonic 1 and got it working in Collision Chaos Act 1 Present:


    Wanna mention the pinball flippers. There's actually 2 sets of slope data for them: one for when you're falling/standing, and one for when you're moving upwards, specifically for hitting them from below.
    [​IMG] [​IMG]

    However, it should be worth noting that collision detection is only done at the center of Sonic's feet/head, and does not take into account his full hitbox width. As a result, the collision width of the flippers are effectively shrunken down like so:
    [​IMG] [​IMG]

    [​IMG]

    Also, bumper hitboxes and Sonic's hitbox are larger in the 2011 remake than in the original version:
    [​IMG] [​IMG]

    Another fun one: the game still retains the code from Sonic 1 that shrinks Sonic's object collision hitbox if he's ducking... except that they forgot to update the sprite frame ID. As a result, it doesn't work as intended, and the hitbox will shrink when an angled walking sprite is displayed.
    [​IMG] [​IMG]

    An addendum to this: turns out this is only an issue if you roll into a monitor from the left side. This is actually because the point where it would activate the solid collision, but not the destruction collision is actually rested up against the side of the monitor. In solid object collision, if that happens and you are left to the object, it's considered a collision. This happen because it checks if the distance from the object on the left is > 0. On the right side, it checks if the distance is >= 0 instead (Sonic 1, on the contrary, checks > 0 for the right side, too).
     
    Last edited: Nov 29, 2022 at 10:18 PM
    • Informative Informative x 6
    • Like Like x 2
    • List
  19. E-122-Psi

    E-122-Psi

    Member
    2,292
    455
    63
    Really all this stuff makes me excited for if Sonic CD hacking becomes mainstream and the How To wiki gets a HUGE new column of fixes. :P