Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The micro stutter issue. #477

Closed
Arl90 opened this issue Jul 16, 2022 · 5 comments
Closed

The micro stutter issue. #477

Arl90 opened this issue Jul 16, 2022 · 5 comments

Comments

@Arl90
Copy link

Arl90 commented Jul 16, 2022

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
Copy link

Just to add on, the relevant commits from Doom3Quest referenced in this issue are
DrBeef/Doom3Quest@d50c947
which builds on commit
DrBeef/Doom3Quest@6355e3b.
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
Copy link
Member

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
Copy link

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
Copy link
Member

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?

@DanielGibson
Copy link
Member

I think the micro stuttering is fixed in this experimental branch: #585
(even when running at just 60fps)

I don't know if I'll merge that branch eventually, it's still buggy and multiplayer is completely broken, but if not, I'll probably at least port the changes that fix the micro stuttering

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants