The micro stutter issue.

[Arl90]

I created this issue to bring to surface and to gather more info regarding this often talked issue, a mild stutter that happens in the vanilla game. The only instance where it doesn't happen is in later revisions of the engine, this being the so called "idtech 4.5" from Doom 3 BFG Edition.

This has been addressed in the VR implementation of the engine D3 Quest, with notations in the source code stating this:

DrBeef's "smoothing out" logic, dodgy, but seems to do the trick. This is here because, for example, if we are running at 60hz, then the game tic interval is 16ms, which actually means 63 tics per second, so every half second or so we get an extra tic. This extra tic results in a movement glitch (subtle, but annoying when you are aware of it) because you move two tics worth of distance compared to the other frames, which is more obvious in VR.

The solution is to just skip these extra tics, however if we skip all extra tics and only process one per frame then if the fps drop due to a lot of action, the whole game slows down, which isn't desirable. Therefore we only want to skip isolated instances of a single extra tic if we are maintaining almost max frame rate.

This has also been allegedly noted and addressed in some forks of the engine like https://github.com/jmarshall23/DNF-IcedTech

I'll add more info about it as I'm able to gather.

[MatthewBishop]

Just to add on, the relevant commits from Doom3Quest referenced in this issue are https://github.com/DrBeef/Doom3Quest/commit/d50c947e37a6379718593174968f18845ce46263 which builds on commit https://github.com/DrBeef/Doom3Quest/commit/6355e3ba4880a173babbaae7a579f8da622e8f91. the relevant lines from Session.cpp: https://github.com/DrBeef/Doom3Quest/blob/master/Projects/Android/jni/d3es-multithread-master/neo/framework/Session.cpp#L2795-L2832

which would replace https://github.com/dhewm/dhewm3/blob/master/neo/framework/Session.cpp#L2831-L2842

Perhaps we can setup a test branch and see if this resolves the issue?

[DanielGibson]

I don't currently have time to work on dhewm3, but generally, when/if we ever get stable high-refreshrate (for >= 120Hz displays and such) support, this issue would most probably be fixed when implementing that, because then we'd definitely have to find a way to have a higher timer precision than 1 millisecond (maybe use microseconds, maybe use floats, IDK)

[MatthewBishop]

If anyone is interested/has this issue. The code from Doom3Quest mentioned in this Issue integrated in Dhewm3 is available here: https://github.com/MatthewBishop/dhewm3/tree/stuttering-fixes

I have not experienced this issue so I cant say for certain if it fixes the problem for users.

[DanielGibson]

If that fix is actually works for people with this issue, I'd merge it - can you test @MatthewBishop's branch, @Arl90?

Does anyone else have that problem and can test this?