It is currently Tue Dec 11, 2018 4:41 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Tue Aug 28, 2018 5:54 am 
Offline

Joined: Tue Feb 27, 2018 10:41 am
Posts: 20
Location: Brazil
I was thinking about how to synchronize a game speed for both PAL and NTSC systems. My first guess is a kind of "downclocking" the NTSC cpu by skipping 1 every 6 frames to emulate the PAL's 50Hz like this:

Code:
Pseudo code
-----------------
// game loop
while(true) {
   
   // nmiDone is a flag updated during NMI
   // frame is a counter from 0 to 60 updated during NMI
   if (not nmiDone or (system == NTSC and isMultipleOf6(frame) )) {
      continue;
   }

   //game logic
   ...
}

Am I on right direction or totally wrong?
Thanks in advance!


Top
 Profile  
 
PostPosted: Tue Aug 28, 2018 5:56 am 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 2351
Location: DIGDUG
Yes. neslib has a function for this. I think Streemerz uses it.

First you must do (at init) some counting between 2 frames to figure out which system you have (PAL takes longer).

I believe it's count 5 frames, skip the 6th. (Instead of counting to 6).

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Tue Aug 28, 2018 6:09 am 
Offline
User avatar

Joined: Sat Aug 15, 2015 3:42 pm
Posts: 150
Location: France
You can find more information here and here.

_________________
My first game : Twin Dragons available at Broke Studio.


Top
 Profile  
 
PostPosted: Tue Aug 28, 2018 7:14 am 
Offline

Joined: Tue Feb 27, 2018 10:41 am
Posts: 20
Location: Brazil
As you have pointed out, now I see that an "overclocking" can also be emulated by bypassing the "wait for vblank" on every 5th frame of a PAL system.
Now it's all more clear. Thanks again!


Top
 Profile  
 
PostPosted: Tue Aug 28, 2018 7:47 am 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 2351
Location: DIGDUG
Quote:
"overclocking" can also be emulated by bypassing the "wait for vblank" on every 5th frame of a PAL system.


I didn't say that. What I was describing is slowing down NTSC to match PAL.

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Tue Aug 28, 2018 8:46 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7010
Location: Canada
NOOPr wrote:
As you have pointed out, now I see that an "overclocking" can also be emulated by bypassing the "wait for vblank" on every 5th frame of a PAL system.
Now it's all more clear. Thanks again!

I do that for music, but music only takes like 1/20 of a frame normally so it doesn't have much of an impact.

If you're going to double a whole frame's worth of stuff, though, you need to have a game that is underusing the CPU enough that doubling that part of the workload still fits in a single frame... otherwise it will take too long, and that frame that you were trying to get a 2-for-1 in will end up lasting 2 frames anyway. (At the very least, skip building the sprites for the first of the 2 updates, that should cut out some of the workload.) If you end up hitting that slowdown it's worse than if you're just let the game run slower, because instead of seeing 2 frames, you'll see the same frame for 2 frames, and then everything will move twice as fast/far to reach the next frame. It does help a little that there are more CPU cycles per PAL frame, though overall per second it is a slightly slower CPU.

So... as a general technique this is not something i'd recommend. The practice of double-ticking your game engine is simple to write, but the part about managing CPU so that the extra update doesn't produce slowdown that negates is a lot more complex. Also for the user this makes an uneven frame of motion that they didn't get to respond to with new input, and for a smooth action game this will be felt.

For just music though it is a good technique. I do recommend it there. In most cases in PAL I'd probably think just running the game slower is the best compromise (but I definitely think there are situations where it'd be good to adjust the speed).


Top
 Profile  
 
PostPosted: Tue Aug 28, 2018 10:13 am 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7811
Location: Seattle
When I was porting Driar down to NROM (from its original SGROM), I experimented with slowing down the game on 60Hz decks to run at the same 50Hz as the original. As suggested above, it did this by running the engine for 5 vblank, then doing nothing on the 6th vblank.

It looked terrible. It played terrible. The jerkiness was perceptible.


Top
 Profile  
 
PostPosted: Tue Aug 28, 2018 10:33 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 3141
Location: Tampere, Finland
I did it in STREEMERZ out of necessity (the original game runs at 50 Hz, and running it at 60 Hz with the original physics etc constants was unacceptable). I don't think it's too bad in that one (never heard any complaints), but it's not perfect by any means. I'm actually much more bothered by the jerky music than the gameplay (but that could just be me).

In my next game (if that ever happens) I'll probably just target 60 Hz and accept that the PAL version will be slightly slower.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi


Top
 Profile  
 
PostPosted: Tue Aug 28, 2018 1:58 pm 
Offline

Joined: Mon May 27, 2013 9:40 am
Posts: 499
I skip every 6th frame for game logic in NTSC, but not for palette / scroll position update / splits. It doesn't look that bad.

_________________
http://www.mojontwins.com


Top
 Profile  
 
PostPosted: Wed Aug 29, 2018 5:48 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 11:46 am
Posts: 107
Location: Stockholm, Sweden
I've used the skip every 6th frame. I think it looks OK. Best thing is obviously to have all calculations be done from 2 different set of constants that would result in the same behavior in both worlds. But that can become quite messy, take up room and/or be slower if not hard coding constants in calculations.


Top
 Profile  
 
PostPosted: Wed Aug 29, 2018 11:18 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11011
Location: Rio de Janeiro - Brazil
Nioreh wrote:
Best thing is obviously to have all calculations be done from 2 different set of constants that would result in the same behavior in both worlds.

I don't think that's possible with fixed-point math. Every time I try to think of a way to implement perfect PAL/NTSC support I give up in frustration.

I think that if you really need a game to run at the same speed in PAL and NTSC, skipping every 6th frame in NTSC is the only sane option. I would feel bad about sacrificing the smoothness of the NTSC version in favor of the PAL version though, so I wouldn't do it.


Top
 Profile  
 
PostPosted: Wed Aug 29, 2018 11:31 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3720
Location: Mountain View, CA
General question: is there a particular reason this has to be done within a single ROM/game, given that it cannot be implemented and timing and smoothness retained?

Rephrased: why not just have separate NTSC and PAL releases?


Top
 Profile  
 
PostPosted: Wed Aug 29, 2018 11:41 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7010
Location: Canada
Nioreh wrote:
Best thing is obviously to have all calculations be done from 2 different set of constants that would result in the same behavior in both worlds. But that can become quite messy, take up room and/or be slower if not hard coding constants in calculations.

I don't think this is ideal either. It's another compromise. It can solve the "different rate" problem, but introduces a new "different behaviour" problem.

The specific height and lengths of jumps will be different, and the arc passes through a different set of discrete points. A bullet moving farther per frame will do less collision tests against the things it is moving past. Etc. These are all behavioural changes that need to be tuned and tested, and IMO testing is the single biggest task in game development.

Every solution to this is a tradeoff between different kinds of problems. What's ideal depends on which problems affect your particular game the most, but for a lot of action games this is a rock and a hard place. For a menu driven RPG, on the other hand, all of these solutions might be "fine".

...though maybe worth reiterating: doubling every fifth frame to convert PAL to NTSC is a lot less of a problem than skipping every sixth frame to convert NTSC to PAL, at least for interactive things. There's a big difference between missing a whole frame of being able to hit that jump/attack button, and having 2 frames to do it. (However, I think both are an acceptable technique for music conversion.)


Top
 Profile  
 
PostPosted: Wed Aug 29, 2018 11:44 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7010
Location: Canada
koitsu wrote:
General question: is there a particular reason this has to be done within a single ROM/game, given that it cannot be implemented and timing and smoothness retained?

Rephrased: why not just have separate NTSC and PAL releases?

The only problem that solves is where to put and/or how to manage the data. It's mostly only helpful if ROM space is too limited to accomodate the changes you want to include. (There are code conveniences too, but I think they're a more minor issue than ROM space.)

All of the other problems of how to change the game remain, all of them with the same compromises. Changing stuff about how the game works means retesting the whole game, whether or not both versions are in the same ROM.

...and there's several advantages of their being only one ROM, I think especially for PAL region players where you might commonly have access to both kinds of machines in different situations.


Top
 Profile  
 
PostPosted: Wed Aug 29, 2018 12:17 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11011
Location: Rio de Janeiro - Brazil
koitsu wrote:
why not just have separate NTSC and PAL releases?

The problem is not supporting both in the same ROM, detecting the type of the console and using variables instead of constants is the easy part. The real problem is making something that updates 50 times per second and something that updates 60 times per second feel the same to a human being that's observing and interacting with those things.

The math is simple: if a character moves at 1 pixel per frame in NTSC, it'll move 60 pixels in a second - to make that character cover the same ground in the same time at 50Hz, it's gonna have to move 1.2 pixels per frame. The only problem is that 1.2 is not a value you can accurately represent as an 8.8 fixed point value. 1.2 * 256 = 307.2 which rounds down to 307, which represents 1.19921875, not 1.2. Doesn't sound like much of an error, but over time this error accumulates and causes the physics to behave differently. Even 1 or 2 pixels could make the difference between making a jump or not.

rainwarrior wrote:
doubling every fifth frame to convert PAL to NTSC is a lot less of a problem than skipping every sixth frame to convert NTSC to PAL

I think we have a terminology misunderstanding here: I thought that by "skipping every 6th frame" we meant not processing a frame (effectively repeating the 5th frame) for converting PAL to NTSC. "Skipping a visible frame" as in making everything move twice as much every 5th frame to make PAL catch up with NTSC would be way more problematic indeed.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 guests


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

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group