Adjusting animations between NTSC and PAL/Dendy...
Moderator: Moderators
- FrankenGraphics
- Formerly WheelInventor
- Posts: 2064
- Joined: Thu Apr 14, 2016 2:55 am
- Location: Gothenburg, Sweden
- Contact:
Re: Adjusting animations between NTSC and PAL/Dendy...
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.
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.
Last edited by FrankenGraphics on Sat Dec 02, 2017 2:32 pm, edited 1 time in total.
Re: Adjusting animations between NTSC and PAL/Dendy...
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.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.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.
Re: Adjusting animations between NTSC and PAL/Dendy...
No.tokumaru wrote:Wouldn't the NTSC version be the "master" if this solution was used, though?
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.
My game "City Trouble":
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
Re: Adjusting animations between NTSC and PAL/Dendy...
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).DRW wrote:And on NTSC, you simply duplicate every sixth frame, so that it runs at the same speed as the slower version.
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.
- Hojo_Norem
- Posts: 137
- Joined: Mon Apr 16, 2007 10:07 am
- Contact:
Re: Adjusting animations between NTSC and PAL/Dendy...
While I have nothing to say on the technical aspects, I applaud your dedication toward all NES owners!GradualGames wrote:I'm in the process of refactoring my new game to be adjusted for the currently detected TV system.
But...
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: 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 AmericanNESC64.
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'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.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.
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?
Insert witty sig. here...
Re: Adjusting animations between NTSC and PAL/Dendy...
That's what I mean. I added some text to my post after I sent it: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.
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.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.
My game "City Trouble":
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
Re: Adjusting animations between NTSC and PAL/Dendy...
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.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.
I specifically bought an NTSC NES and an American CRT TV to have it the authentic way.
Which pretty much proves my point: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.
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.
The C64 is an American device that was most popular in Europe, so the situation is a bit more complicated here.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.
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.
"Asterix" for example.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?
My game "City Trouble":
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
- rainwarrior
- Posts: 8735
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Adjusting animations between NTSC and PAL/Dendy...
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.
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...
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.Dwedit wrote:Just run animations twice every 5 frames.
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.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.
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
Re: Adjusting animations between NTSC and PAL/Dendy...
Sometimes not even that! I still can't believe this game was released like that!Bregalad wrote:Most comercially released PAL NES games only fixed the first point
- Raster effects fixed to look OK
- Music pitch adjusted
- Music tempo adjusted
- Gameplay speed variables adjusted
- Non-gameplay animations adjusted
- FrankenGraphics
- Formerly WheelInventor
- Posts: 2064
- Joined: Thu Apr 14, 2016 2:55 am
- Location: Gothenburg, Sweden
- Contact:
Re: Adjusting animations between NTSC and PAL/Dendy...
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.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.
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.
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).tokumaru wrote:Sometimes not even that! I still can't believe this game was released like that!
Re: Adjusting animations between NTSC and PAL/Dendy...
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?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.
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.
My game "City Trouble":
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
Re: Adjusting animations between NTSC and PAL/Dendy...
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.
I chose the latter approach for Thwaite and RHDE. They both animate certain things on a 10 Hz timer.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.
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.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.
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".GradualGames wrote:Oh wait, I understand the 10fps approach...interesting. That'd be super slow animations though wouldn't it?
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.DRW wrote:Since the NES is a Japanese console and had a much wider release in NTSC regions than for PAL
Asterix and The Smurfs are the best known cases.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?
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.Bregalad wrote:Basically you're wasting a lot of RAM and ROM in your cart to accomodate for PAL and NTSC systems.My approach is to simply store a global value saying whether the clock speed is NTSC or PAL/Dendy
Or when you want to deter someone from cheating his way to a high score by playing the NTSC ROM at PAL speed.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.
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.
- Hojo_Norem
- Posts: 137
- Joined: Mon Apr 16, 2007 10:07 am
- Contact:
Re: Adjusting animations between NTSC and PAL/Dendy...
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!
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!
Insert witty sig. here...
Re: Adjusting animations between NTSC and PAL/Dendy...
Ironically enough, it was the guy who usually complains when we don't stick to answering exactly what he asks in his own threads!Hojo_Norem wrote:... then one comes along saying, in a nutshell "Don't bother. Code for NTSC. PAL is crap."
That's easier said than done.just adjust the physics to things move at the same speed in PAL as they do in NTSC.
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.It's not going to be perfect smooth