Hard framerate cap of 35 fps using VBLCOUNTER

[erysdren]

I tried this in my ROTTEN port, and it seemed to make the physics & lookup/lookdown behave a little better. It even fixed demo desync! I don't know if this the best solution, but it does get the game to run at the "intended" framerate (as far as i can see from the original source). Thoughts are appreciated.

[fabiangreffrath]

Thanks for looking into this!

So, I assume that there are functions which update the game state per rendered frame instead of calculated game tic. And now that you've changed the code to wait with the next rendered frame until the next tic is calculated, things are in sync again. This doesn't sound surprising, I think the projectile movement in Wolf 3D is also bound to rendered frame instead of game tic and thus goes out of sync for any other than the original frame rate. Do we know which function is affected in ROTT?

May I ask which specific demo you refer to which gets out of sync before this commit but keeps sync after applying this change?

[erysdren]

WaitVBL(); is called all over the place in the code to wait until the VGA vertical retrace has finished before continuing, essentially locking the game's ticrate to the retrace. I don't know how strictly necessary this change is, since the game runs "fine" as it is now, but for the sake of accuracy I still think it's a good idea.

[fabiangreffrath]

I'm afraid this contradicts #22?

[fabiangreffrath]

Thank you!