NTSC vs. PAL--game speed governed by Vblank?

[GradualGames]

Something I've been wondering about---do PAL games actually play/sound a bit slower than NTSC games?

[Disch]

If the game logic and music tempo were not adjusted to work with PAL, then yes.

A good example of this is the J version of Hebereke vs. the PAL version of Ufouria. The PAL version plays significantly slower, but the music is the same pace (the music tempo was adjusted, but the game logic was not). EDIT -- although, now that I try this game again, I don't notice the speed difference. Maybe it was properly adjusted?

I believe the PAL version of Mike Tyson's Punch Out was properly adjusted, though... so it plays about the same as the NTSC version. (Try playing the PAL version in NTSC mode once if you want a challenge!)

[GradualGames]

What would those adjustments usually entail? Different frame count constants for animations, state logic, music ...etc?

[tepples]

What would those adjustments usually entail? Different frame count constants for animations, state logic, music ...etc?

That, and different speed constants for things that are ordinarily updated every frame, such as gravity, accelerations, friction, etc. I wonder if any games have their graphics adapted for the pixels on PAL that are 20% wider than on NTSC.

[Bregalad]

That, and different speed constants for things that are ordinarily updated every frame, such as gravity, accelerations, friction, etc.

Gravity is an acceleraion.

I wonder if any games have their graphics adapted for the pixels on PAL that are 20% wider than on NTSC.

On a limited system such as the NES this is downright impossible (unless you talk about pong or something that uses 2% of NES graphics capabilities), but on modern systems they probably fix that kind of stuff, altough not always, some PS2 games have their hero walk really weirld because they didn't adjust the speed from the NTSC version.

What would those adjustments usually entail? Different frame count constants for animations, state logic, music ...etc?

Basically all timed code waiting constants should be multiplied by 15/16, the music frequency table has to be adjusted, the music tempo shoudl be multiplied by 6/5 and all enemy AI or logic counting frame should be multiplied by 6/5. Also, volume enveloppes in music should be adjusted.
In practice, you don't adjust everything (like if you have something scrolling a 1 pixel per frame it is sometimes simpler to just keep to that speed), and you are forced to round things a liitle (for example if you wait 10 frames in NTSC you can't wait 8.3333 frames in PAL, so you'll wait 8).

[GradualGames]

I presume those adjustments are probably not dynamic---game developers probably make those changes and test them on a PAL system and then release them?

Also, do many homebrew developers bother to make their games work in each mode?

[Celius]

I'll probably make my game PAL compatible (I'm in NTSC land, so I design with that first. And plus, it's more of a challenge to do NTSC with limited Vblank, so get that out of the way first). But by doing this, I must make sure I use 16+ bit coordinates, because I may move something 1 pixel per frame on NTSC, but I have to move it 6/5 of a pixel on PAL, which you just can't do with one integer.

Also, my game will have many benefits working in PAL. One thing will be my polygonal movie engine, which will run quite a bit faster due to the 50 extra scanlines of Vblank. Then I'll be able to squeeze in game like all of the PPU updates I'd ever want to do into 1 regular, unforced Vblank.

Though if somehow you could get your engine to run at 60 Hz while the system is still running at 50, you wouldn't need to worry about acceleration conversion. This might work if for every 5 NMIs you executed your game loop 6. This might result in disaster if you're not careful, however.

And if you want to alter the music, you have to change the speed and pitch. Not to be advertising or anything, but if you care to see which values to store into the sound regs for PAL and NTSC, check out the topic "Square Wave Notes" in NESMusic.

EDIT: Though I say I'll make my game PAL compatible, that's only because it's a big project and I might want to put it on cartridges. If I didn't put it on cartridges, I'd just release it one way or the other because people can choose modes on their emulators.

[GradualGames]

What does your polygonal movie engine do? That sounds interesting. If it has been done before I don't think I've heard of it. Sounds like you've written an engine to dynamically render polygons in the NES and you're going to use it for cut scenes (movies?) that'd just be my noobish guess =)

[Celius]

Yes, my engine dynamically renders polygons for sequences/cutscenes. My intention is to make it look 3D when it's really frames of flat 2D polygons shown one after the other.

Basically I tell the engine to draw a bunch of lines and fill in the spaces between them. I'd always wanted at least wireframe cutscenes in my game, but then doynax, a user here, started a topic in the NESDev section titled "Polygon Filling". In this thread he proved that polygon filling was possible on the NES (and lots more). I was completely in awe. The demos he made were absolutely astounding to me. "Filled polygons would be so fricking sweet to have for sequences!" I thought.

So eventually I decided to make my own engine that could fill polygons. The difference between mine and his are that mine does not run NEARLY as fast, mine does not use illegal opcodes, and more importantly, mine isn't really 3D at all. It takes flat polygons and fills the spaces between them. Also, he says his is a demo, and wouldn't really be efficient to use in a game. I tried to make all of my code fit into 16k of PRG so I could use mine in games. I succeeded, probably sacrificing a fair deal of speed though.

You should seriously check out his demos if you want to see what I'm talking about. It's super cool. And I started a topic "XOR Filling" in the "General Stuff" section. I think there I talk about my engines capabilities more.

[Bregalad]

I'd always make sure that my programms could work fine on both PAL and NTSC. If your raster timing work in PAL and your VBLank timing works in NTSC, then normally the whole thing should work under both. The VBlank is longer in PAL, but the frame is shorter, and the CPU overall slower. Look here for more details.

[tepples]

Also, do many homebrew developers bother to make their games work in each mode?

At least I did at some point in the development of Tetramino. The makefile has instructions to build NTSC and PAL versions, and the biggest difference is the following:

Code: Select all

; game speeds are defined in terms of frames per second (FPS)
; expected speed is the approximate frame time in 3589-cycle units,
; rounded down, and the startup code checks this to make sure
; people don't cheat by playing the NTSC rom on the PAL deck

.ifdef PAL
FPS = 50
EXPECTED_SPEED = 9
.else
FPS = 60
EXPECTED_SPEED = 8
.endif
POST_CLEAR_DELAY = FPS/4
REPEAT_DELAY = FPS/5
LOCK_DELAY = FPS/2

; later in the file:
initial_speeds:
  .byt     250/FPS, 1800/FPS, 12000/FPS, 0
initial_speeds_whole:
  .byt     0, 0, 0, 20

This might work if for every 5 NMIs you executed your game loop 6. This might result in disaster if you're not careful, however.

Frame-skipping might look sort of like telecine judder.