Here's an old post I made on the subject,
I was thinking of adding uncapped framerate support to Mocha Doom, and I was wondering which approaches/algorithms are currently used.
My current understanding of the matter is as follows:
Any suggestions/comments are welcome.
- The actual gameplay still runs at 35 tics
- "Uncapped" framerate essentially means attempting to render extra frames, if possible, between tics, by interpolating player view position and angle and/or visual monster and platform positions, but not actually modifying them in the gameplay code.
- Rendering extra frames is a "best effort" and opportunistic approach: sometimes it might be possible, sometimes not, and since a-priori knowledge of how long a frame will take to render is not available, some heuristics are needed.
- Rendering extra frames should NOT occur at the expense of gameplay speed, so if not possible to spare time for extra renderin, don't do it.
- I imagine the algorithm to be more or less like this: e.g. render a frame normally, time how long it took to render, and if enough time is left in the current tic to render more, try to render them.
- I can only imagine that uncapped framerate can occur at multiples of the base framerate (35, 70, 105, etc.) and not at any arbitrary rate (e.g. you can't have a 60 Hz refresh rate), since you can only decide whether to render one or more full frames between tics, not a fractional number. Trying to delay rendering in order to achieve non-multiple-of-35 refresh rates must look fugly and jerky :-S
- Non-multiple-of-35 framerates may be achievable on average over a longer period, but not as instant tic rate: during a tic you can either NOT be able to render a frame (skip it), be able to render one, or be able to render more than one, so necessarily at 0x (skip), 1x (normal), 2x, 3x... etc. speed of the base ticrate.
- I presume that multithreading at the tic level is possible: if based on the previous tic you conclude that rendering more frames is possible, you could start e.g. one or more extra threads per tic to prepare several position-shifted renderings of the current gamestate.
Last edited by Maes on Sep 25 2013 at 11:29