[0.6.0-495-g6a9f1e9da] Frame limiter implementation

[mjr4077au]

Because we're on the full backend, there's now multiple frame limiters within the game and they can come into conflict as I believe vid_maxfps is at 200 as well as r_maxfps, but vid_maxfps is not exposed to the menu so unless you know what you're doing, you can't uncap the frame-rate.

Little pissy issue all things considered but just noting it down.

[Graf Zahl]

Yes, this needs to be cleaned up, of course. One good opportunity to get rid of code in the game modules that never should have been there.

[mjr4077au]

Since you've forked the code, they have moved the frame limiter into the engine which does make sense: https://voidpoint.io/terminx/eduke32/-/ ... 436cf05e71

I've tested things with GZDoom's frame limiter and it all seemed to work fine for me (though was really annoyed when I did vid_maxfps 1 but meant to do vid_vsync 1 ).

I can have a crack at removing r_maxfps and associated code if you like? Might be able to hook up SW as well so all the games have a limiter.

[Graf Zahl]

Yes, they moved the implementation into the engine, but the limiter is still being operated from the game side, so it's effectively still all the same. GZDoom's limiter fully sits in the backend, effectively acting like a vsync just without waiting for the sync but a given time interval.

[mjr4077au]

I'd need to extensively test the results of limiting the frames in the backend while the game is calling G_DrawRooms(), G_DisplayRest() etc as fast as possible to make sure there's no funkiness going on there. From my limited (haha, get it?) testing, vid_maxfps seemed to work well.

[Graf Zahl]

Since the game works with vsync on this shouldn't come as a surprise. I think all that needs to be done is to remove the active limiting from G_FPSLimit

[Graf Zahl]

Done. No loss, I'd say. The frame rate limiter never yielded the CPU while waiting, it continues to run full steam ahead and probably made things even worse on the CPU side.