The Metallic Madness act 2 demo was, indeed, rerecorded as well. The USA demo struggles while the Japanese demo gets quite a bit further ahead. Left: Japan/Europe, Right: USA

The Tidal Tempest act 3 demo was also rerecorded. What I find peculiar is how whoever recorded the USA demo slowly walked to the boss while the Japanese demo caught up. Were they trying to eyeball the Japanese demo? I dunno... Left: Japan/Europe, Right: USA

In the PAL version of Sonic CD, the physics of Sonic were modified to more closely resemble the NTSC physics while at a lower frame rate. As such, separate demo controller data had to be recorded for the special stage demos. Special Stage 1 Left: NTSC, Right: PAL

For some reason, the demo for Palmtree Panic act 1 was rerecorded for the USA release of Sonic CD. Here's a comparison showing the differences. Left: Japan/Europe, Right: USA

Thanks for the 200 followers :) Sorry that I've not been posting as much here. I admittedly don't really use Bluesky and I keep forgetting about this account. I should find the time to bring this account up to date.

A few ways to play and see it: 1. Modify the disc image to set the byte at 0x2A75353 from 1 to 0 (712 prototype only) 2. Modify RAM in an emulator to set address 0xFF1581 to 0 (works in final) 3. Use PAR code FF1581:00 or Game Genie code AAL9-8AEB in an emulator (works in final)

Additional fun fact: the sprite here was repurposed for the Backup RAM manager.

Thanks to c4/seafour4 on the Hidden Palace Discord server, a new prototype signpost sprite was discovered in the Palmtree Panic act 1 demo (DEMO11A.MMD) in the 712 prototype of Sonic CD, which was previously only seen in a magazine.

More Mario content? Oh no! Anyways... so, you know how in Mario 1 on the NES, you bounce downwards when you destroy a brick, but hover upwards in the SNES version? Turns out the SNES behavior was possibly the intended behavior? Here's how it works.

Another sample.

So, because Sonic 2 changed the ground speed cap to be more lenient, but not the air speed cap, you can actually see this issue by just running down a hill at a fast speed and then jumping. No hacks needed to see it.

So what happens if you remove that control lock in a faster game like Sonic 2? Yeah, not ideal...

In the Sega CD version of Sonic CD, pressing left or right while in the air applies a speed cap, but unlike Sonic 1/2/3K, the control lock for when you jump after rolling was removed. As a result, the trajectory of a rolling jump can be affected by the speed cap.

Sprite order is what determines who's in front of what, regardless of priority. All one needs to do is ensure the high priority sprite is bellow the low priority sprite while in front of a high priority tile layer. Footage from "I made you a Salad" (SHC 2019)

Actually, here's a visible example of this behavior in this set of pulley platforms in World 3-3!

In Super Mario Bros, objects with an upwards force have a quirk with its speed cap. If their Y speed (8.8 fixed point) goes beyond max speed + 0x80, then it gets capped to max speed - 0xFF. This behavior is possibly never visible, so here's a mod to show what it looks like.

Ever seen this weird sprite quirk with the lava and platform in Marble Zone in Sonic 1? Here's why that happens.

In the remake of Sonic 3 & Knuckles included with Sonic Origins, there is a hidden credits cheat code in the title screen. However, due to a very specific change in the code that handles cheat inputs, as well as a flag not being set when activated, this is impossible to see under normal play.

In the Nick Arcade prototype of Sonic 2, there lies leftover scraps of a build process for an even earlier build. One of the things that can be found is an earlier version of Emerald Hill's boss. It has only 2 hit points, no hitbox for the drill, and a weird bobbing animation.

In the vertical scrolling code, it follows the top boundary + 32. I assume that this might be related to old HUD code that displayed on the top 32 pixels of the screen? There is unused code that draws a chain of life icons, but that's on the bottom... www.youtube.com/watch?v=zkLf...

scrh_flag and scrv_flag do function in the Sonic 1 prototype, and may be related to a potential scrapped auto-scroll function. Each are individually set if the stage boundaries for their respective axis are the same, and change how the camera moves. [1/2]

There's some unused variables related to camera scrolling in Sonic 1 and Sonic CD. Here are their official names, taken from Sonic Gems Collection.

Leftover symbol data included a lot of internal names for various things. Sonic was "play00", "play01", or "play02", depending on the game mode. Tails was "fox" in Sonic 2, but was changed to "miles" in Sonic 3. Knuckles was either "knuckles" or "nuckle". Amy was "emie".

Sega did have their own formats. The 2 most well known ones are "Nemesis" and "Enigma". "Nemesis" was used for tile graphics and "Enigma" was used for tilemaps. Symbol data revealed "Nemesis" to potentially be called "bitdevr", and "Enigma" to actually be called "mapdevr".

There is a compression format used in various Sega Genesis games known as "Kosinski". It is an LZSS based format used for various kinds of data in games. Recently, it was found out that "Kosinski" was LZEXE this entire time. 🧵 bellard.org/lzexe.html

A breakdown of the differences in the peelout and spindash between the original and 2011 remake. (Part 1)

100 followers! Thanks 😊

A brief breakdown of how the peelout and spindash are charged up in the original Sega CD version of Sonic CD.

Wacky Workbench actually uses a duplicate file for Sonic's object code, modified to handle all the stage gimmicks. However, some of the updates they made to the main file didn't get implemented in the duplicate file, such as changing the spindash charge speed from 50 to 75.

So, in the 2011 remake, the time it takes to start time traveling appears to be longer than the original. However, this is false. As it turns out, in the original, the time warp timer ticks every frame, regardless of lag. The original can get laggy. For example, this section.

When you turn in Sonic CD's special stages, Sonic's sprite tilts towards the direction he's turning, and it's gradual. Well, the developers intended to make the untilting gradual as well, but a couple of bad branches make it so that he snaps back to the normal sprite instantly.

The time warp cutscene is not actually really much of a loading screen at all. Nothing loads in the background while it's running. It only actually starts loading the next time zone file after it ends and fades to white.

Fun fact: the Sub CPU program file for Sonic CD's good ending is called "BADEND.BIN" (loads "GOODEND.STM") and the bad ending Sub CPU program file is called "GOODEND.BIN" (loads "BADEND.STM"). They got the file names mixed up.

The special stages in Sonic CD were intended to have 1024px wide backgrounds instead of 512px wide backgrounds. There exist unused chunks that would've been placed after or inbetween the used ones. For example, here's special stage 1's background and what it looks like extended.

The 2011 remake is missing the layer with the small buildings in special stage 7's background.

You may notice that in Wacky Workbench, the background changes from turquoise to green after the electrical beams flash. This is due to an oversight. 🧵

There exists concept art for the special stage where Sonic would fall through something while shrugging. This was actually partially implemented, but ultimately went unused. 🧵

There is evidence that suggests that this unused blue ring monitor was intended to be the Combine Ring powerup from Knuckles Chaotix. 🧵

If the leftover code for sneezing were to be activated properly, it would have looked something like this.

There is an unused animation of Sonic sneezing, which is well documented already. Did you know that there was actually some code that was implemented for it that never got used? 🧵

Unused special stage animations for Sonic in Sonic CD 🧵 0x07

Test, 1, 2.... Seeega!