Internal game frame rate adjustable to 60Hz instead of 70Hz on the SDL2 branch

[GoogleCodeExporter]

I've built OpenTyrian SDL2 branch and I run it on the Raspberry Pi (wich 
received SDL2.0 support recently, including GLES and native DispmanX backends).

The game runs fine, but scrolling is jerky instead of smooth as expected. It's 
not a matter of CPU power: it's just that this game runs internally at 70FPS 
while most common Rpi video modes are 60Hz, thus ruining scroll. It's VERY 
noticeable on the Jukebox, too.

This issue won't be noticed by those running on windowed enviroments like X11, 
because they aren't getting proper double-buffer and vsync support, so they get 
tearing instead, but in SDL2.0, running fullscreen without X11 on the Pi, it's 
VERY noticeable and ugly.

Game speed should be disengaged from frame rate, thus fixing OpenTyrian to run 
smooth on today's 60Hz video modes, instead of the old, unused 70Hz assumption 
wich is no more.

Original issue reported on code.google.com by redwindw...@gmail.com on 5 Oct 2013 at 6:21

[GoogleCodeExporter]

The SDL2 branch should try to use the desktop video mode on whatever monitor 
you tell it to fullscreen in. Does it work properly if you manually set the 
video mode to 70Hz?

I'm also curious, why is it worse running without X11 than with? You say both 
aren't being vsync-ed, so I don't see what would be the difference.

Decoupling the game speed from frame rate isn't something that's going to 
happen. It's too ingrained into the game logic.

Original comment by yuriks...@gmail.com on 5 Oct 2013 at 9:34

[GoogleCodeExporter]

In the first place, there's no vsync in X11 enviroments: you simply got 
asynchronous screen updates, so you get tearing but "smooth" scrolling, even if 
pretty ugly.

Also, in the Raspberry Pi, X11 is unaccelerated: any SDL1.2.x or SDL2 program 
using the X11 backend is slideshow slow.

On the Arm boards running Linux I've seen, it's impossible to change to a 70Hz 
video mode once booted: video mode is established on boot.
So, without a 60FPS mode, we're going to have jerky scroll on most common video 
modes used today.

Original comment by redwindw...@gmail.com on 5 Oct 2013 at 10:40

[GoogleCodeExporter]

I know. In windows instead you have compositing and get jumpy scrolling instead 
of tearing. (Which is IMO worse.)

Since changing the internal game tick rate is infeasible (at least to my 
knowledge, Mindless might want to comment if he disagrees) I'm gonna mark this 
as WontFix.

You could try hacking the source so that is simply runs at a 60Hz tick rate. 
That will change the game speed, but at least it will be smooth. (Not a big 
deal anyways, since you can already adjust the in-game speed via the menu...)

Original comment by yuriks...@gmail.com on 5 Oct 2013 at 11:14

• Changed state: WontFix

[GoogleCodeExporter]

I've been fiddling with the sources, desperately trying to hack the game and 
make it running at a 60Hz tick rate, precissely!

Can you help me on how to do it?
Where's the value? How's it derived?

I found a 70Hz rate in src/lds_play.h:#define REFRESH 70.0f, but that's all. 
It's only for the music player, and I need to change the game speed to 60Hz.

Original comment by redwindw...@gmail.com on 5 Oct 2013 at 11:20

[GoogleCodeExporter]

The timer routines are in nortsong.[ch]. The game speed is calculated in a 
routine in config.[ch], iirc. It consists of a timer update rate and number of 
ticks to wait between frames.

Original comment by yuriks...@gmail.com on 6 Oct 2013 at 7:27

[GoogleCodeExporter]

Ok, Yuri, I got it to refresh screen with a 60.0000Hz refresh rate (60.0017 is 
the exact value in my monitor) by setting float jasondelay = 16.661946f.

But the game is still slightly jerky, showing a desync every few seconds, when 
it should be totally smooth as it's now supposed to be running at the monitor 
refresh rate.

So, in order to fix this final problem, I went and made wait_delay() and 
service_wait_delay() return immediately without blocking on SDL_Delay() calls, 
hoping for the game to run "wild", only blocked by the SDL_RenderPresent() 
function, wich DOES wait for vsync before swapping buffers, thus controlling 
the game speed.
To my surprise, disabling wait_delay() and service_wait_delay() makes the game 
run as fast as the CPU allows: that's wrong, imho. The game should sync to 
monitor refresh rate, something you can rely on if you use SDL2.0. I can 
understand monitor refresh rate is ususally different from 70Hz, so the game 
would run at a reduced speed even if perfectly smooth, but even so, an option 
to run at "monitor refresh rate speed" would be very nice.

Even if you don't want to do that, can you tell me how is it possible that game 
runs "as fast as possible" when the delay functions are disbled if the 
functions SDL_RenderPresent() or SDL_Flip() in old SDL1.2 are supposed to be 
synchronous?
Are the game logic and the video speed control routines running in separated 
threads?

Please, if you're not the person to help me with those questions, I'd be more 
than happy to contact with the adequate developer... I really want to 
understand how all this stuff works and there seem to be some details I'm 
missing here. 

Original comment by redwindw...@gmail.com on 7 Oct 2013 at 2:38

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

As yuriks mentioned, the game logic and frame rate are tightly coupled.  As you 
are no doubt realizing, the mechanism for determining the gameplay speed in 
Tyrian is not simple and, unfortunately, not particularly easy to refactor 
since it is also tied to values in level scripts (level scripts can affect 
gameplay speed).

At Normal speed, the game is supposed to wait 2 70-ish-Hz (1193180 / 0x4300) 
ticks per frame of gameplay, so it's not surprising that the game would run 
fast if you change it to wait for 1 60-ish-Hz tick per frame of gameplay.

Original comment by mindless...@gmail.com on 7 Oct 2013 at 4:40