Rewrite scaled time management

[kraflab]

The core of the code managing scaled time (game clock rate above or below 100) is the question "what tick are we on?" The scaled code asked this question based on real time and then scaled the result itself. This means that the answer to the question changed exactly as frequently as the real time result. So if we ran the game at 150% speed, then we'd have the following:

Elapsed Real Time	Real Time Tick	Scaled Time Tick
0	0	0 (0 * 1.5)
1/35 s	1	1 (1 * 1.5)
2/35 s	2	3 (2 * 1.5)

Unfortunately, we never render tick 2, because 1 scales to 1 and 2 scales to 3.

While rates below 100% didn't have the missing tick problem, they still had the problem of the answer changing only as often as 1/35 of a second. If the game is run at 60% for instance, the time between ticks is inconsistent, as shown here:

Elapsed Real Time	Real Time Tick	Scaled Time Tick
0	0	0 (0 * 0.6)
1/35 s	1	0 (1 * 0.6)
2/35 s	2	1 (2 * 0.6)
3/35 s	3	1 (3 * 0.6)
4/35 s	4	2 (4 * 0.6)
5/35 s	5	3 (5 * 0.6)

The new code scales time before answering the question "what tick are we on?"

[kraflab]

@fabiangreffrath Our implementation of the stuttering fix messes up interpolation for slow-mo. Alternate clock rates must be why the code tracking "start of the tick" was implemented in prboom+ in the first place, and investigating that issue is what led me to realize all the tracking of scaled time is broken to begin with😄

I don't know if it's worth adapting all the fixes, since no one complained about the wider issue before, but the interpolation at least needs to be fixed. It's just the line setting frac that assumes there are 35 / 1000 tics in a millisecond that needs to be updated to account for the clock rate.

[fabiangreffrath]

So, you mean this line here needs some TICRATE * realtic_clock_rate / 100 added?

https://github.com/coelckers/prboom-plus/blob/98c3615b0639acc441b6aa8f8425de0eeec79f3f/prboom2/src/SDL/i_system.c#L172

[fabiangreffrath]

@rfomin I believe this also applies to Woof, could you have a look?

[kraflab]

So, you mean this line here needs some TICRATE * realtic_clock_rate / 100 added?

I think that should fix it