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

Adjusting animations between NTSC and PAL/Dendy...

Adjusting animations between NTSC and PAL/Dendy...
by on (#209158)
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...
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209160)
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.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209161)
Dwedit wrote:
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.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209162)
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.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209165)
lidnariq wrote:
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)
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209166)
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.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209167)
Dwedit wrote:
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.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209169)
DRW wrote:
Dwedit wrote:
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.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209170)
DRW wrote:
Dwedit wrote:
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.
lidnariq wrote:
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?
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209171)
GradualGames wrote:
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.

GradualGames wrote:
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?
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209173)
DRW wrote:
GradualGames wrote:
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.

GradualGames wrote:
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. :lol: 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.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209175)
GradualGames wrote:
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:
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.

GradualGames wrote:
*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.

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

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.

GradualGames wrote:
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.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209176)
DRW wrote:
GradualGames wrote:
Adding a handful of tiny lookup tables wouldn't be nearly as tough as being godly. :lol:

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! :lol: :lol: :lol:
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209179)
Quote:
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
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209181)
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.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209182)
The truth is i don't mind at all that games are slower here in PAL territory. Can't speak for everyone else, but that's just a natural experience if that's what you have.
Then there's these wonderful glitch/speed run streams that wouldn't be if it weren't for PAL/NTSC discrepancies.

Still, in the shoes of a developer, you might simply want to do it because you're something of a perfectionist and want everybody to have a near-same experience of what you've made. And as a consumer of homebrew, i'd recognize and appreciate the effort. It's part the fun to know that what you're playing is someones' labour of love, and this is one of many ways to express that.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209184)
DRW wrote:
Dwedit wrote:
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.

Wouldn't the NTSC version be the "master" if this solution was used, though? PAL is slower, so it'd get one extra "tick" every 5 frames to catch up with NTSC's faster frame rate. You'd effectively be skipping one out of every 6 animation frames, while in NTSC you'd see all the frames.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209187)
tokumaru wrote:
Wouldn't the NTSC version be the "master" if this solution was used, though?

No.

NTSC outputs 60 frames per second.
PAL outputs only 50 frames in the same time.

So, you program the game with PAL in mind, i.e. the slower version.
And on NTSC, you simply duplicate every sixth frame, so that it runs at the same speed as the slower version.

PAL:
1 2 3 4 5 6 7 8 9 10

NTSC:
1 2 3 4 5 5 6 7 8 9 10 10

Making NTSC the master version would mean that you have to cram the 60 frames of one second into the 50 frames of PAL's same second.
This would mean that for every fifth frame, the PAL version has to process two frames at once (i.e. processing two game logic frames and then outputting the resulting graphics of the second frame).

NTSC:
1 2 3 4 5 6 7 8 9 10 11 12

PAL:
1 2 3 4 5+6 7 8 9 10 11+12

Which is pretty much impossible if you actually need the CPU time for game logic. This is only possible for very simple games that require just about half of the CPU time for every given frame.

So, yeah, the output itself can be either way around. But it's about calculating the game logic here.
This one is mundane if PAL is the master version: You simply skip game logic altogether every sixth frame on NTSC.
But if NTSC is the master version, then PAL has to process two game logic steps every fifth frame.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209188)
DRW wrote:
And on NTSC, you simply duplicate every sixth frame, so that it runs at the same speed as the slower version.

Except that the suggestion wasn't to duplicate one frame in NTSC, it was to skip one frame in PAL, via an extra ticket in the animation logic (if I understood it correctly).

This is feasible for animations, but not for gameplay, unfortunately, because you can't count on a PAL console being able to run 2 logic frames in a single hardware frame.

I absolutely refuse to downgrade the NTSC version in any way just to make the PAL version better, but I will try to accommodate PAL if there are no negative impacts on the NTSC original.

For example, in a Sonic clone, that must be able to scroll 16 pixels per frame, I absolutely would not reduce that speed to 13 something pixels per frame so that PAL consoles could do in 5 frames what NTSC consoles do in 6.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209189)
GradualGames wrote:
I'm in the process of refactoring my new game to be adjusted for the currently detected TV system.


While I have nothing to say on the technical aspects, I applaud your dedication toward all NES owners! :mrgreen:

But...

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

Music adjustment for NTSC is fine so that the game doesn't sound like shit on a NTSC computer.
And raster effect timing adjustments are of course necessary as well, so that the game doesn't glitch, that is if you even have enough raster time to do it on NTSC.
And if you use PAL colour mixing, you should also keep in mind that your intended effects may not even work on in NTSC.

But it's really not worth the hassle to manually adjust the game to that inferior piece of crap that is the American NESC64.
Back in the day, people were used to a flickering and juddery mess on NTSC, even with supposed 'fixes' by the cracking groups. So you would be authentic here by not adjusting it.
And today, if people still use that stupid American computer, there's nobody to blame but themselves.

I may have edited that quote a little, just so you get a feel of just how you sound over on this side of the pond.
DRW wrote:
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'd say that's a load of bull. I'd rather say that NES emulators default to NTSC is because the vast majority of the NES's library originated in the NTSC territories. The C64 however, a wholly American computer but I dare say you'd find it difficult to find a modern emulator that defaults to NTSC out of the zipfile. I'd hazard a guess that the same can be said for the Amiga also.

How I seem to see the sentiment from some people, if it's in NTSC then I should be thankful that the bare minimum of music pitch is correct or I should just put up with it or shell out for NTSC equipment.

~but~

Heaven forbid if somebody releases something for PAL... "NTSC version plz!" ad infinitum. NTSC entitlement can really push my button sometimes. Consider it officially pushed.

On a more conversational note, does anybody know of any PAL exclusive titles that made use of the PAL NES's greater vertical screen resolution and increased vblank time to a point where they couldn't be converted to NTSC? Perhaps some extreme edge cases?
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209190)
tokumaru wrote:
This is feasible for animations, but not for gameplay, unfortunately, because you can't count on a PAL console being able to run 2 logic frames in a single hardware frame.

That's what I mean. I added some text to my post after I sent it:
Quote:
So, yeah, the output itself can be either way around. But it's about calculating the game logic here.
This one is mundane if PAL is the master version: You simply skip game logic altogether every sixth frame on NTSC.
But if NTSC is the master version, then PAL has to process two game logic steps every fifth frame.

And that's why it's not really feasable to use the "skip frames" attempt and make the NTSC version the master version. Because frames are not just about output, but about game logic as well.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209191)
Hojo_Norem wrote:
I may have edited that quote a little, just so you get a feel of just how you sound over on this side of the pond.

First of all, I am on your side of the pond. I'm from Germany. And still, I think the PAL NES is not worth supporting apart from simple music adjustment and timings for raster effects, unless you find a general-purpose method.

I specifically bought an NTSC NES and an American CRT TV to have it the authentic way.

Hojo_Norem wrote:
I'd say that's a load of bull. I'd rather say that NES emulators default to NTSC is because the vast majority of the NES's library originated in the NTSC territories.

Which pretty much proves my point:
Most NES games are NTSC, most NES consoles are NTSC, most NES gamers use NTSC.
So, if you're able to create a game that runs equally on both systems, fine. But making the NTSC version inferior, like playing the PAL version normally and duplicating frames on NTSC, is an absolute no-go. PAL NES is a niche product compared to NTSC NES.

Hojo_Norem wrote:
The C64 however, a wholly American computer but I dare say you'd find it difficult to find a modern emulator that defaults to NTSC out of the zipfile. I'd hazard a guess that the same can be said for the Amiga also.

The C64 is an American device that was most popular in Europe, so the situation is a bit more complicated here.
But for the NES, the situation is clear: Famicom + American NES had a much wider market share than European NES. So, downgrading the NTSC version of a game to make the PAL version good is inexcusable.

"Super Mario Bros.", "The Legend of Zelda" and "Mega Man" play slower on PAL.
So, you either have European gamers who got an NTSC device (or modded their PAL console) to get the authentic experience.
Or you have European gamers that still play PAL and don't mind the slower speed.

The former group plays on NTSC anyway, so they don't need speed adjustment.
The latter group wouldn't care about adjustment since they obviously don't care that the console's top titles don't have it.

So, yeah. NTSC is the way to go when it comes to NES and Super Nintendo.

Hojo_Norem wrote:
On a more conversational note, does anybody know of any PAL exclusive titles that made use of the PAL NES's greater vertical screen resolution and increased vblank time to a point where they couldn't be converted to NTSC? Perhaps some extreme edge cases?

"Asterix" for example.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209192)
I wouldn't do the same thing for every game.

If it was menu/turn based, like a strategic thing, it would be relatively easy to change the timings for PAL in a way that didn't affect the game. In this case it's only a detriment that the PAL version plays slower, so it's worth speeding up. (Of course, a lot of things have to go frame-by-frame for smoothness anyway, so some things you just can't speed up properly.)

If it's a platformer, I would normally prefer the 5/6 slower version, so that all the physics stay exactly the same on a frame-to-frame basis and the mechanics are otherwise identical except for the speed. Like even if you calculate a trajectory that's "the same" at the new speed, the actual points you pass through on the arc of the jump are going to be different-- the peaks and tolerances are all moved by this, and it's compounded for every part of the system you adjust the speed for (each enemy, etc.) -- it's a really big change! You have to fully test and tune two games to do it properly.

Speed does affect difficulty, but reaction times are highly variable between humans (not to mention TVs and lag) and hopefully your game's challenge isn't really based on how fast you react (Punch Out is a bad game, IMO). If it's a bit more important "what" you do than "how fast you reacted", it might make sense that a 5/6 slowdown isn't as big a change as simulating the physics with different precision? If your game IS mostly based on reaction time, though, you probably SHOULD adjust the timings for PAL... but I personally am wary about that kind of game to begin with.

Streemerz took the approach to target PAL and just display every 5th frame twice on NTSC. This results in the expected judder and I also thought it hurt input response. As I recall thefox said he wouldn't have done this for any other game, it was just that it was a port of a Flash game that was 50hz originally and he wanted it to match exactly.


Music of course I'd adjust the speed of in either case, though. That's a given.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209194)
Dwedit wrote:
Just run animations twice every 5 frames.

Sorry but with all respect that is due to you, that advice is downright awful. If you really need me to explain why I will but it seems pretty obvious this complicates coding extremely AND will never yield satisfying results.

Quote:
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.

If your goal is however to make actual games that could have been have released back in the day, this approach is awful. Basically you're wasting a lot of RAM and ROM in your cart to accomodate for PAL and NTSC systems. The correct approach is to make your ROM as small as possible and not waste RAM, and make the cart run correctly on either region, and then do another ROM which is ported to the other region.

Things that should be corrected in order of priority from most important to least important are:
  • Raster effects fixed to look OK
  • Music pitch adjusted
  • Music tempo adjusted
  • Gameplay speed variables adjusted
  • Non-gameplay animations adjusted

Most comercially released PAL NES games only fixed the first point, or the first 3 points at the very best.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209195)
Bregalad wrote:
  • Raster effects fixed to look OK
  • Music pitch adjusted
  • Music tempo adjusted
  • Gameplay speed variables adjusted
  • Non-gameplay animations adjusted

Most comercially released PAL NES games only fixed the first point

Sometimes not even that! I still can't believe this game was released like that!
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209197)
DRW wrote:
So, you either have European gamers who got an NTSC device (or modded their PAL console) to get the authentic experience.
Or you have European gamers that still play PAL and don't mind the slower speed.

The former group plays on NTSC anyway, so they don't need speed adjustment.
The latter group wouldn't care about adjustment since they obviously don't care that the console's top titles don't have it.


I would be surprised if the former group even reached a percent even after we had ruled out everyone who haven't used their NES at least once this year.

Also, there's a little bit more nuance to it. For example, i don't care that SMB plays differently on PAL, because that's my authentic experience i had as a child. Compared to it, NTSC feels odd. That version, however one step more original, is just a curiosity item for me.

If a homebrewer, however, made a new game, then it just might matter. Not by much, but by some.

Else, the advice to aim for NTSC is of course the sound if you want to make and sell copies.

If you made a piece of software that'd target PAL specifics, then it'd be another story. But then you'd effectively be restricted to online rom distribution for use with an emulater and maybe do a few physical copies for yourself and your friends and anyone who might be interested despite it only running favourably on a PAL.

tokumaru wrote:
Sometimes not even that! I still can't believe this game was released like that!

And to think i just saw this game (scn release) go for what translates to 89 usd. Well, at least it had its pretty iconic red plastic rental box (all rental games here had the same-looking vhs box with the original box cover cut out and inserted behind a film).
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209199)
FrankenGraphics wrote:
For example, i don't care that SMB plays differently on PAL, because that's my authentic experience i had as a child.

Well, by this logic, if a homebrewer made a new game and decided not to adjust the speed, wouldn't that become your authentic experience as well?

To me, adjusting the speed for PAL makes only sense in one specific case: When you have PAL players who desire to play the game at the correct speed, but on their unmodded PAL console. Everybody else doesn't care anyway.

But if I ever come across one of those people, I would ask them why they desire a speed adjustment in one little game, even though the vast majority of the existing games they use doesn't have this either and they still play the slower versions.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209202)
At least one new post has been made to this topic. You may wish to review your post in light of this.

At least one new post has been made to this topic. You may wish to review your post in light of this.

At least one new post has been made to this topic. You may wish to review your post in light of this.

Dang, this blew up while I was out shopping, and I got ninja'd a few times while composing this reply.

lidnariq wrote:
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 chose the latter approach for Thwaite and RHDE. They both animate certain things on a 10 Hz timer.

DRW wrote:
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.

More countries used PAL 50 Hz or SECAM than NTSC or PAL-M. Oziphantom's previous post mentioned this diagram, which I admit is slightly misleading because it groups Brazil's PAL-M with PAL rather than with NTSC, whose timings it more closely resembles. But 50 Hz (green plus orange minus Brazil) still covers a lot more of the world than 60 Hz (blue plus Brazil). And even if you consider area misleading, I counted countries by population, and PAL 50 Hz and SECAM outnumbered NTSC and PAL-M there as well.

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

Not necessarily. Traditional cel animation is "on twos", which is 12 fps at the North American 24 fps rate or 12.5 fps at the European 25 fps rate. If all the actors have velocities 20% bigger on PAL than on NTSC, and they change cel once every 5 frames on NTSC or once every 4 frames on PAL, you'll end up with the same smoothness as "on twos".

DRW wrote:
Since the NES is a Japanese console and had a much wider release in NTSC regions than for PAL

Are there more PAL famiclones than authentic PAL NES consoles? PAL famiclones such as the Dendy generate 312 lines every 50 Hz, like a PAL NES. But they NMI 21 lines before picture start like an NTSC NES, and the CPU:PPU ratio is 3:1 like an NTSC NES. So my games that compensate for PAL (Thwaite and RHDE) make the same compensations on Dendy as on PAL NES (actor velocities, skipping sixth frame of 10 Hz timer, music speed) except one: music pitch.

Hojo_Norem wrote:
On a more conversational note, does anybody know of any PAL exclusive titles that made use of the PAL NES's greater vertical screen resolution and increased vblank time to a point where they couldn't be converted to NTSC? Perhaps some extreme edge cases?

Asterix and The Smurfs are the best known cases.

Bregalad wrote:
Quote:
My approach is to simply store a global value saying whether the clock speed is NTSC or PAL/Dendy

Basically you're wasting a lot of RAM and ROM in your cart to accomodate for PAL and NTSC systems.

I don't see one byte of RAM as "a lot". As for ROM, it doesn't take a lot of bytes to wrap (say) the tempo upcounter at 3000 instead of 3606. In any case, it'd "waste" a lot less ROM than storing both a complete NTSC version and a complete PAL version of the game in each cartridge.

DRW wrote:
To me, adjusting the speed for PAL makes only sense in one specific case: When you have PAL players who desire to play the game at the correct speed, but on their unmodded PAL console. Everybody else doesn't care anyway.

Or when you want to deter someone from cheating his way to a high score by playing the NTSC ROM at PAL speed.


Just my opinion:

Here's how I'd make a dual NTSC/PAL game, based largely on my experience with Thwaite:

  • Run much of the game engine at 10 Hz, such as advancing sprites to the next cel of animation. This can help with enemy AI as well, as spreading the enemies' think cycles over five frames can seriously ease processing.
  • Increase actors' velocities by 20% and accelerations by 44%. This will cause slight changes to trajectories, as rainwarrior mentioned and as top-level Quake series players exploit. Be sure to play-test your game in emulators at both speeds.
  • Increase music tempo. Pently expresses tempo in rows per minute, allowing it to use a Bresenham algorithm to accumulate rows in a variable until it crosses the platform's frames per minute value. Decreasing frames per minute from 3606 to 3000 keeps everything the same tempo, but I'll admit it gets on the nerve of hardcore 0CC-FamiTracker composers (who prefer to control tempo using a looping sequence of frames per row values, which 0CC-FT calls a "groove").
  • On PAL NES (but not Dendy), transpose everything up one semitone. This should keep everything reasonably in tune unless you're using Sunsoft bass, and if you're using that, you should have enough PRG ROM for two period tables.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209205)
The thing is, GradualGames wants to make his game auto adjust for different systems.

The first few posts are helpful comments on how this could be achieved...

... then one comes along saying, in a nutshell "Don't bother. Code for NTSC. PAL is crap."

PAL is only crap because of the perception generated by the countless numbers of poor conversions ranging from meh to terribad (MM III, as was just demonstrated).

Now I do get that gimping the NTSC experience isn't really the way to go, but do we need full 1:1 logic parity for a game running in PAL? Perhaps I need to elaborate.

I fully understand that a game written originally for NTSC can't be 100% faithfully converted to PAL without things like redrawing of animation frames, etc. Or squeezing the game logic into the slower PAL frame.

Actually, tepples hit it on the head as I was typing. You don't need to get the game to run logic perfect at PAL speed, just adjust the physics to things move at the same speed in PAL as they do in NTSC. It's not going to be perfect smooth, but hey, I was a PC gamer long before I had a job of my own. I'm used to a little stutter in my games if I know there's a good reason for it. I made that Celeron 300A and 3dfx Velocity gfx card last damn it!
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209208)
Hojo_Norem wrote:
... then one comes along saying, in a nutshell "Don't bother. Code for NTSC. PAL is crap."

Ironically enough, it was the guy who usually complains when we don't stick to answering exactly what he asks in his own threads! :lol:

Quote:
just adjust the physics to things move at the same speed in PAL as they do in NTSC.

That's easier said than done.

Quote:
It's not going to be perfect smooth

This is not just about smoothness... Rounding errors in fractional values can significantly change the gameplay from one version to the other... Things like acceleration and jump heights may be affected, and that's pretty dangerous.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209209)
Quote:
Well, by this logic, if a homebrewer made a new game and decided not to adjust the speed, wouldn't that become your authentic experience as well?


Yeah, basically, but it's also a bit more complicated. I've enjoyed homebrew on my PAL nes, and they have served as great entertainment on gettogethers. But unlike when i was a child, there's now the awareness that it plays differently on different systems, so part of that experience is wondering how it'd play on the NTSC. The difference in game speeds might also make a difference for streamed gaming and the audiences' expectancies, in arranged charity speedruns (not that the most important thing is who wins, but anyway) if one is used to PAL speed and the other to NTSC.


Some games may suffer from different timing windows worse than others, like something requiring consecutive timed button presses when swinging a golf club, or if the characters' animation hints at something you're supposed to tap, press or hold in a rythm.

Thinking about it, there's a "secret" to always-successful bomb jumps in metroid which is syncing the taps to the music. I wonder if that's exact or good enough between both NTSC and PAL.

I think making major game play challenges comparable (if not 1:1), like game speed, regardless of system is a worthy cause for those who want to pursue it, even if i think it's mostly a bonus and in no way essential.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209211)
Bregalad wrote:
[*]Music pitch adjusted

I would say if using tuned DPCM (e.g. "sunsoft bass") this is critical, but otherwise you shouldn't adjust the pitch at all. It's better to just leave it so that things like the high bit of frequency (e.g. the "A-3 vibrato clicks") keep their quirks in the same place, etc. The music will have exactly the same meaning at ~15/16 pitch.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209214)
tepples wrote:
More countries used PAL 50 Hz or SECAM than NTSC or PAL-M.

It's not about the countries, it's about the market share of the NES and the general perception.

As a pop culture icon, the NES is mostly perceived in its American form:

When you hear the "Super Mario Bros." theme, you never hear the screwed-up PAL version.
Everybody knows "Contra", but nobody really gives a shit about "Probotector".
When they released "Balloon Fight" on the virtual console, people complained that European gamers got the 50 Hz version.
Also, the speed of the NES matches the 60 Hz that is used in arcades.

Same with Nintendo itself:

Nintendo of Japan is the mother company.

Nintendo of America was lead by the Japanese boss' son-in-law and it's influential for many things that later became popular.
For one, "Donkey Kong" was only programmed because the American branch needed a fresh new game.
And they are the ones who came up with the name Mario.

Now, who was Nintendo of Europe? A bunch of Bavarians who liked to include stupid in-jokes or sexual allusions into the German translations of games.

Also, Nintendo's arcade conversions can only be fully enjoyed on an NTSC machine because American and European arcade games run on 60 Hz.


That's why I would never program a game natively for PAL and then adjust it for NTSC with some half-assed workarounds. The main game is always the NTSC version.

It would be a different story when it comes to C64 games.

Hojo_Norem wrote:
The thing is, GradualGames wants to make his game auto adjust for different systems.

The first few posts are helpful comments on how this could be achieved...

... then one comes along saying, in a nutshell "Don't bother. Code for NTSC. PAL is crap."

You're free to suggest more ways to convert a game from NTSC to PAL.

The only other way I know:

Make the playfield five times as big in memory. (I.e. one on-screen pixel is five virtual pixels in memory.)

Calculate all movement based on this larger playfield.

I.e. if a character in a normal game moves two on-screen pixels per frame, let him move 10 virtual pixels in NTSC and 12 virtual pixels in PAL per frame.

Same with the animations:
Pretend that there are five times as many animation frames. If your characater has three running animation images, make an array of 15 animations and distribute the three animation frames evenly in this array.
Use the array in a circular way (i.e. if you're at entry 15, go back to entry 1) to determine the next animation: On NTSC, increment the index of the array by 5 everytime a change is necessary. On PAL by 6.

Do your game logic calculations, like collision checks, normally, once per frame, based on the current character positions after the calculations.

Afterwards, convert all character positions back to actual screen coordinates for output.

I have no idea how playing this would feel, though.

tokumaru wrote:
Ironically enough, it was the guy who usually complains when we don't stick to answering exactly what he asks in his own threads! :lol:

That's not quite comparable. If I ask a question about suggestions like "Game with a human female main character that is recognizable as a female" and people suggest "Ms. Pac-Man", "Bird Week" or "Metroid", then I'm of course pissed.

But if I'm asking a technical question about some programming issue that I want to do and people say that my line of thought is too complicated and that actual games did a much easier approach than what I have in mind, I often agreed with them and took the easier route.

So, the easier route for this specific problem is: We have 2017. People have access to NTSC versions of the consoles and games. Everybody who strives for authenticity will get a 60 Hz console anyway. People who still use PAL are the ones who accept that games run slower. So, why bother with them? They don't care that "Super Mario Bros." doesnt play at full speed, so they won't care whether your game plays at full speed. Adjusting a game to play exactly alike on both consoles is investing time and energy into a niche market of a niche market.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209216)
Or to put it another way:

DRW is open to "describe the goal" analysis aimed at rooting out XY problems when the question is technical, but not when it involves what the d20 System's Open Game License refers to as "product identity": setting, characters, and the like. Do I understand you correctly?
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209220)
tepples wrote:
Do I understand you correctly?

Basically yes.

When I program a game, there's a lot I can learn from more experienced developers, so sometimes it's necessary to stop people from overambition.

But when I ask about stuff like specific game characteristics for a game that I want to buy, this has nothing to do with learning or experience.
If I want a game with a woman, then I want a game with a woman. People don't need to tell me: "I guess you're probably just looking for a good platformer. How about "Mega Man III"?"
No, it's not about a platformer. Don't tell me what game I'm looking for. I know what I want better than anybody else.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209227)
rainwarrior wrote:
The music will have exactly the same meaning at ~15/16 pitch.


I thought the cycle reset noise during a vibrato occured consistently one semitone above on PAL compared to NTSC.

On a more elusive and maybe less important note; I don't think that the scale of the APU is equal-tempered (if you can call it a temperament since it would not really be intentional). Wouldn't there be an ever so slight difference impacting our perception and emotional feedback? Or is the non-equal temperament shifted proportionately, too? I tried to google and look on the wiki after APU notes in cents but couldn't find it.

Also, i might fool myself but i could sometimes swear some harmonies change their emotional value more than subtly after i've transposed a piece. Part of it is probably timbre (had been easier to detect with sines), but anyway...
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209230)
Though General MIDI provides theoretical pitch bend resolution down to 1/4096 of a semitone, the ear can't hear pitch differences smaller than 6 cents, where a cent is 1/100 of a semitone or 1/1200 of an octave. This means a period or frequency ratio of less than 2^(6/1200) = 1.00335 to 1 will sound like the same pitch. Thus to differ audibly, frequencies have to differ by more than 1 part in 1/(2^(6/1200) - 1) = 288.

The entries in a table generated using a typical equal temperament period table generator script differ by less than half a period unit from the true frequency. This means the approximations will be accurate enough for all periods greater than 144, as half a period value is less than 6 cents. These periods correspond to pitches below the G an octave and a half above middle C. And there's probably at least another octave or two of headroom before the rounding error starts to become noticeably objectionable to anyone without both perfect pitch and obsessive-compulsive personality disorder (OCPD).*

Besides, the whole tuning scale can be sharp or flat, as long as all notes are sharp or flat by the same amount. For example, if an NTSC NES tuning scale is used on a Dendy, all frequencies will be multiplied by 1.773448/1.789773 = 0.9909, making the Dendy log(1.773448/1.789773) / log(2) * -1200 = 16 cents flat. But most people have only relative pitch, such that people hear intervals, not absolute frequencies. If the whole scale is 16 cents flat across the board, only those with perfect pitch and OCPD will care. The same is true of the quick-and-dirty "add 1 semitone" compensation that Pently uses on a PAL NES. The PAL NES plays log(1.662607/1.789773) / log(2) * -1200 = 128 cents flat, and raising everything by a semitone compensates for only 100 of those cents, leaving the whole table 28 cents flat yet internally consistent.


* OCPD is formerly called anal retentiveness. Not to be confused with OCSO, the Orange County Sheriff's Office.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209232)
FrankenGraphics wrote:
rainwarrior wrote:
The music will have exactly the same meaning at ~15/16 pitch.

I thought the cycle reset noise during a vibrato occured consistently one semitone above on PAL compared to NTSC.

One semitone and ~15/16 are approximations of the same ratio here, which is just their respective clock speeds.

So, if you "do nothing" and just let your music play at the new pitch all the "clicks" will be at the same relative pitch they were in the original. Especially if you worked to avoid vibrato clicks, not adjusting the pitch will prevent you from producing new ones.


FrankenGraphics wrote:
On a more elusive and maybe less important note; I don't think that the scale of the APU is equal-tempered... I tried to google and look on the wiki after APU notes in cents but couldn't find it.

The APU doesn't have a scale. You can use it to produce whatever tuning you like, but it doesn't have high precision accuracy. Almost all NES music uses tuning tables in its software that are some approximation of equal temperament, usually at A-440 on the NTSC version at least.

If you wanted a different temperament you can easily rewrite the tables in your player, but due to the low precision most of the usual differences between temperaments have a hard time coming through.

Here's a demonstration I made a while ago of just intonation on the NES, compared to equal temperament:
Attachment:
harmonic_series_compare.nsf [5.93 KiB]
Downloaded 79 times

It's hard to do just intonation well, though, since the frequency divider is kind of in direct opposition of making rational frequency relationships. Works better on an accumulator based chip (e.g. N163, C64).


The DPCM sample playback rates are an exception; they seem to have been intended for an A-440 equal temperament (on both NTSC and PAL) but they botched the loop length implementation, and even if they hadn't the precision is so low that it's not very well tuned anyway (the PAL even has two mistakes in it). Basically as it is the actual tuning is still up to you and how you use the samples.


FrankenGraphics wrote:
Also, i might fool myself but i could sometimes swear some harmonies change their emotional value more than subtly after i've transposed a piece. Part of it is probably timbre (had been easier to detect with sines), but anyway...

If you play something, and then play the same thing transposed immediately, you are comparing the two. That is not the same as just hearing it at a lower pitch on its own. Absent of direct comparison, most humans lack the sense required to know it's even changed pitch. Within a moderate amount, especially just a semitone, it's effectively identical.

A lot of people associate keys with moods/emotions etc. but it's just sentimental rubbish for the most part. On some instruments there's mechanical differences between various keys, of course (e.g. how does that open G sound on a violin), and on non equal tempered tuning the intervals do sound different in various keys, but that's no longer just a simple transposition that's an actual change-- you could reverse-transpose that tuning and get the same effect at the original pitch.

Some people with the absolute pitch sense do have associations with various keys, but even here this is personal/subjective/sentimental. I actually do have absolute pitch, but as soon as I started experimenting with tunings "between" the 12 notes all associations like that melted away for me.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209241)
rainwarrior wrote:
Especially if you worked to avoid vibrato clicks, not adjusting the pitch will prevent you from producing new ones.
That's really useful to know.

But I believe that would pose a problem for percussion. Kicks, toms and snare tones would come off as more soft compared to a NTSC rendition. If this new softer sounds unacceptable to the author, the alternatives seem to be 1)adjusting pitch (and flutter corrections) anyway, or 2)releasing 2 separate versions.

Quote:
If you play something, and then play the same thing transposed immediately, you are comparing the two.
Yeah, i recognise this, but that's not really what i meant. I meant transposing and coming back to it a while later when the memory has cleared, something i do sometimes to not disorient myself. The difference i've thought i've heard might just have been pavlovian, though, unless the even temperament of famitrackers' driver has inaccuracies audible enough which now appears unlikely.

tepples wrote:
Orange County Sheriff's Office
please tell me they were called a police department before someone took notice
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209249)
FrankenGraphics wrote:
But I believe that would pose a problem for percussion. Kicks, toms and snare tones would come off as more soft compared to a NTSC rendition. If this new softer sounds unacceptable to the author, the alternatives seem to be 1)adjusting pitch (and flutter corrections) anyway, or 2)releasing 2 separate versions.

It's a 15/16 pitch reduction, that's all. How much more "soft" do you really think that makes something? This is insignificant, IMO. This is well below the threshold of the many other variations that are involved already. (Aside from NTSC vs PAL differences you've already got balance variations even in the same region, the huge difference in sound between RF out vs composite etc.)

If it was a bigger drop by 3/4 or something like that I'd say it's pretty important to adjust the pitch, but it's not. It's very slight, and because of that I think the advantages of leaving it as-is are pretty strong.

BTW the noise frequencies are all reverse-adjusted by roughly that 15/16 ratio on the PAL hardware, so if you use tuned noise in a way that's relative to the other channels' pitches it again becomes critical to adjust the pitch. (i.e. the noise frequencies are the "same" on NTSC or PAL, no pitch drop.) It's the same situation as DPCM on this, if you're relying on Noise or DPCM tuning you have no choice but to compensate. (I'll never forgive Nintendo for failing to implement PAL DPCM rates on Wii U's VC.)

There are a bunch of other little differences that will manifest whatever you do, e.g. do you tick your macros at a 6/5 rate to compensate the 50/60 Hz difference (and end up skipping frames) or do you leave them slower but more continuous? (Both of these work well in a lot of situations, especially if planned for.) Or as you're suggesting, build a whole new version for PAL. That's the most effort version, but in general I think the "easier" automated versions can be more than adequate, and also allows a multi-region ROM without changing any data.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209250)
Quote:
How much more "soft" do you really think that makes something?

Not sure what i think (i'm probably obsessing over details), but for comparison a semitone lower makes a somewhat decisive difference to wether the tri support for the snare gets a smack that's carried through the mix or not. It's definitely not the end of it if this isn't compensated, but it does mean a change in the % noise / % tone balance of the composite drum sound than originally planned. Ultimately, this is dependent on the total composition and mix so it might not matter less in some other composition, and it's still a pretty small matter on its own anyway.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209253)
DRW wrote:
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.

Streemerz had the PAL version as the master, because the Flash game ran at 50FPS. It repeated every 5th frame to make it 60FPS.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209256)
Dwedit wrote:
Streemerz had the PAL version as the master, because the Flash game ran at 50FPS. It repeated every 5th frame to make it 60FPS.

TBH, I never noticed.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209260)
FrankenGraphics wrote:
Not sure what i think (i'm probably obsessing over details), but for comparison a semitone lower makes a somewhat decisive difference to wether the tri support for the snare gets a smack that's carried through the mix or not. It's definitely not the end of it if this isn't compensated, but it does mean a change in the % noise / % tone balance of the composite drum sound than originally planned. Ultimately, this is dependent on the total composition and mix so it might not matter less in some other composition, and it's still a pretty small matter on its own anyway.

Well, if you have constructed a very careful balance that's fragile enough that less than 10% difference in volume will make or break the mix, it is not robust enough for hardware deployment. The NES is just not accurate in that way. Only emulators are stable and precise enough for this, and it's a frequent reason you get people saying "only play this NSF in --- player, it doesn't sound good in any others."

Like, if I'm dealing with high fidelity recording/composition I love to make very subtle mixes, and I understand the goal there, just you can't actually rely on a real NES to do that, and that's before any regional differences or even thinking about clones. The relative volumes already vary a lot from system to system. It's even worse when you get Famicom expansions into it. (The balance can even change significantly as the system warms up!) Similarly nobody really emulates the effect of RF output but it completely changes the sound too when it's used. As well, the nonlinear volume curves widely used in NES emulators aren't even entirely accurate, to my tests!

Same deal with tuning, like if you wanted to try an experiment in "well temperament" for some arrangement of Bach's preludes/fugues, the NES is the wrong place to do it because its pitch precision just won't cut muster. The relative tuning of the NES and emulators is accurate and stable, at least-- that much you can rely on, just its inputs don't have that much precision.

(Same as trying to use subtle hue relationships as a substitute for intensity on the visual side, or checkerboard dither...)

Actually Bach is a good example for how to write things that stand up well when your orchestration isn't precise. Orchestral separation, counterpoint and independence of lines, etc. his stuff has been played by every piece of chiptune hardware under the sun and it generally plays quite well. When orchestrating for the NES, listen to it with channels muted, and with a channel mixer with things turned up and down randomly, make sure it still works when things aren't as precise.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209268)
Dwedit wrote:
DRW wrote:
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.

Streemerz had the PAL version as the master, because the Flash game ran at 50FPS. It repeated every 5th frame to make it 60FPS.

I know that some games do this. (Especially games by Europeans.) I just don't understand how this can actually be an advice for a developer:
"Design the game around the inferior hardware that is used by fewer players and that mostly only gets used by players who don't care for accuracy or speed differences anyway. Then make some hackjob that results in choppy scrolling when the game gets played on the main hardware."
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209272)
rainwarrior wrote:
The relative volumes already vary a lot from system to system. It's even worse when you get Famicom expansions into it. (The balance can even change significantly as the system warms up!)
Wait, you mean the independend channels in the analog sum circuit vary noticably from unit to unit, not counting expansion audio? :shock: I have two PAL units (have had 3) but never thought of it. I know carbon resistors generally have a larger tolerance, but i didn't knew it'd amount to significant changes in perceived volume. This may also be something that has changed over time and/or vary with manufacturers but my experience is that in a batch of 5% tolerance carbon resistors, most of them stay within 0-2.5% with the rare, occasional "dud" in the 2.5-5% range.

Anyway, i don't think it's a case of "make or break", but a case of preferred representation. Even with something as lo-fi as the APU, there's room for a surprising variation of "sound". You'd still want the "master copy" to sound preferable to your ears.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209275)
There are two audio outputs, one group is the two squares, the other is the triangle / noise / dpcm. So I think you can rely on precise relative output within a group, at least, but not so much between the two groups, and the relative mix is based on the compound error of both, not just one resistor.

A while back I did a small survey having several people record their machines (different NES and famicom machines) and measured the outputs, and this informed the default balance settings in NSFPlay. I don't remember where I put the files right now, so I can't look up the numbers (wish I'd thrown it up on the wiki or something, might be worth revisiting and doing another survey) but there was a pretty significant range.

Famicom cartridges were even worse. In some cases the same game has been seen with different intentional resistor values, not just deviation within tolerance.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209287)
Wow, this thread really took off!

I am taking a look at Streemerz. So, it was said above that it is basically timed for PAL but skips every 6th frame on NTSC?

I can't notice it at all..... *edit* But I just reviewed rainwarrior's mentioning about input response. Yeah I guess if I'm skipping my entire frame, I might lose twitchy button presses and screw over the player. I'll have to test and see. *edit* I can't seem to notice much difference control wise. But then there's the factor I'd be timing the game for PAL and NTSC would be the one with the timing adjustment in place...

Other really good points were made, such as platformers changing subtle differences in trajectories and so on. I've already seen this begin to happen as I'm experimenting with tuning the game for PAL. It actually plays pretty good in PAL without adjustment (except for sound of course) so I've just got to weigh all these options. I'm almost through fully refactoring the game (and the game is not even half done so it wasn't a huge job) to tune the timings but...there are so many factors to consider here. It doesn't sound like the collecting community is going to be up in arms one way or the other.

I was also thinking about doing something like implementing threads using mmc3 irqs and have them fire 5 or 6 times a frame or something like that. All my entities are coroutines; seems like one could take another step and have full blown threads. Problem would be balancing using those irqs with split screen irqs for boss fights (guess you'd have to have a list of irqs to fire and which routine to redirect to...split screen management or thread management....), so I'm probably not going to do anything quite this insane, but it is fun to think about. This way one could do the 300hz animation updates but allow the rest of the game logic to take the normal frame length, perhaps.

I recall finding a copy of Neotoxin's source code once upon a time (which unfortunately I appear to have lost) and noticed it mentioned threads in there. I am not sure if that basically meant "coroutine" like I'm currently using in my games, or if they actually did have a real preemptive thread scheduling scheme in place.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209301)
FrankenGraphics wrote:
I know carbon resistors generally have a larger tolerance, but i didn't knew it'd amount to significant changes in perceived volume. This may also be something that has changed over time and/or vary with manufacturers but my experience is that in a batch of 5% tolerance carbon resistors, most of them stay within 0-2.5% with the rare, occasional "dud" in the 2.5-5% range.
Resistors can change their value dramatically with age. Even if they started as 5% resistors, these NESes and Famicoms are 30-35 years old now, and the resistors could have drifted several more percent.

If any of them were sitting in hot attics for some portion of that time, I'd even say it's guaranteed.

Vishay has a writeup about modern 1% and 0.1% SMT resistors here, indicating that derating after 1 year of worst-case conditions could change an originally-1% resistor by up to 6.5%
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209303)
Quote:
Vishay has a writeup about modern 1% and 0.1% SMT resistors here


Interesting... i'll read that tomorrow. Thanks! Though if it's about metal film resistors, does it compare them with carbon ones?
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209305)
It doesn't seem to, but other sources say that carbon film resistors are approximately like metal film resistors but less precise and less stable. (Hence why carbon film resistors came in 10% and 5% varieties, while 2% and 1% resistors seem to mostly (all?) be metal film)
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209308)
DRW wrote:
Dwedit wrote:
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.


After considering all the feedback in this thread including yours DRW I think I'm just going to tune the music for PAL and leave the game to be somewhat slower.

When I got further along in tuning my game for PAL, I began running into funny situations where the adjustment was going to require totally rethinking some entity logic including for bosses...it actually did turn out to be a bigger hassle than I first thought.

I also tried the dropping every 6th frame approach on real hardware, and it looked too jerky to me.

What I've learned from this thread is there's really no correct way to account for PAL. Letting your game be slower with music corrected is one totally acceptable option, and I think for my particular game it's the best option.

Thanks for all the thoughtful feedback everybody.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209309)
GradualGames wrote:
I think I'm just going to tune the music for PAL and leave the game to be somewhat slower.

This is probably the conclusion most people reach when they realize how complex this task is. In fact, I'd say that other than making the PAL version the master and repeating every 5th frame on NTSC, it's impossible to get games working the same at both frame rates. There are better ways to approach this issue, but the NES is too underpowered for any of those.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209368)
rainwarrior wrote:
I would say if using tuned DPCM (e.g. "sunsoft bass") this is critical, but otherwise you shouldn't adjust the pitch at all. It's better to just leave it so that things like the high bit of frequency (e.g. the "A-3 vibrato clicks") keep their quirks in the same place, etc. The music will have exactly the same meaning at ~15/16 pitch.

I find it noticeable when music plays at the wrong pitch. Other people might not care but I do.

Quote:
Sometimes not even that! I still can't believe this game was released like that!

For Nintendo, gamers from PAL were clearly 2nd class clients until the late 90s. Between horrible 50Hz ports and shitty translations, to manuals which thinks and implies you're stupid. Sony is guilty of this as well, perhaps even worse. But I'm getting off-topic here.

What I wanted to say is that MM3 PAL hironically fixes the music pitch AND tempo (this even create a "glitch" when Protoman appears, as you can hear the music going too far) - but it did not fix raster effects. So in my list 2 and 3 are fixed but not 1.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209377)
Bregalad wrote:
I find it noticeable when music plays at the wrong pitch. Other people might not care but I do.

Due to having absolute pitch I notice immediately that the pitch is different if I've played the other (or even without absolute pitch it's obvious if you play them back to back in an emualtor)... but the question I have is what makes it "wrong" to you? Simply the fact that it's not the same pitch as the NTSC version?

Like, to me if I compose something and listen to it in two transpositions like this, both sound good to me. There's nothing about one sound that becomes inferior to the other for me, and I'm wondering if this is not the case for you? I really do feel that a small transposition like this is absolutely meaningless without some external reference.

(And by comparison, there is something inferior to me about it if you change the pitch tables to compensate and introduce clicks etc. that weren't in the NTSC version. That's why I think it's better to leave it as-is unless there is some other reference that invalidates it like tuned DPCM samples.)


Changing the tempo I understand as a very meaningful change. Same with changing the speed of the game. There are lots of changes that I do think are significant, but not the pitch change by itself.


Though I would say, in many cases when you have two alternatives for something... sometimes both are pretty decent. Like in my current game, I regularly play it in NTSC, PAL, Dendy, stretched, square PAR, NTSC filtered, 480i, etc. and most of these things the difference is obvious between and I could never simulate one with the other, but that's never my goal. My goal is for it to be good if played on any of these. Even the speed difference, I'm not actually sure if I consider the PAL or NTSC version is the superior speed for the game! It plays fine to me at both speeds, and I think there are acceptable ranges for everything.


I am reminded of the problem of localization, i.e. when you take a game from on language to another, the goal is never to give an exact translation, because it's impossible to do this-- there are always too many differences in culture. You only do exact translations in academic work, like when you're trying to explain a historical document. There the aesthetics don't matter, and you can try to explain a whole civilization in a footnote if you need to. With localizing the game, though, the precise meaning isn't what's important, the goal instead is to make something that is good in that language.


...and I mean I'm not defending bad PAL ports, or bad localizations... there's tons of that. Sometimes the 5/6 slowdown does make it a worse game. Sometimes the attempt to compensate for the 5/6 slowdown also makes it a worse game. Sometimes either is "fine" though-- in some cases the port is even improved just by having more time to fix stuff. There are plenty of things that are obvious unintentional errors, especially bugs, but there is also a whole lot of room for things being a little different but still good.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209380)
Quote:
but the question I have is what makes it "wrong" to you? Simply the fact that it's not the same pitch as the NTSC version?

Indeed. It was intended to be played at some pitch, so it's good to reproduce this on PAL. Changing a pitch table is extremely straightforward, so there's no reason not to do it. Basically it's the simplest thing to "port" to PAL NES.

rainwarrior wrote:
I am reminded of the problem of localization, i.e. when you take a game from on language to another, the goal is never to give an exact translation, because it's impossible to do this-- there are always too many differences in culture. You only do exact translations in academic work, like when you're trying to explain a historical document. There the aesthetics don't matter, and you can try to explain a whole civilization in a footnote if you need to. With localizing the game, though, the precise meaning isn't what's important, the goal instead is to make something that is good in that language.

Many older games are translations that are so abyssal they are basically random words without any meaning, this has nothing to do with the technical possibility of translating something 1:1 or not. Of course if the game is amazing it'll still be enjoyable despite making no sense text-wise - and in some cases such as "all your base..." the horrible translation is actually enjoyable. But that's completely off-topic.

Quote:
(And by comparison, there is something inferior to me about it if you change the pitch tables to compensate and introduce clicks etc. that weren't in the NTSC version.

Clicks on vibrato is typically an NTSC-only thing - they happend arround A notes, on PAL that would fall between G and Ab, so usually clicks are avoided - how is removing clicks not a good things ? And besides, good NTSC NES games detune their music slightly on purpose to avoid this ;)

Another issue you forgot to mention is very-high pitched notes where the rounding to integer actually detunes the notes significantly. Changing the pitch table will obviously affect this significantly, for the better or the worse.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209383)
Bregalad wrote:
Clicks on vibrato is typically an NTSC-only thing - they happend arround A notes, on PAL that would fall between G and Ab, so usually clicks are avoided - how is removing clicks not a good things ? And besides, good NTSC NES games detune their music slightly on purpose to avoid this ;)

Another issue you forgot to mention is very-high pitched notes where the rounding to integer actually detunes the notes significantly. Changing the pitch table will obviously affect this significantly, for the better or the worse.

I don't have a ready survey of vibrato clicks on PAL, but I've seen many Famitracker tracks that are "click free" in NTSC (because they were composed knowing not to do vibrato on A-3 / A-4) and suddenly have new clicks when you put it in PAL mode (equivalent to just replacing pitch table and compensating tempo). It is true that the break point is a little further from the A-440 pitches on PAL, so it could be less likely to happen but only for the case where the vibrato is not very strong. I've done several multi-region music compilation carts at this point, and new clicks in PAL was a significant problem on all of them. So... my experience directly differs on the idea that this is "an NTSC-only thing".


I have seen some people in Famitracker put a temporary pitch detune on an A-3 so they can use wider vibrato on it, but that also has the minor negative effect of putting that note out of tune (and requiring more data, and an engine that supports the detune effect-- not famitone). You could also shift the whole pitch table away from A-440 so it's further away from the base pitch, but again only addresses weak vibrato, and it's not something Famitracker can do. ...or you can transpose your whole track up or down a semitone or two just so the note you want to put vibrato on isn't A anymore-- which is also in the same category of why I think it's acceptable to just use the lowered pitch for PAL: just straight up transposing a whole song up or down after composing it is something that is done ALL THE TIME by professional and amateur composers alike. People even frequently requested a feature for Famitracker to automate that.

As for stuff that actual commercial games do... when I made the NSF import tool, as a consequence I ended up having a really good look at the tuning of a hundred or so games that I tried it with. Nearly every single one was tuned to A-440 (though sometimes the rounding method varied), and the only counter-example I can remember offhand is Drac's Night Out (which has very strange tuning).

So, no I wouldn't say that "good" NTSC games detuned it at all, I don't think any commercial game did this, not for avoiding clicks. Many games had detune effects just for a "chorus" sound (e.g. Startropics is full of this) but that has nothing to do with avoiding vibrato click.


Yes, the difference in precision at high pitches is also a problem, or really the difference in precision at all pitches, but most prominently at high pitches. By keeping the pitch table the same all the same interval relationships are maintained exactly. Replacing the pitch table changes them all. For example, if you use a pitch envelope that's supposed to bend from one note to another... if you replace that pitch table it will be badly out of tune for PAL! You would have to replace the envelope too! It also affects the perceived strength of vibrato as well, and a number of other minor things... I mentioned the clicks as an example because it's well known, but there's like a hundred little issues here and I was not trying to be exhaustive.

I forget if I mentioned before, but the other good reason not to change the pitch tables if you don't need to: you can make a multi-region cart without having 2 copies of the pitch table.


On a side note, what about PAR? Tepples has a theory that Dr. Mario's magnifying glass title screen is supposed to be a perfect circle at the standard NTSC PAR. Does failing to redraw this for the PAL version make it inferior?

Since PAL has a different colour gamut, should PAL versions also adjust their palettes to match the artists original intentions?


Bregalad wrote:
Indeed. It was intended to be played at some pitch, so it's good to reproduce this on PAL.
...
rainwarrior wrote:
With localizing the game, though, the precise meaning isn't what's important, the goal instead is to make something that is good in that language.

Many older games are translations that are so abyssal they are basically random words without any meaning, this has nothing to do with the technical possibility of translating something 1:1 or not.

I wasn't making a comparison against bad translations, though. I was talking about good localizations, which are never a precisely accurate translation of the original: there are always things that work better if you let them be adapted. The comparison is that your reason that the unadjusted PAL pitch makes it inferior seems to be entirely just that it's not the same as the original version, and my argument is that this is not by itself enough reason to call it wrong.

It's also similar to what I was mentioning about pixel aspect ratio. Technically it's all at the "wrong" aspect if your goal is to match the NTSC version as closely as it could, but in reality anything you do to redraw the art will probably have a detrimental effect. I feel more or less the same way about adjusting the pitch tables-- it changes a lot of relationships in the music, which maybe are more subtle than the PAR case but it's still a random jittering of all the intervals in the piece, which I think are best left intact. Transposition instead of degradation. The pitches are being jittered the same way pixels would if you redrew them with another PAR, just a little less obviously.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209385)
rainwarrior wrote:
I have seen some people in Famitracker put a temporary pitch detune on an A-3 so they can use wider vibrato on it, but that also has the minor negative effect of putting that note out of tune (and requiring more data, and an engine that supports the detune effect-- not famitone). You could also shift the whole pitch table away from A-440 so it's further away from the base pitch, but again only addresses weak vibrato, and it's not something Famitracker can do. ...or you can transpose your whole track up or down a semitone or two just so the note you want to put vibrato on isn't A anymore-- which is also in the same category of why I think it's acceptable to just use the lowered pitch for PAL: just straight up transposing a whole song up or down after composing it is something that is done ALL THE TIME by professional and amateur composers alike. People even frequently requested a feature for Famitracker to automate that.

Funny you mention this.

Not having access to the detune effect, i've used detuned envelopes to avoid the troublesome flutter in NTSC mode. Sometimes they remain useful outside that context which justifies it, but (as you might remember from a recent discussion), i'm basically overusing instruments, and there's a cap on 3F instruments in famitracker no matter how well they reuse envelopes, so this isn't really viable anymore. I was thinking of hex editing famitracker to "correct" the pitch table in some direction by a few cents (as to achieve "What you hear is what you get" if using a different table outside FT).

Just transposing the songs that use the troublesome notes would be easier, but i try to use a variety of keys as to impose a sense of difference between areas. I'm probably not going to end up using all 12 keys, but having the freedom to move around freely without being afraid of touching the trouble notes is somewhat valuable to me.

Quote:
Since PAL has a different colour gamut, should PAL versions also adjust their palettes to match the artists original intentions?

Should is a strong word in this context - but just sometimes maybe that could be beneficial. But palette data changes are probably going to differ more than gamut differences, so it'd be if the new colour was somehow closer to what the artist had in mind or would find favourable than was made available in the NTSC version.

lidnariq wrote:
These NESes and Famicoms are 30-35 years old now, and the resistors could have drifted several more percent.


Some extrapolated points from this discussion and that paper:
-Carbon resistors are thought to be somewhat like metal film resistors except the manufacture process makes them vary a lot more, so they also have to sample and sort them in classes of tolerances up to 10%.
-Worst case scenario, metal film resistors can drift a lot
-Worst case scenario, under the responsibility outside the component factory, mostly means using the wrong component in wrong application*, and soldering for too long.
-*Basically, use a resistor that is able to dissipate heat/prevent buildup at the rated wattage required. Larger sized resistors = better heat dissipation.
-The single most important factor is heat. Most of all, drift/degradation seems to occur at high internal temperatures. 55 degrees could be a reasonable internal temperature during operation, at which degradation happens over time. Could also be a lot hotter, or colder. The paper is measuring and predicting based on 55 degrees, and 125 degrees.
-Storage temperature would be around 12-30 degrees of ambient heat, depending on environment and storage type?
-The scale of degradation is ppm (parts per millon) over 1000h (usually commercial) to 5000h (usually medical/military). ppms measure anywhere between 20 and thousands depending on alloy, class, hours, and temperature (55 or 125).

It seems to me resistors wouldn't degrade by much at all in normal ambient temperatures. On the other hand, storage time is constantly ticking.
Resistors seem to mostly drift with use/when warmed up, especially when excessively heated. In other words: leaving your nintendo on overnight repeatedly might be mildly bad for your resistors.

If those resistors were hand soldered, there might be deviancy if someone working at the assembly line was inconsistent in timing when soldering, as those levels of heat are well above the point of excess.

While i personally would measure and match resistors in my synth projects if it had some significant bearing towards timing/pitch, filtering or volume (and sometimes counteract temporary in-use drift with thermally coupled thermistors), i doubt the plant making NESes and famicoms had a process for sorting duds out/matching deviances. Likely, they just went with a tolerance class that was acceptable for the task (likely 5% or 10%).

Edit: corrected some typos
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209389)
rainwarrior wrote:
I have seen some people in Famitracker put a temporary pitch detune on an A-3 so they can use wider vibrato on it, but that also has the minor negative effect of putting that note out of tune

I don't see any benefit in detuning only the problematic A notes, it makes much more sense to detune the whole game to me. I'd thought that practice was common but apparently it's not - so I'm guilty of having assumed that. Personally I didn't hesitate to detune my whole sound engine a little to avoid that problem.

Quote:
just straight up transposing a whole song up or down after composing it is something that is done ALL THE TIME by professional and amateur composers alike.

I had no idea really - I'm a very amateur composeer but I think it's natural to leave song in the keys they came to me. A music tune always sounds quite different when transposed.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209394)
bregalad wrote:
I think it's natural to leave song in the keys they came to me.


In performed music, you need to transpose a piece to fit the optimal range of instruments used. The instruments themselves will have different timbre depending on key, and they might be easier or harder to perform depending on key.

For a singer, this is especially true as timbre, ease of performance and delivery changes a lot depending on key.

In a program of musical pieces, performed or recorded, you may want to transpose because you want to achieve a dramatic (or nondramatic) effect between two pieces played in a consecutive fashion without much of a pause.

I think transpositions up to a second are fairly "transparent" if you allow time to pass, but anything beyond that will usually affect the overall impression (ie. the composition feels "dark" or "bright", some countours start to feel accented because of the instruments' musical properties). Also, an open string will sound just slightly different to one held by a finger.

On the NES, i think the most obvious thing to notice is the tri channel with all it quirks. It can sound quite different even after a somewhat modest transposition.

Those with absolute pitch may experience the transposition of a whole song as a bit "painful" because they've gotten used to hearing it in a certain key, and may need time to digest the change.
Or worse, imagine having absolute pitch and be singing in the choir - those, especially amateur choirs, are very prone to slowly and steplessly falling or rising in pitch without the aid of instruments.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209399)
A lot of interesting things here.
For information, and if it can help anyone, I'll explain what I'm doing in Twin Dragons since Derek (Gradual Games here) asked me on Twitter.

I'm using two arrays where I store all my speed and acceleration values (16 bits). One for NTSC and one for PAL.
Something like that :

Code:
actorsPalSpeeds:
    .word PLAYER_WALK_X_ACCEL
    .word PLAYER_WALK_X_DECEL
    .word PLAYER_WALK_MAX_X_SPEED
    ........

actorsNtscSpeeds:
    .word PLAYER_WALK_X_ACCEL*50/72       
    .word PLAYER_WALK_X_DECEL*50/72       
    .word PLAYER_WALK_MAX_X_SPEED*50/60   
    ........

actorsSpeeds:
    .word actorsNtscSpeeds, actorsPalSpeeds, actorsPalSpeeds ; NTSC, PAL, DENDY


Then I'm using constants for the values :

Code:
PLAYER_WALK_X_ACCEL      = $0040
PLAYER_WALK_X_DECEL      = $0080
PLAYER_WALK_MAX_X_SPEED  = $0220
........


And finally, I got other constants to index everything :

Code:
PLAYER_WALK_X_ACCEL_IDX      = $00
PLAYER_WALK_X_DECEL_IDX      = $02
PLAYER_WALK_MAX_X_SPEED_IDX  = $04
........


Then in my boot code I'm doing this :

Code:
    jsr detectTVsystem ; 0 : NTSC / 1 : PAL / 2 : DENDY

    asl
    tax

    lda actorsSpeeds+0,X
    sta ptrActorsSpeeds+0
    lda actorsSpeeds+1,X
    sta ptrActorsSpeeds+1


And finally when I need to update speed :

Code:
    ; X = actor index

    ldy #PLAYER_WALK_X_ACCEL_IDX
    lda actorSpeedLo,X
    clc
    adc (ptrActorsSpeeds),Y
    sta actorSpeedLo,X

    iny
    lda actorSpeedHi,X
    adc (ptrActorsSpeeds),Y
    sta actorSpeedHi,X


(I'm actually using a variable to store the speed index used with Y).

It may seems heavy, but it works pretty well so far, and the difference between the two console is totally acceptable, even hardly noticeable I would say (at least for me).

I'm doing the same thing for frame counters (PAL_SPEED*60/50 in this case); when I need timers, or for cutscenes for example.
Fun fact : I'm always testing the game using NTSC settings, and once in while using PAL to check that everything is working the same.

I'm not saying here that it's THE way to do thing, or the BEST way, it's just the way I'm doing it for Twin Dragons, and I'm happy with the result. Every game is different and may need a different approach. However, I think that offering (quite) the same gameplay on PAL or NTSC consoles is a plus and a good way to add polish to a game. I don't understand why PAL users shouldn't be considerate, I know that it's more work to do on our games but it's not like people here are trying to release new games every 6 months.

Well, that was just my point of view :)
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209413)
rainwarrior wrote:
On a side note, what about PAR? Tepples has a theory that Dr. Mario's magnifying glass title screen is supposed to be a perfect circle at the standard NTSC PAR.

Putting actual numbers on this: The ring at the lower left corner during gameplay has an outer diameter of 72x80 pixels (9:10) and inner diameter of 64x72 pixels (8:9) on NES. On Super NES, it has an outer diameter of 70x80 pixels (7:8) and inner diameter of 50x60 pixels (5:6). All these appear to approximate 7:8 (inverse NTSC PAR) closer than 13:18 (inverse PAL PAR).

I don't consider redrawing everything to be quite as necessary in games that don't use real-time scaling and/or rotation as in games that do. Correct vertical stretching would improve something like On the Ball, a racing game that rotates the entire background every frame using the Super NES's affine mode. The same is true of anything using the Neo Geo-style sprite shrinking method I prototyped earlier.

FrankenGraphics wrote:
In performed music, you need to transpose a piece to fit the optimal range of instruments used.

Case in point: The SN76489 in the Game Gear is missing the bottom octave of the 2A03's pulse channel. This means it can't play notes lower than what NerdTracker II and FamiTracker call A-1 or LilyPond and Pently call a,. This led the team porting Zoop to Game Gear to transpose the BGM "Uptown Meeting", which is in C on 16-bit platforms, up a major third to E in order to move the subdominant up from F to A. (It also affected the Game Boy version, as presumably the LR35902 and Z80 code bases were similar enough.)
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209422)
FrankenGraphics wrote:
In performed music, you need to transpose a piece to fit the optimal range of instruments used.

As a player you don't need to transpose anything - the arranger does. You play your music sheet as the aranger decided to. That's what a PAL NES is supposed to do - if the game says "I want to play an A note" then it should play an A note, not a G note.

I see rainwarrior's point in that by adjusting the pitch table it can still sound a little different than the NTSC original - however by not transposing it it will also sound different due to lower pitch, so it's a matter of preference. Guaranteeing music to sound 100% identical across versions is basically impossible.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209432)
Bregalad wrote:
FrankenGraphics wrote:
In performed music, you need to transpose a piece to fit the optimal range of instruments used.

As a player you don't need to transpose anything - the arranger does. You play your music sheet as the aranger decided to. That's what a PAL NES is supposed to do - if the game says "I want to play an A note" then it should play an A note, not a G note.

As a professional musician, having to transpose at sight is actually a very common request. Especially if you play accompaniment for a vocalist, very frequently they will need it transposed to fit their range, and they would almost never have a copy of the music already transposed for you. (For the most part, a vocalist transposing is as easy as just giving them another starting pitch, a consequence of most people not having absolute pitch.) It also comes up a lot if you play in a pit orchestra where very often you don't have the same set of instruments as it was originally written for, and when you substitute one instrument for another it's often written at a transposing pitch.

Of course, as an amateur there is not much compelling you to learn to do this. It's just as easy to refuse the task of transposing at sight if there's no job on the line for it. Similarly if you're writing music for amateurs to play, you really shouldn't expect them to have this skill, because most won't.

FrankenGraphics wrote:
Those with absolute pitch may experience the transposition of a whole song as a bit "painful" because they've gotten used to hearing it in a certain key, and may need time to digest the change.
Or worse, imagine having absolute pitch and be singing in the choir - those, especially amateur choirs, are very prone to slowly and steplessly falling or rising in pitch without the aid of instruments.

Yep. As someone with absolute pitch, I was used to relying on it for performance for a long time (I started with piano), but over time I experienced a lot of situations where I had to learn to "turn it off" and go 100% by relative pitch. For instance, if a piano hasn't been tuned in a while and its overall pitch has sunk, it's not like you can just tune it back up on the spot- you gotta deal with it. I tried learning the saxophone and was initially shocked that C actually made the sound of B flat. Joining a choir and learning to sing was a huge transformative experience too, because yeah they drift all over the place! (I can think of more than one person in my music program who had absolute pitch and dropped out of choir because of that problem.) Not to mention learning about other tuning systems, etc. where there's not even 12 notes per octave anymore... at this point absolute pitch is only useful to me for kinda specific situations, and relative pitching skills are the default thing and much more useful to me as a musician.

It's not just amateur choirs, by the way. People seem to have an idea that a "good" choir will not drift, but drift is actually a natural function of certain kinds of harmonic motion. Because of the disparity between just intonation and equal temperament, e.g. a modulation that proceeds one way by a major third but returns by a sequence of fifths must naturally drift to accommodate the tuning of that major third. The ideal choir performance will still shift, just less than the weak choir, and in a more predictable and repeatable way.


FrankenGraphics wrote:
rainwarrior wrote:
Since PAL has a different colour gamut, should PAL versions also adjust their palettes to match the artists original intentions?

Should is a strong word in this context - but just sometimes maybe that could be beneficial. But palette data changes are probably going to differ more than gamut differences, so it'd be if the new colour was somehow closer to what the artist had in mind or would find favourable than was made available in the NTSC version.

Like everything I've said here, I think what's appropriate to do is not a one-size-fits-all situation. I posed the question of palette to stimulate the discussion, the difference in colour is immediately obvious if you play an NTSC and PAL game side by side, but the question for the developer is whether that change is a problem. In almost all NES cases you probably just want to leave the shifted colours where they are, preserving all the existing relative colour relationships more or less? I'm sure there are exceptions, though.

Of course, even without changing region there's a huge range of gamma/hue/brightness/tint/contrast settings across TVs of the same type and trying to be precise is pretty much a lost cause, but you still have people arguing to this day about whether Super Mario Bros. sky is "purple" or not.

FWIW I believe it was somewhat common to have a separate set of PAL palettes for PSX/PS2, where it was more practical to do so (and things like human looking skin tones were more critical), but eventually correcting the colour just became the hardware's job and it's thankfully not really an issue the developer has to deal with anymore.

(It's very analogous to the pitch question... actually just as well it's pretty normal for a graphic artist to do "colour correction" as a final step on a project too, similar to that late transposition thought.)

Same deal with the PAR thing, as tepples has pointed out here and more directly in other threads a square PAR makes rotational symmetry much easier to attain, and otherwise you get some warping effect across the rotation. That's potentially a good reason to compensate for the PAR difference, but it's still a trade-off against other factors. The rotation would need to be a very strong part of your game to want to start taking those trades. Like I doubt anyone would care about Castlevania's gears being elliptical rather than circular, it doesn't negatively affect the game even though it's not "perfect". (And yet again, emulators will give you square PAR, some people play with the image stretched to widescreen, NTSC, PAL, all sorts of factors here make relying on it very impractical.)
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209438)
FrankenGraphics wrote:
It seems to me resistors wouldn't degrade by much at all in normal ambient temperatures. On the other hand, storage time is constantly ticking.
Resistors seem to mostly drift with use/when warmed up, especially when excessively heated. In other words: leaving your nintendo on overnight repeatedly might be mildly bad for your resistors.
Hence my comment about "any NESes that were stored in an attic"—they were quite probably exposed to 50-60C temperatures for many years.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209442)
Wait... all attics i recall, whether in houses or apartment buildings are often below room temperature even during summer, except perhaps locally near the funnel, as the isolation between the attic and the story below keeps the heat locked to save energy and costs warming the house. Sure, Gothenburg is half-cold with moderate summers and more or less constantly moist, but still.

I realize now this might not be the case in places where commonly hot summers and -i guess- other construction principles collide. Googled a bit and saw one who gave an example of 32 degrees outside, a whopping 60C in the attic. That's almost a free sauna, depending on where in the attic that was measured...
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209459)
I agree that for listening to music, only the relative pitches matter. But if you consider that someone might want to play along with your game's music or transcribe it, then you might want to ensure it's in A440 tuning and in an easy-to-play key.

    I remember reading a post somewhere by a person who was transcribing video game music. One thing he found was that the music in Super Mario games was always in the key of C. I figure the composer might have done that to make it easier for people to play along with the music if they want to.

    I remember one time my cousin was playing a Sonic game on his Genesis, I played along with some of the game's music notes on a small keyboard. I remember the game pitches being slightly out-of-tune with respect to the keyboard's pitches. The game's pitches were something like 1/4 or 1/3 of a semitone higher or lower than the keyboard's pitches -- each of the game's notes fit between two keys on the keyboard without matching either of them, but was closer to one than the other. It took me a while to figure this out, because I had assumed the notes would match one of the keyboard keys exactly. (This happened in the US, so in this case, I doubt the tuning mismatch was because of an NTSC-to or from-PAL conversion without music adjustment, it could have just been the keyboard didn't use A440 tuning. But I can imagine a similar problem encountered by a keyboardist playing along with a NES PAL game containing NTSC music that wasn't retuned for PAL.)
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209461)
Quote:
It also comes up a lot if you play in a pit orchestra where very often you don't have the same set of instruments as it was originally written for, and when you substitute one instrument for another it's often written at a transposing pitch.

Then you're basically compensating for your transposing instrument -exactly what I advocate the PAL NES (which is basically a transposing instrument like your saxophone) should do.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209462)
Bregalad wrote:
rainwarrior wrote:
It also comes up a lot if you play in a pit orchestra where very often you don't have the same set of instruments as it was originally written for, and when you substitute one instrument for another it's often written at a transposing pitch.

Then you're basically compensating for your transposing instrument -exactly what I advocate the PAL NES (which is basically a transposing instrument like your saxophone) should do.

Well, yes it is a similar situation in one way, but if we continue this analogy in the pit orchestra if you don't do the transposition you aren't in the same key as all the other players (critical fail). There is an external frame of reference here, which would not be important if playing alone. If you have a DPCM orchestra playing along, on the other hand...

Anyhow, sorry to have gone this far out on the topic of the meaning of transposition, all I'm trying to express is that just transposing a tune down a half step doesn't really make it worse or wrong or bad. I think it's a very reasonable thing to do for a PAL version of a game in a lot of cases, and often the best option. (Nothing applies in all cases, though!)

Bavi_H wrote:
But if you consider that someone might want to play along with your game's music or transcribe it, then you might want to ensure it's in A440 tuning and in an easy-to-play key.

I don't think it's really the goal to help other people play along with it, but it certainly does help for composing if e.g. your piano is tuned the same as your other instruments (like your NES) and you can jump back and forth between them and play together, so that's definitely a good reason to use A-440 tuning while working at least.

Bavi_H wrote:
The game's pitches were something like 1/4 or 1/3 of a semitone higher or lower than the keyboard's pitches -- each of the game's notes fit between two keys on the keyboard without matching either of them, but was closer to one than the other.

Yep! That's something you have to learn to account for if you do transcription. That's actually one of the reasons I had to learn to be able to ignore my sense of absolute pitch, so I could transcribe stuff that was in between the tones.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#209491)
How about leaving the user decide if they want to repeat every fifth frame in NTSC or get a faster experience? It's flicking a switch, no much hassle.

I usually code my games for PAL then adjusto to NTSC, most of the time "the cheap way". I do this mainly 'cause I'm from a PAL region, my consoles are PAL, my TVs are PAL, my friends' systems are PAL, etc. But if I'm planning to release physically and my main target audience is NTSC, I will make the NTSC the main version, of course.

I tend to do everything every frame but update the game state, which I do the first 5 out of 6 frames in NTSC. Most of the time, it works. Specially if the games are non-scrolling. In scrolling games, it doesn't look too jerky if the screen isn't continuously scrolling all the time.
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#221349)
DRW wrote:
And today, if people still use that stupid European console, there's nobody to blame but themselves.

https://en.m.wikipedia.org/wiki/File:PAL-NTSC-SECAM.svg
Re: Adjusting animations between NTSC and PAL/Dendy...
by on (#221351)
... C'mon, don't necrobump just to pick a fight.

1- DRW's complaint was about the idiosyncrasies of the 2C07 specifically. A geographic map of area is wholly irrelevant.

2- That map is astoundingly misleading as pertains to 2C02 vs 2C07 vs UA6538 anyway.


Argentina (50Hz, 3.6MHz PAL) and Brazil (60Hz, 3.6MHz PAL) got their own special PPUs from UMC. Programs that run on Brazil's standard are definitely closer to 2C02 than UA6538.

Comparisons of geography are misleading. Better comparisons would involve cartograms by population or ideally (and unavailable) by total numbers of relevant consoles (i.e. with a cart slot) sold.