Zandronum Chat on our Discord Server Get the latest version: 3.1
Source Code

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0003848Zandronum[All Projects] Bugpublic2020-07-21 09:392022-06-22 13:57
Assigned To 
Statusneeds testingResolutionopen 
PlatformOSLinuxOS Version5.7.9-arch1-1
Product Version3.1-beta 
Target Version3.2Fixed in Version 
Summary0003848: [Linux/SDL] OpenGL Stuttering (with fix)
DescriptionMassive stuttering issues in OpenGL in Zandronum on Linux, practically unplayable, see here: [^]

Applying this fix [^] from [^] fixes this entirely. I tried it by compiling the source with the changes by myself. The game is silky smooth afterwards.
Attached Files

- Relationships

-  Notes
User avatar (0021623)
DoubleK1LL (reporter)
2021-07-20 01:32
edited on: 2021-07-20 03:29

I compiled Zandronum 3.1 alpha 5bb6162acea1 with this patch and I still have movement that has a slight stutter. It's not possible to play competitively like this. Mouselook is otherwise smooth like the video. Run out of options here to get Zandronum perfectly smooth in Linux. I'm on Mint 20.2.

Running the Windows variant (3.0) in Wine actually works smoothly compared to the native linux builds.

User avatar (0022068)
tm512 (reporter)
2022-01-01 23:30
edited on: 2022-01-02 00:00

I was getting this issue with the Zandronum 3.1 release on Linux. Pretty much everything lines up with what is described in the ZDoom forum post, with the degree of jitter varying every time Zandronum is started up.

The patch seems to alleviate the issue almost entirely, at the very least it now runs consistently. It still seems like maybe it's not as smooth as modern GZDoom is, but at this point it's slight enough to where it's hard to tell for sure. GZDoom has since switched over to using a timer source with nanosecond precision, a million times more precise than SDL_GetTicks(), so maybe that's got something to do with it, but I don't know this code well enough to tell how much inaccuracy Zan's millisecond timer would even produce at the 60Hz refresh rate I'm using.

I did my own video capture, comparing the patched and unpatched binaries back-to-back: [^] Do note that my capture software ended up having a hiccup at one point during the recording of the patched binary, but that wasn't visible in-game.

I also uploaded an updated patch that applies cleanly to the current codebase, for convenience: [^]

This overwrites a change that seems to be introduced here: [^] but there don't seem to be any ill effects from that, if necessary, the change to how TicStart is calculated could probably be reintroduced, but I haven't tested that.

Really hoping to see this issue get resolved in the mainline source soon.

User avatar (0022084)
Torr Samaho (administrator)
2022-01-16 21:14

Kaminsky pointed me to the corresponding GZDoom commit, which I now transplanted to our main repo: [^]
User avatar (0022198)
tautvis (reporter)
2022-04-25 18:15

The patch using millisecond timer was not enough, at least for me subjectively the stutter problem (more like microjitter) was not completely gone. Situation looks is alleviated using the transplanted (copy from gzdoom source) time function with nanosecond resolution. After applying patch, which was not very intrusive (these few places more, where need to change variables to accommodate 64 bit timestamp) game felt much more smoother.

Created two patch versions:
* for ZA_3.1 version - [^]
* fairly recent commit c770f5a41612 - [^]
User avatar (0022270)
azvasKuklenko (reporter)
2022-06-19 21:34

I have exactly the same issue running Zandronum on Linux. Tested on 2 machines (NVIDIA RTX 3060Ti, Intel HD 620), I can always reproduce it. Whenever a map gets more crowded by monsters, it stats lagging in an odd way.

I compiled Zandronum 3.1 with the above patch and then played for about 2h - it's buttery smooth no matter how crazy the game goes (tested with Brutal Doom and Maps of Chaos, played through 4 different levels). I didn't notice any issues with the game itself.

Is there any chance this patch could be merged for future release as is or is there something more missing? I could do some more testing on my end.
User avatar (0022271)
Kaminsky (developer)
2022-06-19 22:42

Just to clarify, were you using the patch provided by tautvis or the GZDoom commit that was transplanted in 3.2? Is the GZDoom commit not working well enough for you?
User avatar (0022273)
azvasKuklenko (reporter)
2022-06-22 13:56

This one:

> * for ZA_3.1 version - [^]

I cloned Mercurial repo and checked out into ZA_3.1, then applied the patch, made sure the diff is fine, then compiled it.

I couldn't compile it on Arch btw and actually used Ubuntu 20.04 in Docker container, but that's another issue.

Issue Community Support
Only registered users can voice their support. Click here to register, or here to log in.
Supporters: DoubleK1LL
Opponents: No one explicitly opposes this issue yet.

- Issue History
Date Modified Username Field Change
2020-07-21 09:39 Lunia New Issue
2021-07-20 01:32 DoubleK1LL Note Added: 0021623
2021-07-20 03:09 DoubleK1LL Note Edited: 0021623 View Revisions
2021-07-20 03:29 DoubleK1LL Note Edited: 0021623 View Revisions
2022-01-01 23:30 tm512 Note Added: 0022068
2022-01-01 23:30 tm512 Note Edited: 0022068 View Revisions
2022-01-02 00:00 tm512 Note Edited: 0022068 View Revisions
2022-01-16 21:14 Torr Samaho Note Added: 0022084
2022-01-16 21:15 Torr Samaho Status new => needs testing
2022-02-20 05:37 Kaminsky Target Version => 3.2
2022-04-25 18:15 tautvis Note Added: 0022198
2022-06-19 21:34 azvasKuklenko Note Added: 0022270
2022-06-19 22:42 Kaminsky Note Added: 0022271
2022-06-22 13:56 azvasKuklenko Note Added: 0022273

Questions or other issues? Contact Us.


Copyright © 2000 - 2022 MantisBT Team
Powered by Mantis Bugtracker