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.

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.

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.

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.

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!

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.

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?

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.

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?

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.

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.

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).

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.

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.

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.

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!

... 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!

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.

Who is online

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum