Under the Surface of Classic Sonic

I think what's interesting about the "Player shock jump up" line is the fact they deliberately used the unsigned byte representation of -2 (0xFE) when setting Mario's Y speed...

Additionally, you can see the removed lines of code in the official All Stars source code!

From @nfroggy99 on Twitter/X:

"When you look at the All-Stars source code, the equivalent subroutine to BrickShatter (BBKINT) says "Player shock jump up", so you're right that this behavior was intended. I'm glad that they accidentally screwed it up because the All-Stars behavior feels worse."

It should be noted that the temporary invisible solid block is what keeps the gap solid while the block bouncing animation plays, and is also what actually kills the enemies when you hit a block from under them.

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.

It's also possible that they simply just forgot.

This was fixed in Sonic 3 by also applying the modified ground speed cap logic to the air physics.

Another sample.

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.

This, too...

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

This isn't so noticeable in Sonic CD due to the different nature of its level design compared to the other games, but the beginning of Tidal Tempest Act 1 is probably where it's most noticeable.

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!

From what I can see from the code, it appears that only pulley platforms, vertically oscillating platforms, and Koopa Paratroopas make use of this functionality.

🤫

The reason the cap ended up that way is because the integer portion is set to -max speed, while the fractional portion is set to 0xFF for some reason, which results in that stuttery motion.

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.

Correction: the bit about the platform not being drawn yet while sprites are being processed being the cause is incorrect. It's more likely that it's because sprites at the top of the table in VRAM will just automatically take priority over sprites after it, regardless of setting

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

If anyone had caught onto the inputs needed to trigger this secret, it's the same input required to activate the hidden Japanese credits in Sonic 1, on REV01!

As well as the code that sets the secret to be active. Note the lack of the intro Skip flag here.

Another bug that prevents this from appearing is that the code fails to set the global variable to skip the intro to false.

Due to this, it never reaches the code to fully set up the hidden credits.

Below is a reverse-engineered estimate of the code where the game sets up the hidden credits.

A side effect of the C press removal is that its still possible to input the first 6 presses... by hitting 6 frame perfect Down-Right inputs to total a value of 16.

However, in the version included in Sonic Origins, the C press check is not there. Below is an image of a reverse-engineered estimate of what the code for inputs may look like in Origins currently.

In the code that handles cheat inputs, the game looks for 6 presses that are the equivalent to a value of 16 when pressed, followed by Up, Down x3, Left, then Right.

Stealth, also known as Simon Thomley, said the initial input for the 6 presses was a (in engine) C press when he implemented this.

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.

Alongside different positioning for the boss, the wheels also do not actually collide with the ground until the bounce off after defeat.