Comment by masfoobar | Hacker News Reader

Comment by masfoobar | Hacker News Reader

> Trivia: Besides the annoying black band, the game code was also rarely revised to account for the VSYNC which occurred at 50.00697891Hz instead of 60.098Hz. This resulted in game running 17% slower than intended. European gaming was a real dumpster fire. But luckily without the internet we did not know about it.

This one hits home. Although my examples are not specific to the Super Nintendo, it reminded me of the first time I played/watch Sonic the Hedgehog on the Mega Drive (Genesis)

I wasnt impressed with the game. It looked clunky and just felt slower compared to the Master System version. It wasn't until the rise of youtube I realised the difference in speed between the NTSC and PAL is huge. Its not just the speed of the game, but the Music. It sounds horrible on PAL!

Don't get me wrong - I knew about the PAL during the 16-bit, and the need for the "black box" but I didn't realise how much of a difference it was. I am sure the console magazines at the time would say the difference is minor in most games. One of the exception (honesty) was DooM on the SNES. The NTSC version had a bigger screen.

I remember being good at Punch-Out when I was a kid on the NES. I could beat Mr. Dream (or Mike Tyson) in the first round. Of course, I was playing the PAL version. If there was some kind of competition in the USA, I would have been destroyed in the first round! I would have been convinced I was framed!

Past times, right?

Super Metroid is a game where the developers did make revisions so that the game would play at the correct speed on PAL consoles. But those tweaks still end up making material differences in gameplay, especially in a speedrunning context, because the slight differences in physics constants and animation timings can make a difference when exploting glitches or race conditions. For example, the slower framerate makes it easier to clip through things, because Samus and her projectiles move more pixels in one frame, so this gate glitch can only be done on PAL: https://www.youtube.com/watch?v=RvyIwtO_qgM

Also, the developers properly adjusted Samus's physics constants and animation timings for the new framerate, but they didn't adjust enemies, cutscenes, or other aspects of the game environment. So Samus moves at the same speed as on NTSC, but the rest of the world moves slower. This means that on PAL you can grab Bombs and escape the room just in time before the door locks, skipping the miniboss fight: https://www.youtube.com/watch?v=R3t8TIIj7IM On the NTSC version, that same skip requires a complicated setup and several dozen frame perfect inputs in a row, and only one person has ever managed to pull it off: https://www.youtube.com/watch?v=jcKUMk5g8Wk

Here's a comparison of the fastest tool-assisted speedruns between NTSC (left) and PAL (right): https://www.youtube.com/watch?v=KD_-thqcB5s Both runs take the same route up until the very end; the NTSC version is faster in almost every single room, but PAL ends up finishing first because the arbitrary-code-execution setups are very different. The NTSC run has to do a very slow sequence of pausing and unpausing to move through a door without activating it, in order to get out of bounds and trigger memory corruption. Whereas on the PAL version, we're able to exploit a race condition in the game's animation system to achive ACE fully inbounds. The race is between a spike's knockback timer and Samus's landing animation; because Samus's timings were revised for PAL but the spike's were not, the timing works out a little differently and the race ends up being exploitable in this context on PAL but not on NTSC.

I absolutely love Super Metroid, but only played it briefly on a Super Nintendo in the 1990's. I've played the NTSC version on emulators for years, and definitely came across timing issues with memory corruption when pausing through a door, but it wasn't even intentional. I always thought developing for different architectures was the only issue developers had to deal with (beyond faster or slower CPU/GPU/RAM), but had no idea that even something like the SNES had issues between NTSC and PAL. This whole comment section has been amazing as someone who loves these classic games, and also enjoys watching speedruns. Gaming got me into software development, even though I never got into that side of development, but your comment and articles like this remind me why development is so interesting (and difficult for the strangest reasons!).

My memory might be a little off but in Australia, because of magazines like 'Hyper' we were made aware of the timing differences but there wasn't anything we could do about it. Thanks for the heads up guys! We could have lived in ignorant bliss!

So when the Dreamcast came along, it was the first to offer games that you could switch between 50Hz and 60Hz but only if your TV could handle it. It also meant that with a lot of games that didn't account for this, you could make things easier by switching back to 50Hz. I recall Crazy taxi being much easier at 50Hz.

Wow, that sounds like it might explain why my timing is always off playing SNES games on emulators. I grew up playing the PAL versions. I always put it down to lag on modern TVs. Be

This is raising the question if emulators are using PAL timings for EU roms. And do we know if the snes mini is giving the NTSC or PAL experience?

It depends on the system and the emulator. The file format most commonly used for NES ROMs does not include region information, so most NES emulators require the user to manually select NTSC or PAL timing to match their ROMs. I think SNES emulators should automatically use the correct framerate though, as the SNES ROM header does include a region field.

The NES/SNES minis always use the NTSC versions of the game, regardless of region.

Thanks for the clarification, it's giving me an excuse for my now totally bad timing at yoshi's island.

I remember being floored when I first heard about speed differences between US (where I grew up) and PAL once I got older.

Seems crazy games would be sold while so different, although it makes perfect sense why the choices were made.

As a kid I had just always assumed Mario was Mario and Sonic was Sonic everywhere. Why would they be different?

Was it the 3D consoles when this finally ended, since rendering and logic were no longer in lockstep most of the time?

No, it was a common issue on PS1/PS2 era 3d consoles as well. It wasn't until we got digital connections like HDMI etc that the PAL/NTSC timing issues went away completely. The disconnect between rendering and logic was not so common back then even in 3d titles, there are many games that just run slower in PAL etc.

> I would have been convinced I was framerated!

Fixed that for you.

You legend.

> Its not just the speed of the game, but the Music.

I get that the game speed depended on the framerate, but playing music at a frequency reduced by 17% would have sounded really horrible, I don't think they would have gotten away with it. But then again, what do I know... The only system I know a bit about is the Amiga, which had dedicated sound hardware, so I'm pretty sure it was not tied to the video frequency, no idea about other systems.

At the time, I would not have figured anything different.. other than I just didn't understand the hype that is the Mega Drive (Genesis)

- The 3-button game controller is horrible, and the D-PAD is worse! - The main mascot game (Sonic the Hedgehog) was clunky with poor music

Of course, if I had experienced the Genesis on an NTSC then my initial view of the machine might have been totally different!

Overall many games I played in the UK - no matter the console... I was happy because I had nothing to compare it to. It's just Sonic the Hedgehog, from memory, was the main one that just felt off. I would not have thought it was a PAL vs NTSC thing.

Reply on news.ycombinator.com