|
Notes |
|
|
|
|
Ditto here on GNU/Linux, I haven't touched Zandronum for a month or two. I can't stay in fullscreen either, it throws me back into windowed after few seconds. No stdout/sdterr. No idea how to debug this. |
|
|
|
|
- Happens (mostly) with the OpenGL renderer, but not the software renderer.
- Happens at 2560x1440 resolution, but not 5120x1440.
- Software renderer gets confused of resolutions with "toggle fullscreen". Might go into windowed 1600x900 or so, but the game thinks it is in fullscreen. May also go to 1600x900 fullscreen with blackboxing. Native resolution is 2560x1440.
- The cursor in menu may be selected over a non-existent resolution (blank) after some trickery.
- Same with no PWADs, clear configuration.
|
|
|
|
(0018995)
|
|
WubTheCaptain
|
2018-01-18 04:57
(edited on: 2018-01-18 05:00) |
|
The OpenGL renderer won't take my mouse input at all in fullscreen (except for 1 frame during Ctrl + F shortkey in i3 window manager for toggle to windowed/fullscreen).
Software renderer is odd and follows this cycle with "toggle fullscreen" in console:
- Fullscreen 2560x1440; fullscreen is true
- Windowed 2560x1440; fullscreen is false
- Windowed 1920x1080; fullscreen is true; mouse won't work, keyboard works;
- Windowed 2560x1440; fullscreen is false;
Sometimes it gets stuck between 3 and 4, until the resolution is changed again in the menu. Also very rarely, 2560x1440 fullscreen true but it appears as windowed on desktop.
|
|
|
|
|
Okay, this happened:
- Start with fullscreen 2560x1440.
- "fullscreen false" in console to go to windowed 2560x1440.
- "fullscreen false" (again) in console to go to windowed 1920x1080 and it gets confused.
- "fullscreen true" attempts to fullscreen, but goes back to windowed 1920x1080. Then it resets to fullscreen 1920x1080 few seconds later and loses both keyboard and mouse input.
I had to switch to tty2 and pkill zandronum. |
|
|
|
|
|
None of this happens in GZDoom 3.1. I don't have GZDoom 1.8.6 installed right now, but I can try there if needed. |
|
|
|
|
That would help, we could then think about back-porting the relevant GZDoom fix if it happens there too.
1.8.6 can be downloaded from the rules page. |
|
|
|
|
I built GZDoom 1.8.6 from source on Debian GNU/Linux buster/sid, using git tag g1.8.6.
Happens there too. Toggling the fullscreen option in the menu with Enter key, the game remains in windowed mode and doesn't go fullscreen. I also sometimes lose mouse input, as previously described.
Also in this situation where GZDoom 1.8.6 appears to be windowed on desktop:
- "fullscreen" is "true", "use_mouse" is "false" → mouse1 "+attack" goes through (system cursor shown).
- "fullscreen" is "true", "use_mouse" is "true" → mouse1 "+attack" doesn't work (system cursor not shown/captured by the game).
|
|
|
|
|
|
Worth noting the resolution doesn't screw up to 1920x1080 in GZDoom 1.8.6 with double-command "fullscreen false" at least, while it does in Zandronum. |
|
|
|
(0019002)
|
|
WubTheCaptain
|
2018-01-18 21:11
(edited on: 2018-01-18 21:14) |
|
Hardly relevant, but I'll mention it anyway: Also in GZDoom 3.2.5, the i3 window manager "Meta + F" [sic to previous] fullscreen toggle is independent of the ingame's fullscreen option. Essentially, the "fullscreen" cvar is disregarded and the cursor boundaries aren't respected in any scenario (while they are in Zandronum 3 and GZDoom 1.8.6).
|
|
|
|
|
I dunno about anyone else, but I was able to fix my case.
I just have to close TeamViewer when Zandronum is open.
Conveniently, there's another tracker tracking that very issue. |
|