PAL vs NTSC

[Sarr.]

i've been searching in the previous threads, but sadly i haven't found what i'm looking for... PAL vs NTSC - i know the theory but how did it work in BD games?

if PAL games are supposed to run slower because 1sec lasts 1.2sec, why is there a difference in one of the BD intermissions that makes it impossible to play on PAL systems? [i've found one cave set and there was a remark about that].

is hatching delay supposed to be longer in PAL versions? [that would explain why PAL version of the intermission is not playable]. if so, and the time runs slower as well, then wouldn't these factors combined produce the same result as NTSC version, only with the 'feeling' of slower gameplay on PAL?

if, on the other hand, hatching delay would be counted in real seconds, and PAL game runs slower, resulting in less cave scans executed during this real time of hatching - shouldn't then teh player be born quicker [quicker considering the game time] and make this intermission playable on PAL and not playable on NTSC?

i'm confused here. some time ago cirix showed me a cave to verify if game physics is implemented properly [http://gratissaugen.de/erbsen/exact.html] and i was grateful for that - now, is there a cave to test if all game timers, PAL timing and hatching delay are implemented properly? how did you guys verify that in your games?

i believe some of you know these things like a back of your hand - it's time to share your knowledge boys and girls, don't be shy! ;]

BR,
Sarr.

[LogicDeLuxe]

Unfortunately Boulder Dash timing isn't reliable to begin with. And there are no "supposed" PAL timings, since the coder only did the game on NTSC machines.
At least BD2 and later count TV fields for cave scan delay, which might result in similar gameplay, only slower. But of course, very rough only.
BD1 is probably the worst since the delay is just a loop to eat CPU cycles. And since PAL uses the lower TV framerate, there are more cycles left and the cave scan can be actually faster on PAL machines. Although, the CPU clock is slightly slower which might counteract the effect a little. I didn't do measurings on this.
XDC introduces reliable timing to C64 Boulder Dash.

[Sarr.]

i've seen a long thread about gdash, improving accuracy, many people testing their sets, and so on. there is this famous BD1/Intermission3 cave which is not playable on PAL settings [tested on vice c64 emu], yet still pretty playable in gdash. the player is spawned just few game scans too early [compared to the c64 on vice].

can anyone explain why?

or, should i ask that in the main gdash thread instead?

BR,
Sarr.

[subotai]

can anyone explain why?

In the c64-game, the timer works independent from the game engine. The timer speed is always the same. The game speed especially depends on animated elements. Many animated elements in a cave will slow down the game speed without affecting the timer speed. Unfortunately, the time of hatching depends on the clock and not on the number of scans that has been performed 'til the start.

Gdash tries to find out the realtime game speed calculating the slow down affected from the elements in a cave. But the result is only an approximate value and hatching is performed a bit earlier as in the original. The calculation in Gdash is pretty good but will surely never be 100% accurate. That's impossible to implement.