This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Getting NTSC and PAL to run at the same speed

Getting NTSC and PAL to run at the same speed
by on (#162959)
What are good ways to create a game, so that the NTSC and PAL version run at the same speed?
Re: Getting NTSC and PAL to run at the same speed
by on (#162966)
You can always simply run the game loop 6 times over 5 frames, but that will stutter and look stupid.

You could adjust parameters in the game so that objects move 6/5 as fast, fixed point math helps here, but it's tricky and error prone, and you sometimes end up with bugs/exploits that only work in one region of the game.

Or you could just say 'screw it' and do nothing to the game speed like 95% of all PAL released NES games. Europe got shafted so hard with crappy ports.
Re: Getting NTSC and PAL to run at the same speed
by on (#162969)
A lot of background tasks in Thwaite and RHDE are on a 10 Hz timer. They run every 6 frames on NTSC or every 5 frames on PAL NES or Dendy.

Thwaite moves the cursor and missiles every frame (60 Hz on NTSC, 50 on PAL). These have their speed adjusted using fixed-point math. Velocities need to be 20% bigger on PAL, accelerations need to be 44% bigger, and times need to be 17% shorter, but for a lot of things, it cheats a bit, multiplying by 19/16 or 13/16 (thus adding or subtracting 18.75%). It also clocks explosions every other frame (30 Hz on NTSC, 25 on PAL), and the number of frames for each of the six cels is set higher on NTSC.

Games using the Pently music engine version 3 or later (Thwaite, Action 53 menu, and RHDE) use a Bresenham-type algorithm to know when to advance to the next row. The tempo value (in rows per minute) is added to a counter every frame, and when that exceeds the TV system's frames per minute (3000 for PAL NES and Dendy or 3606 for NTSC), another row is played. In addition, it transposes music up a semitone on PAL NES only because of its slower APU.

For cursor movement autorepeat in RHDE, I just said screw it. But I did make the playfield update much faster on a PAL NES: 2 frames to copy everything instead of 5, or 1 to copy a single side instead of 3. (I couldn't do the same for Dendy because tapping into post-render time is more complicated.)
Re: Getting NTSC and PAL to run at the same speed
by on (#162978)
I don't think there's one "good" solution, all of them have their compromises.
Dwedit wrote:
You can always simply run the game loop 6 times over 5 frames, but that will stutter and look stupid.

If this is done in a naive way (running the update routine twice in a single 50 Hz frame's time), the processing load will be distributed very unevenly. A non-naive implementation (actually running the internal game logic at 60 Hz and dropping frames to get to 50 Hz) is pretty tricky to pull off since you need a 60 Hz timer source and very careful decoupling of the game logic from PPU drawing. There might be some holes in this idea, I haven't thought much about it. Definitely it'd make the implementation much more complex. I don't think it'd look too bad though (easy to test by recording 60 Hz footage from existing games and converting to 50 Hz with something like AviSynth).

In STREEMERZ the game logic runs at 50 Hz and every 5th frame is duplicated when running on NTSC NES. (Why? Because the original Flash game ran at 50 Hz.) It doesn't look too bad, but giving up the 60 Hz update rate feels wrong given that most of the homebrew market is NTSC.
Re: Getting NTSC and PAL to run at the same speed
by on (#162998)
Another simple option for low-action games would be to design the game around 50Hz, and skip updates (except for vital ones like controller reads, you don't want any dead frames for input) one out of six frames on NTSC. Useless for any games that scroll, but for single-screen puzzle-type games, it could be a workable method. For a game like 2048, the player probably couldn't even notice the difference. Even more so if you delay triggering of an animation if the dropped frame would occur in the middle of the animation (and your animations are short, like 2-3 frames, as that would be the threshold for delaying).
Re: Getting NTSC and PAL to run at the same speed
by on (#163001)
Dwedit wrote:
You can always simply run the game loop 6 times over 5 frames, but that will stutter and look stupid.

I don't think I will have time to update six times in five frames. I fear I'll even need to do some more optimizations in the next days in my game as it is, so I definitely don't have time for rendering an additional frame.

Dwedit wrote:
Or you could just say 'screw it' and do nothing to the game speed like 95% of all PAL released NES games. Europe got shafted so hard with crappy ports.

This will probably be done when I don't find an elegant solution. In this case, I'll only adjust the music. Or let it adjust automatically by setting FamiTone to PAL in the second build of the ROM.

Splitting the code into timed stuff that works independently from the frames per second would require a completely new concept for my game. So, I don't think I can split the tasks.

Also, I don't completely separate game logic and graphics output. O.k., the graphics output is pretty independent. But the game logic does set the ID of the current metasprite/animation frame as well as X and Y for each character.

LocalH wrote:
Another simple option for low-action games would be to design the game around 50Hz, and skip updates (except for vital ones like controller reads, you don't want any dead frames for input) one out of six frames on NTSC.

In my opinion, that's just evil. :evil: I would never create the PAL version as the master version and the NTSC version as some afterthought hack. Either both formats are equally valid (for example calculate the game with 300 frames per seconds and output every fifth frame on NTSC and every sixth frame on PAL, which is obviously not possible on the NES due to processor speed) or the PAL version is the adjusted version.


By the way, what method does the PAL version of "Super Mario Bros." use? As far as I know, this isn't just the NTSC version with altered music, right?
Re: Getting NTSC and PAL to run at the same speed
by on (#163002)
Apart from music, SMB1 has two kinds of changes:
  • A bunch of speeds are increased and frame counts are decreased.
  • The 21-frame task timer is changed to 18 frames.
Years ago, I made an absurdly detailed comparison based on a diff.
Re: Getting NTSC and PAL to run at the same speed
by on (#163003)
The PAL version of SMB1 is pretty much broken, so it's not a good example.
Re: Getting NTSC and PAL to run at the same speed
by on (#163013)
PAL smb1 is broken? How? It's what we grew up on!!!!!!! Is the ntsc version somehow better?
Re: Getting NTSC and PAL to run at the same speed
by on (#163016)
thefox wrote:
I don't think there's one "good" solution, all of them have their compromises.
Dwedit wrote:
You can always simply run the game loop 6 times over 5 frames, but that will stutter and look stupid.

If this is done in a naive way (running the update routine twice in a single 50 Hz frame's time), the processing load will be distributed very unevenly. A non-naive implementation (actually running the internal game logic at 60 Hz and dropping frames to get to 50 Hz) is pretty tricky to pull off since you need a 60 Hz timer source and very careful decoupling of the game logic from PPU drawing. There might be some holes in this idea, I haven't thought much about it. Definitely it'd make the implementation much more complex. I don't think it'd look too bad though (easy to test by recording 60 Hz footage from existing games and converting to 50 Hz with something like AviSynth).

In STREEMERZ the game logic runs at 50 Hz and every 5th frame is duplicated when running on NTSC NES. (Why? Because the original Flash game ran at 50 Hz.) It doesn't look too bad, but giving up the 60 Hz update rate feels wrong given that most of the homebrew market is NTSC.


I would not have guessed. I've spent enough time on your game that I would have picked out things bothering me, but I haven't noticed a stutter at all. You did a fantastic job all around, btw.
Re: Getting NTSC and PAL to run at the same speed
by on (#163069)
tepples wrote:
Years ago, I made an absurdly detailed comparison based on a diff.

Thanks for linking to the list.

Is there any NES game where NTSC and PAL run at the same speed and play the same?
Re: Getting NTSC and PAL to run at the same speed
by on (#163073)
DRW wrote:
Is there any NES game where NTSC and PAL run at the same speed and play the same?

The Codemasters games adapt at runtime to differences between NTSC and PAL NES, but I don't know to what extent they actually scale speed. Thwaite and RHDE do scale most speeds (as I mentioned).
Re: Getting NTSC and PAL to run at the same speed
by on (#163153)
DRW wrote:
LocalH wrote:
Another simple option for low-action games would be to design the game around 50Hz, and skip updates (except for vital ones like controller reads, you don't want any dead frames for input) one out of six frames on NTSC.

In my opinion, that's just evil. :evil: I would never create the PAL version as the master version and the NTSC version as some afterthought hack. Either both formats are equally valid (for example calculate the game with 300 frames per seconds and output every fifth frame on NTSC and every sixth frame on PAL, which is obviously not possible on the NES due to processor speed) or the PAL version is the adjusted version.

Well, of course this idea wouldn't work for scrolling action games. Only low-action games where the skipped update wouldn't be noticeable, and where it would be overkill to do a more advanced optimization. The only way to reverse this quick and dirty cheap method would be to run visual updates twice in one of six frames on PAL (but in such a case on the "double frame" I wouldn't recommend applying input again as you'd get doubled input 10 times a second).
Re: Getting NTSC and PAL to run at the same speed
by on (#169571)
The producer of a game I'm involved with is considering a PAL version as a stretch goal. Like Super Mario Bros., this is a platformer. Other than Super Mario Bros. and Codemasters games, what other NES games ported from NTSC to PAL have their accelerations, velocities, and delays adjusted?
Re: Getting NTSC and PAL to run at the same speed
by on (#169836)
Super Turrican is allegedly another one that adjusts itself to NTSC, but I've never personally verified that.
Re: Getting NTSC and PAL to run at the same speed
by on (#169849)
I've checked it just now: While the music adjusts itself automatically at startup, the gameplay doesn't seem to do:
If you start the game and begin to walk right, the number of frames until you run into the first opponent is exactly 67 frames, no matter if in NTSC or in PAL.
A straight jump takes 57 frames in both regions.

So, no: No gameplay adjustment, only music.