Implement a FPS counter with faster refresh rate

[tigrouind]

The refresh rate of the FPS counter is quite low.

I think it could be improved, here is some ways :

1. every frame, push current time into a queue. Remove items which are older than 1 second.
   FPS is how much items there is in the queue. It's possible to use a different time window (eg: 0.5 sec or 2 sec), you just need to multiply/divide FPS by some constant. Here is an implementation example.
2. push frame time into a queue, dequeue items older than 1 sec. FPS = average of all frame times (moving average).
3. push frame time into a fixed size queue (eg: 60 items). Once queue is full, dequeue oldest item. FPS = average of all frame times (moving average).
4. calculate frame time and smooth it with a low-pass filter (exponential moving average) :
   smoothFrametime = (smoothFrametime * 95 + frametime * 5) / 100

I used the first technique in one of my projects and it give good results. The two first solution are frame rates independent (the way they smooth out values is not impacted by FPS). The two last solutions are frame rate dependent (they will take more time to rise / fall at low FPS vs high FPS).

[viti95]

I like this idea, I'll give it a try

[viti95]

I've created a branch for testing (https://github.com/viti95/FastDoom/tree/faster-fps-updates), I've tested this only on emulators, now it's much more responsive, even with lower framerates. Also I have to check the performance impact of having the FPS enabled on slow systems.

[tigrouind]

I have implemented the first method I described earlier and compared it with your implementation.

It give similar results (both end up showing same FPS once stabilized) and both cap at 35 FPS.
The method I use obviously converge faster to the real frame rate but it's less precise as it only show integers, no fractional part.

I am working on an improved version of it.

[tigrouind]

Here is a video that compare implementations (4000 cycles in DOSBox) :
1st counter : average of frame time (your implementation)
2nd : average of frame time since last second. Branch
3rd : counting number of frames since last second. Branch

2024-08-22.13-10-18.mp4

• 1st method is stable but take a lot of time to reach equilibrium, especially at low frame rates.
• 2nd method is somewhat shaky (eg: it oscillates between two values quickly). 1st can do it as well but considerably less. This is due to timer low precision. A tick is 1000 / 35 = 28.5ms. All implementations are affected by this.
• 3rd method is quite stable and offer fast response time. It's probably as best as it can go with such a low precision timer. Trying to measure subframes precision with a timer that can't go lower than time for a single frame is weird. It can be improved by averaging frame times, but then you got delays.

I'm unsure which method is the best. There is probably a tradeoff between stability and response time.

[viti95]

Looks very promising!! I'll test both implementations this weekend on my 386SX (the slowest system I have). I'm surprised it's possible to update this fast and accurate even on very low framerates.

I really like the 2nd method even if it's a bit shaky. Response time is much better than my average method. What do you think is better?

[viti95]

I've done some testing in both my 386SX@33 and 486DX@80. Both methods work very well and don't take a big hit in general performance (Dosbox usually hides the latency of instructions like idiv and memory latency). The only issue I've found is that the 3rd method (non decimal), caps out at 64 fps when running a timedemo, while the 2nd method shows correctly the framerate with more than 64fps.

[tigrouind]

64 fps cap : if FPS can go above 64 FPS, FPS_STORAGE_SIZE should be increased.

Here is a chart that compare all methods :

• Gray is raw framerate, very unstable (due to low precision timer)
• Purple is a multi-tap FIR filter. This is some sort of "ground truth". Why it's both smooth and responsive is because it can look forward while processing the signal. It's not possible to do the same here (we can't predict frame time in advance).
• Yellow is your method, very stable (due to averaging a large sample of frames) but slow response. It's basically an moving average. It can sometimes slightly overshoot.
• Red is counting frames since last second. Stable but no fractional parts. FPS are rounded up. Branch
• Green is average frame time since last second. Branch.
• Cyan is a new method. It's same as yours (calculate average of frame times) but within a fixed time loop. It's very similar to average of frame time since last second. Branch.
• Amber is a new method as well. It use a low pass filter and a fixed time loop. Branch.

Those methods can be tweaked out (eg: green/cyan: use 70 frames buffer, amber: use 124/4 ratio). It will cause them to be more stable but less responsive (they will get closer to the yellow line). Still, they will lower quickly when the FPS drop because they are frame rate independent.

[tigrouind]

What do you think is better?

If you are OK with zero decimal places FPS : method that count frames is probably the best. It's super fast (CPU wise) and responsive.
If you want fractional FPS : your method is probably the best. It's more stable than other methods, which are too shaky to my taste. Timer precision should be improved to make them usable. Anyway, if they are tweaked to be more stable (eg: by increasing some constant as explained in my previous message) and are proven to be faster (CPU wise) than your method, then, they might deserve another look.

[tigrouind]

I have made new tests with tweaked parameters (as suggested before). While it improve stability (less shaking), it's far from great. It's possible to tweak it even more but then the response is quite slow (as your current method). It's annoying to have to wait several seconds to see FPS impact when you change some game settings or move camera.

I made another series of tests, using a much better timer : mscount. Resolution is 1ms. It can be enabled using advanced parameter.

It's very stable and responsive. However using a high resolution timer all the time might not be advisable. If you look at the chart you will see new results are now slightly below purple line. The reason is that high precision timer use more CPU cycles. Not sure if it's timer callback itself or extra process done by advanced parameter. In average, you lose 0.3 FPS.

What about some trade-off (that should be documented) :

• If you detect high resolution timer is used, you display FPS with one decimal
• If it's not used, you display FPS with zero decimal.

If you want to show FPS with one decimal in all cases : you have to deal with large response time (which might be OK) or FPS shakiness (which make decimal part hard to read and somewhat useless).

The changes have been pushed on the respective branches.

[viti95]

Maybe you can take a look at @dougvj branch for frame interpolation (#176), it uses a faster timer interrupt (560Hz). My implementation it's not working fine so changes will have to be made for the new "uncapped FPS" mode.

As for me it's ok to show the framerate with zero decimal places, in fact it's faster as less characters has to be drawn each frame on the screen (I'm also thinking of using the very small number font to make it draw less pixels on screen).

[tigrouind]

I took a look at some old DOS games that have a framerate display built in, to get an idea about how it was done. Some show zero decimal (Duke3D) some 2 or 3 (Descent 2, Pacific Strike), or even 6 ! (Terminal Velocity). They are all very responsive (eg: even at low framerate, FPS can increase/decrease quickly) but also all unstable (eg: the decimals oscillate very quickly between multiple values, making it hard to read). Most of them use a 120Hz PIT Timer, some 60Hz.

560 Hz timer : if you go that way I would suggest that it's enabled using command line arguments or settings menu only. 560 Hz timer is probably going to be CPU expensive, especially on low hardware (386 and such). Timer callbacks usually do very little (eg: it increase a single variable) but in FastDoom it's doing a lot of things (eg: save/restore stack, loop trough tasks, ...). Using 560 Hz will make that part called 16 times more. It has to be tested on real hardware (since DOSBox is not cycle accurate). The best way to test this would be to compute the average of all frame times on a long demo, with a 35Hz timer and then later with 560Hz.

[dougvj]

It would be interesting to have some benchmarks to see the impact. I didn't mean to suggest changing the task module, I meant to suggest separating the interrupt handler from the task logic. Incrementing a global tick counter on each interrupt fire is basic enough to not warrant being its own generic task in the structure IMO, even if the performance improvement is negligible.

[dougvj]

You could keep the TaskModule relatively clean by having something like TS_SetTickHandler as a special case

[dougvj]

Another option I had considered too was to use the rdtsc instruction available on P5 and onward, and just not have frame interpolation on anything else. That would work, but I think it's an interesting feature to try out on lower CPUs.

[tigrouind]

rdtsc : I like the idea but there might be some issues with CPUs that don't run at a fixed frequency (I'm not sure at which point it has been introduced, may quite early in laptops). Multicores CPU can be issue too but AFAIK DOS only run on CPU0.
If you want have a highly optimized interrupt handler (that only increment a single variable and call task module every X iterations) ASM might be the way to go.

[dougvj]

rdtsc : I like the idea but there might be some issues with CPUs that don't run at a fixed frequency (I'm not sure at which point it has been introduced, may quite early in laptops).

Yeah Intel fixed this issue by making the tsc fixed frequency but I think that was introduced rather late. We would probably want to have some kind of fallback. There could be an issue with multicore scheduling and rdtsc, but that's what setaffinity is for. Would definitely be an experimental feature but removing the interrupt overhead might make a measurable difference on P5.

If you want have a highly optimized interrupt handler (that only increment a single variable and call task module every X iterations) ASM might be the way to go.

Yeah I like that Idea, I will look into it when I have some free time later this week.