Adjusting animations between NTSC and PAL/Dendy...

[GradualGames]

I'm in the process of refactoring my new game to be adjusted for the currently detected TV system. My approach is to simply store a global value saying whether the clock speed is NTSC or PAL/Dendy. Then, velocities, accelerations, frame counter speeds, etc. are all retrieved from small lookup tables containing the correct values for each clock speed.

It's turning out quite nicely, but I realized that it starts to get not so accurate for fine grained timings such as animations, which typically have a frame-by-frame counter.

What I'm curious about is if anybody goes quite so crazy as to have sub-frame animation speed, much like one would implement tempo in a music engine?

I'm guessing not...that sounds too problematic to me, just as sub-frame speed adjustment for envelopes would create audible sound artifacts...

[Dwedit]

Just run animations twice every 5 frames. Judder is inevitable whenever you need to deal with 50FPS vs 60FPS, so just take the easy way out.

[GradualGames]

Just run animations twice every 5 frames. Judder is inevitable whenever you need to deal with 50FPS vs 60FPS, so just take the easy way out.

Bleh, though. Sounds like on PAL/Dendy animations might suddenly jump to the next frame or if you've got other precise timings in place that match up state machine transitions with animations...I think I'm gonna stick with the lut approach.

[lidnariq]

Having tried the "repeat every 5th frame on NTSC", man does that look ugly.

Other options that occur to me:
* 300fps (300 = LCM(50,60)) and run 5 high-resolution ticks per NTSC refresh and 6 per PAL refresh
* 10fps (GCF) or 12/12.5fps and run one low-resolution tick every 4/5/6 NTSC or PAL refreshes.

[GradualGames]

Having tried the "repeat every 5th frame on NTSC", man does that look ugly.

Other options that occur to me:
* 300fps (300 = LCM(50,60)) and run 5 high-resolution ticks per NTSC refresh and 6 per PAL refresh
* 10fps (GCF) or 12/12.5fps and run one low-resolution tick every 4/5/6 NTSC or PAL refreshes.

I wouldn't have the faintest clue how to begin looking into that approach. Using approximate values is enough for me. For instance, if I have something that is supposed to change an animation frame every 9 frames, using 7 on PAL/Dendy looks close enough. (9 * .83333 ~ 7.49) Undoubtedly the subtle differences between platforms could compound for the whole game and make certain things easier or harder for the player depending. I find that easier to accept than the whole game looking/playing like molasses. Haha (i.e. doing nothing about region differences and letting it just be slow on PAL, as I did in my first game. Second game, I adjusted only for PAL for the music and raster effects, the gameplay was still NTSC timed)

[lidnariq]

Yeah, sorry, let me spell that out more explicitly:

The least common multiple of 50 and 60 Hz is 300Hz. If you had one animation that ran at 300 Hz, you could advance through this table at 5 steps per vertical refresh when rendering for 60Hz output, and advance at 6 steps per vertical refresh when rendering for 50Hz output. If the animation involves physics (gravity) simulation, you may need to actually evaluate the intermediate steps.

The greatest common factor of 50 and 60 Hz is 10Hz. You could redraw the same thing for 5 refreshes on PAL, and for 6 refreshes on NTSC, and it'd be the same. Or, because 12 and 12.5fps is rather close, you could instead just accept the 4% difference and draw the same thing for 4 refreshes on PAL and 5 on NTSC.

[DRW]

Just run animations twice every 5 frames. Judder is inevitable whenever you need to deal with 50FPS vs 60FPS, so just take the easy way out.

I cannot believe that people seriously suggest a way that basically makes the PAL version the original master version while the NTSC version would be the inferior hackjob.


300 fps would probably be the best attempt, but I doubt that you can cram five or six game logic runs into the time of one actual frame.

10 fps is totally unacceptable.

So, I would say:
Program your game for NTSC and leave it at that.

Music adjustment for PAL is fine so that the game doesn't sound like shit on a PAL console.
And raster effect timing adjustments are of course necessary as well, so that the game doesn't glitch.
And if you use the intensity bits for color overlay, you should also keep in mind that red and green are switched around on PAL.

But it's really not worth the hassle to manually adjust the game to that inferior piece of crap that is the European NES.
Back in the day, people were used to a slower game experience on PAL, so you would be authentic here by not adjusting it.
And today, if people still use that stupid European console, there's nobody to blame but themselves.

[GradualGames]

Just run animations twice every 5 frames. Judder is inevitable whenever you need to deal with 50FPS vs 60FPS, so just take the easy way out.

And if you use the intensity bits for color overlay, you should also keep in mind that red and green are switched around on PAL.

This is the first I've learned of red and green being switched around on PAL. Can you elaborate? I've never spotted any significant color differences when testing for NTSC or PAL on the emulators I'm using (FCEUX, Nestopia, Nintendulator) which would make me imagine red and green were swapped (unless I misunderstood).

Maybe it's not worth the hassle, I dunno. It just feels ultra professional to get as close as I possibly can to working close to the same on most any NES, within reason. Like, I've encountered a couple of gnarly timing situations which are probably not worth adjusting between the systems, but a lot of things can be adjusted without too much headache honestly.

[GradualGames]

Just run animations twice every 5 frames. Judder is inevitable whenever you need to deal with 50FPS vs 60FPS, so just take the easy way out.

300 fps would probably be the best attempt, but I doubt that you can cram five or six game logic runs into the time of one actual frame.

Yeah, sorry, let me spell that out more explicitly:

The least common multiple of 50 and 60 Hz is 300Hz. If you had one animation that ran at 300 Hz, you could advance through this table at 5 steps per vertical refresh when rendering for 60Hz output, and advance at 6 steps per vertical refresh when rendering for 50Hz output. If the animation involves physics (gravity) simulation, you may need to actually evaluate the intermediate steps.

The greatest common factor of 50 and 60 Hz is 10Hz. You could redraw the same thing for 5 refreshes on PAL, and for 6 refreshes on NTSC, and it'd be the same. Or, because 12 and 12.5fps is rather close, you could instead just accept the 4% difference and draw the same thing for 4 refreshes on PAL and 5 on NTSC.

I'm trying to imagine how one would actually pull off this 300hz idea. It sounds like it would take some crazy fine tuning of the main loop so that it updates at precisely this speed, not to mention what DRW said, actually getting logic updates to happen 5 or 6 times per frame.

*edit* Oh wait, I understand the 10fps approach...interesting. That'd be super slow animations though wouldn't it?

[DRW]

This is the first I've learned of red and green being switched around on PAL. Can you elaborate?

This is only for the rarely-used intensity bits of PPUMASK. It has nothing to do with the regular color palette.

It just feels ultra professional to get as close as I possibly can to working close to the same on most any NES, within reason.

I go by the philosophy that if the original company and all their third party developers didn't do it, we don't need to do it either. "Super Mario World" and "Street Fighter II" play slower on PAL machines. Why should homebrewers be more pope-like than the Pope?

[GradualGames]

This is the first I've learned of red and green being switched around on PAL. Can you elaborate?

This is only for the rarely-used intensity bits of PPUMASK. It has nothing to do with the regular color palette.

It just feels ultra professional to get as close as I possibly can to working close to the same on most any NES, within reason.

I go by the philosophy that if the original company and all their third party developers didn't do it, we don't need to do it either. "Super Mario World" and "Street Fighter II" play slower on PAL machines. Why should homebrewers be more pope-like than the Pope?

Adding a handful of tiny lookup tables wouldn't be nearly as tough as being godly. In all seriousness though, it's turning out quite well, might as well do it. I was just curious if anybody did/does do anything crazier than simply approximating the same look/feel on PAL. I've seen crazier approaches suggested above, but I'm curious if anybody has actually done it in an actually released homebrew.

[DRW]

I'm trying to imagine how one would actually pull off this 300hz idea. It sounds like it would take some crazy fine tuning of the main loop so that it updates at precisely this speed, not to mention what DRW said, actually getting logic updates to happen 5 or 6 times per frame.

You don't need to update this at precise speeds since it's only about the program logic, not the output.

The idea is simply this:

Instead of calling ProcessGameLogic every frame, you do this:

Code: Select all

if (NTSC)
    updates = 5
else
    updates = 6

for i = 1 to updates
    ProcessGameLogic()

UpdateBackgroundBuffer()
UpdateSpriteBuffer()
WaitForNmi()

In this case, of course you would also have a virtual playfield where one pixel on screen is represented by five sub pixels in memory etc.

But this only works if you have the time to run your logic five or six times per frame, i.e. pretty much impossible.

*edit* Oh wait, I understand the 10fps approach...interesting. That'd be super slow animations though wouldn't it?

Yes. Worse than "Ikari Warriors" which runs at 15 fps if I'm not mistaken.

Adding a handful of tiny lookup tables wouldn't be nearly as tough as being godly.

If you can do this in a relatively easy way, sure, why not? But if I imagine I had to adjust my game for PAL, this would be a huge hassle.

I've seen crazier approaches suggested above, but I'm curious if anybody has actually done it in an actually released homebrew.

Duplicating the fifth frame when running on NTSC was done in "Zooming Secretary".
But as I said, that basically makes the PAL version the clean, as-intended master version of the game and the NTSC version the sloppy afterthought.
Since the NES is a Japanese console and had a much wider release in NTSC regions than for PAL and since today's emulators and hardware clones all default to NTSC, I would never make the PAL version the original version.

I'm not aware of any other methods in homebrews apart from sound adjustment.

[GradualGames]

Adding a handful of tiny lookup tables wouldn't be nearly as tough as being godly.

If you can do this in a relatively easy way, sure, why not? But if I imagine I had to adjust my game for PAL, this would be a huge hassle.

We're making games on the NES. Hassle is our middle name!

[FrankenGraphics]

I go by the philosophy that if the original company and all their third party developers didn't do it, we don't need to do it either. "Super Mario World" and "Street Fighter II" play slower on PAL machines. Why should homebrewers be more pope-like than the Pope?

I can sort of understand that it could be a norm, but basically, they're not the pope. They were just looking for a slightly larger profit margin. The effort of a homebrewer is less thanthat of company that has all this buerocracy, meetings, contracts, the constant expense leak, the need to send yet another a fax to japan to ask if this or that is ok or not, get an approval from some boss to get the original dev team on the line to explain their code... Also, a homebrewer might care more about his/her own craftmanship, while a company just needs to reproduce itself and grow and get their stuff out the door in time for Christmas.

Homebrew = an apple
commercial game = a pear

[DRW]

But then again, one might ask himself: If a gamer in 2017 is contend with using a PAL NES, why should I adjust my game for a better experience?

If he doesn't mind that he plays the classics, those huge names that sold millions of copies, in a slower speed, why should my little homebrew game that maybe sold 50 copies provide this ultra authentic experience where the game plays the same independent from the region?

Gamers who insist on authenticity will get an NTSC console anyway. And everybody who still plays PAL will probably not care that this one homebrew game in his list of 100 NES games has an advanced speed adjustment.