This needs to be called unconditionally for every frame being rendered, not all of the game modules did that.
Placing this call here ensures that it is independent of anything the games do.
* rewrote all uses of timerSetCallback. Most were unnecessary or long obsolete, the sound updates need to run per frame, not per tic and the UI tickers need to be handled in the main loop anyway.
* Use a more precise timer to animate the menu transition.
* uncouple other menu animations from the game timer.
This removes most of the InputState class because it is no longer used.
The only remaining places still checking scan codes are the modifiers for sizeup and sizedown.
All the rest was remapped to safer methods. The multiplayer taunts are currently inoperable, they will need support of shift-bindings to get proper support.
* use a CVAR to decide whether to show them at the top or bottom
* draw them on top of the screen border so that they don't get overdrawn on smaller windows.
It will no longer depend on the game state when the menu was opened but the current game state - only on the dedicated menu screen there's no dimming - everywhere else a dim gets applied.
Also renamed GS_DEMOSCREEN to GS_MENUSCREEN for clarity
* Divisor of delta is there so smoothratio always starts off with some kind of value. After 10 minutes at 1100 fps, closest final result to 65536 was:
ototalclk: 4573
totalclk: 4576
gametics: 33.333 ms
elapsedTime: 33.331 ms
ratio: 0.999938
result: 65531.941356
* `displayrooms()` ultimately should be adjusted as well. For now, just relying on integer truncation as this is just a proof of concept.
# Conflicts:
# source/core/gamecontrol.cpp
# source/core/gamecontrol.h
* Hoping the old path being available will allow the new code to be merged.
* Applied offset to sum of `(totalclk - ototalclk)` of 0.5 to ensure calculated smoothratio under legacy path always returns a value.
* For the above, consider Duke 3D with 4 game tics per ticrate, the returned values would be:
0
16384
32768
49152
* With offset of 0.5, the following values are returned depending on how far advanced `totalclk` is from `ototalclk`:
8192
24576
40960
57344
The checks for game pause were totally inconsistent, so now there is a utility function that tells whether the game is supposed to run or not.
pause can also take 3 values now - 0 for no pause, 1 for pause from opening the menu or console or 2 for hitting the pause button.
I never realized it was redundant when consolidating the interpolation math into one function - originally this was done in a way that it wasn't obvious.
This also eliminates the dependency on refreshFreq which never actually made any sense.
The entire method at use here is essentially not correct. Interpolation should be handled independently of the game timer directly based on the underlying clock, like in ZDoom.
There's interpolation bugs in the Build games that cannot be fixed if totalclock is used for it, but if we use something else we do not need a fractional totalclock.
