Sonic the Hedgehog / GAME HISTORY

Why Can Spikes Hurt Sonic While He's Still Flashing in Sonic 1?

The original Genesis spike routine doesn't check the post-hit flashing timer. It still checks other states, so “spikes ignore all invincibility” is wrong.

By Patchlo Editorial Desk · Published October 20, 2026 · Sources checked October 20, 2026

Scope: Original Mega Drive/Genesis Sonic the Hedgehog, using Sonic Retro's disassembly. Later revisions and remakes can behave differently.

The flashing sprite isn't the whole check

Sonic Retro's disassembly separates the power-up flag, the current hurt state and the flashing timer. In Spikes_Hurt, the original path checks the first two. A check for flashtime appears in the optional bug-fix branch. [1]

That missing check is the important detail. Saying the spike code only looks at Sonic's downward speed misses protections that are actually present.

Watch the landing, not just the first hit

The practical mismatch is between what the sprite tells you and what the next collision allows. Sonic can still look protected after the active hurt state has ended. Contact with spikes can then produce another hit because the original routine doesn't use that remaining flashing time to reject it. [1]

For a useful comparison, keep the camera on Sonic through the landing. A short clip that ends as he bounces away doesn't show what happens next. Also keep the ring counter in view: a second hit and a death are not interchangeable descriptions.

Don't treat every Sonic 1 release as the same test

The disassembly includes revision-specific handling and a separate optional fix. That is a reason to identify the build, not to claim that every later port behaves alike. [1]

If two recordings disagree, compare their release information before blaming the player's timing. The question is whether that version checks the post-hit timer at the next spike contact. “Sonic was flashing” is the starting observation, not the complete explanation.