wayland: regression with imgui-rebased ( https://github.com/dhewm/dhewm3/pull/576 ) #587
Comments
|
the same assertion fails each time here is the bt |
|
Does that also happen in the current master branch? Because imgui-rebased as been merged |
|
yes sorry, I used the master branch. |
|
Ok - can you tell me what imgui menu -> video options says about "Current Resolution" and "Display Size", both in windowed mode and fullscreen mode (if needed because using imgui menu crashes on apply, configure that through console and use a full Oh right, and if that also doesn't work because the assertion triggers just by opening the video menu, comment out the line with the assertion (neo/sys/glimp.cpp:728) |
|
seems to work fine w/o the assertion. windowed mode: fullscreen mode: SDL_VIDEODRIVER=x11 fullscreen mode: with SDL_VIDEDRIVER=wayland the same with vkquake or ironwail. with SDL_VIDEODRIVER=x11 fullscreen uses the real resolution 2560x1440 |
|
does it say anything about "Physical" (it does when detecting display scaling) in the menu, next to Current Resolution and Display Size? |
|
no. in fullscreen mode the desktop size always equals the configured game resolution. ( x11 driver ) update: probably can´t detect any scaling, because the desktop is not scaled ( 100 % ) |
|
If I understand the problem right this behavior is kind of expected: Under Wayland the fullscreen handling is compositor dependent. In my experience tho common compositors (kwin, mutter, wlroots) don't support implement switching initiated by clients. When a client requests fullscreen mode, the client is a) put in exclusive fullscreen mode when it's drawable size matches the current resolution of the given display or b) scaled up / down if it's drawable size is lower / higher than the resolution of the given display. Fractional scaling and scaling awareness of the client shouldn't matter in exclusive fullscreen, the common compositors communicate a scaled display mode, but an unscaled drawable size. That might break assumptions made by the client, though. |
|
Does it help if at the end of GLimp_SetScreenParms(), around here: https://github.com/dhewm/dhewm3/blob/master/neo/sys/glimp.cpp#L685, maybe after that |
|
no change. all what was needed was commenting out the assert at line 728 |
ok, I'll have to debug this on wayland
that's no solution - if the values in glConfig aren't correct (consistent with the actual sizes), other code will behave wrong (for example mouse cursor speed, possibly even rendering itself) |
assert( ret.width == glConfig.winWidth
&& ret.height == glConfig.winHeight );
in GLimp_GetCurState() triggered, because SDL_GetWindowSize(),
which was used to set glConfig.winWidth/Height in
GLimp_UpdateWindowSize(), returned different values than
SDL_GetWindowDisplayMode().
Now use SDL_GetWindowDisplayMode() in GLimp_UpdateWindowSize() so it's
at least consistent.
However it seems like SDL_GetWindowSize() returns the correct values
(IN THAT CASE), because with this change the mouse cursor doesn't work
that well (in the specific case described above).
In the end this is an SDL or Wayland bug or something, and I can only
recommend not using "real" fullscreen mode with Wayland, as it's fake
anyway (Wayland doesn't allow switching the display resolution, so
you get a magically scaled borderless fullscreen window at best)
|
I pushed a fix for this to master. Overall that case is still kinda broken (no crash anymore, but mousecursor behaves weird), and that's a bug in SDL or Wayland. I think the main underlying issue is that Wayland does not support real fullscreen mode. So all you get is fugly hacks: In the native Wayland case ( In the XWayland case however it apparently creates a borderless fullscreen window at the desktop resolution (2560x1440 in your case, not the one you requested!). For some reason however, one SDL function ( Due to dhewm3 using the wrong size (at least consistently now..), the mouse input can behave weird in this specific case (XWayland + "real" fullscreen at lower resolution). Extra unfortunate: think in the past I've seen |
|
So the mouse cursor could behave strangely in the GUI /PDA ? But mouse movement in game should not be affected? Have to reboot to fedora again to test. The scaling with native Wayland and use of real desktop resolution with Xwayland is consistent with other apps I tried so far. |
Yeah, I think so. I specifically noticed that the cursor position in ImGui isn't consistent with the one in the main menu anymore. I recommend using only "fullscreen desktop" mode with Wayland, because real fullscreen isn't supported anyway. |
|
My motivation for this was the advantage of having a configured lower resolution for windowed mode and a full desktop resolution at one click or keyboard shortcut like alt/enter. Otherwise aliases are needed. is something like this available in doom3? |
|
Wouldn't SDL_GL_GetDrawableSize() be a more suitable call? It should report the real dimensions of the drawable.
|
No, because the mouse coordinates don't use the drawable size but the window size (when they're different, like in HighDPI/desktop scaling mode).
You can also use aliases and all that, but the easiest way is to enable fullscreen desktop (r_fullscreenDesktop) mode. |
|
ok, there are other more serious issues if Xwayland is involved. all viewports (?) for windows have a wrong angle, show the wrong parts of the room. Screenshots are also incomplete and sometimes have other garbage. is there an option to disable the vid_restart partial codepath?
|
|
uhh.. wtf.. didn't have that issue is this on master or kickstart-my-hertz? |
|
both! those are screenshots created with the engine. only windows and the ship engines look strange. |
|
Does it only look broken in screenshots or also on the actual screen? So far I really can't reproduce this, even with Wayland + Gnome |
|
everythinig looks fine in game but the windows and the engine exhausts of the ship's engines. what distribution? This is on upto date fedora 40 with the new NFB nvidia branch 555.58.02 |
|
I tested with latest Arch Linux (live image with Gnome from http://dl.gnutux.fr/archuseriso/img/, but updated that while running and additionally installed gnome-control-center) on a laptop with AMD iGPU (Ryzen 5 7640U). I just had a maybe similar issue: When changing the resolution (or toggling fullscreen) after taking a screenshot, the window remained black or invisible. |
|
ignore screenshots for a moment (it did not help btw.) here is a short video . Xwayland 24.1 |
|
I don't really see much in the video (at least no details in the reflections), maybe due to the low resolution. I tested with the space ship at the beginning of the game and didn't see any graphical bugs there. I'll test again with the Infirmary Could also be a graphics driver bug, of course |
|
download the video |
|
the 2nd screenshot above shows is very good. look at the window area. You should see the operator who initiates the scan. But we see the ceiling or parts of it instead driver bug: of course, have avoided the short lived NFB branch most of the time. |
|
Ok, with the downloaded video I can see that it looks wrong. Can't reproduce it though. Here it's the same XWayland and mutter versions, but SDL 2.30.4 (and of course no nvidia driver but the open source AMD driver) |
disables partial vid_restarts, hopefully works around issues like dhewm#587 (comment) Note that resizing the window by dragging it does *not* call vid_restart at all, so if you're having issues that are fixed by a full vid_restart you should also set `r_windowResizable 0`
|
Can't reproduce it with real X11 and nvidia driver 535.183 either. However, I just added a CVar |
enabled window resizing only for the ideo :) quck update: This looks indeed like a driver issue. The NFB driver showed better results with the 144Hz branch. It's only this window rendering after changing the dimentions of the game window. This will be fixed eventually by nvidia. This issue is tiggered by resizing the game window / changing game resolution w/o a hard vid_restart on wayland with Xwayland server. Native wayland is fine! |
|
So do you think we can consider this bug resolved (from dhewm3's point of view, I can't do anything about nvidias driver) by setting |
|
Yes, I think so. |
|
Great! |
disables partial vid_restarts, hopefully works around issues like #587 (comment) Note that resizing the window by dragging it does *not* call vid_restart at all, so if you're having issues that are fixed by a full vid_restart you should also set `r_windowResizable 0`
disables partial vid_restarts, hopefully works around issues like dhewm/dhewm3#587 (comment) Note that resizing the window by dragging it does *not* call vid_restart at all, so if you're having issues that are fixed by a full vid_restart you should also set `r_windowResizable 0`
Using upstream patch. Remove BROKEN. Changes since 1.5.1: 1.5.4 ------------------------------------------------------------------------ * A brand new settings menu that uses [Dear ImGui](https://github.com/ocornut/imgui). Can be opened with `F10` (unless that key is bound already) or by entering `dhewm3Settings` in the console. It has lots of settings that the original options menu doesn't have and can be easily navigated with gamepad or keyboard (or the mouse, of course). It can also be opened while in the game, which then is paused (if Single Player) but still visible, so the effect of most graphics settings can be seen immediately. Needs SDL2 and C++11. * "Soft" Particles (that don't "cut" into geometry but fade smoothly), based on code from The Dark Mod 2.04. Can be enabled/disabled with `r_useSoftParticles`, is applied automatically for all appropriate particles (view-aligned, using additive or alpha blending and not too small) * `r_enableDepthCapture`: Enable capturing depth buffer to texture, needed for the soft particles. Can be used in custom materials by using the `"_currentDepth"` texture * Replaced dependency on (external) zlib with integrated [miniz](https://github.com/richgel999/miniz) * HighDPI/Retina support * Allow inverted mouse look (horizontally, vertically or both) with `m_invertLook` * CVar to allow always run in single player (still drains stamina though!): `in_allowAlwaysRunInSP` * VSync can be enabled/disabled on the fly, without restarting the renderer (still with `r_swapInterval` or in the menu, of course; needs SDL2) * Allow enabling/disabling [HRTF](https://en.wikipedia.org/wiki/Head-related_transfer_function) with `s_alHRTF` * `s_alOutputLimiter`: Configure OpenAL's output-limiter which temporarily reduces the overall volume when too many too loud sounds play at once, to avoid issues like clipping * `s_scaleDownAndClamp`: Clamp and reduce volume of all sounds to prevent clipping or temporary downscaling by OpenAL's output limiter * If `r_windowResizable` is set, the dhewm3 window (when in windowed mode..) can be freely resized. Needs SDL2; with 2.0.5 and newer it's applied immediately, otherwise when creating the window. * If switching between fullscreen and windowed mode or similar changes causes issues (like [here](dhewm/dhewm3#587 (comment))), you can set `r_vidRestartAlwaysFull 1`, so (again) a full `vid_restart` is done, instead of the partial one which *usually* suffices for just changing the resolution or fullscreen state. If you run into that issue (probably a driver bug), you'll probably also want to set `r_windowResizable 0`, because resizing the window that way also triggered the bug, and in that case no `vid_restart` is done at all * Fixed screenshots when using native Wayland (`SDL_VIDEODRIVER=wayland`) * If you enter the `map` command in the console, without any arguments, the current map name is printed * Support OpenGL debug contexts and messages (`GL_ARB_debug_output`). Can be enabled with `r_glDebugContext 1`. Changing that CVar requires a `vid_restart` (or set it as startup argument) * The Mods Menu's entries for the base game and d3xp/RoE are now clearer, and it can load the new d3xp-based mods (sikkmodd3xp, perfected_roe) 1.5.3 (2024-03-29) ------------------------------------------------------------------------ * Support for gamepads (based on code from [Quadrilateral Cowboy](https://github.com/blendogames/quadrilateralcowboy), but heavily expanded). See [Configuration.md](./Configuration.md#using-gamepads) for more information. * Support different file formats for screenshots by setting the `r_screenshotFormat` CVar (0 = TGA, still the default, 1 = BMP, 2 = PNG, 3 = JPG). `r_screenshotJpgQuality` and `r_screenshotPngCompression` allow configuring how JPG/PNG are compressed. Thanks *eezstreet (Nick Whitlock)*! * Fixed problems with lights after loading a savegame (#495) * Fix volume of some weapon sounds, like chaingun being too quit (#326) * Increase stack size on Windows to 8MB (instead default of 1MB) to make loading huge models work * Fixed crash in Radiant Model Preview Dialog (#496) * Fix MD3 model support * Several new CMake options: - To enable Clang/GCC Address Sanitizer and Undefined Behavior Sanitizer - Hardlink the game code into the executable (instead of using game DLLs, only supports base *or* d3xp then; needed for Undefined Behavior Sanitizer) - Force colored diagnostic output from GCC or Clang (esp. useful when building with ninja) * Fix several compiler warnings * Added build instructions for Linux (and similar systems) to README.md * Updated stb_image and stb_vorbis * Updated minizip (from zlib/contrib) to latest upstream code * Added `in_namePressed` CVar to print currently pressed key/button (useful for binding keys in the console or configs). Thanks *Biel Bestué de Luna*! 1.5.2 (2022-06-13) ------------------------------------------------------------------------ * Gamma and Brightness are now applied in the shaders instead of by setting hardware gamma. Can be disabled (so hardware gamma is used again) with `r_gammaInShaders 0` * Improvements for (Windows-only) MFC-based tools: - Added the script debugger! (thanks *HarrievG*!) Original Doom3 didn't have it (Quake4 did), but the Doom3 GPL source contained most of it. *HarrievG* implemented the missing parts and we added some new features. It can even be used over the network and while the client part (the debugger GUI) is Windows-only, the server can run on all supported platforms, so you can debug a game running on Linux or macOS, for example. Relevant CVars for network debugging are: `com_enableDebuggerServer` and `com_dbgClientAdr` and `com_dbgServerAdr`. To debug the running game on the same PC, just enter `debugger` in the console. - All tools can now be built in 64bit (thanks *raynorpat*!) - HighDPI support (thanks *HarrievG*!) - PDAEditor works now - Additional bugfixes * Cycle through multiple Quicksave slots instead of immediately overwriting the last Quicksave. The `com_numQuicksaves` CVar allows setting the number of QuickSaves (#392) * Make r_locksurfaces work (#357) It doesn't do exactly what its description and name suggests: it renders everything that is *currently* visible from the position/view the player had when setting `r_locksurfaces 1`. Originally it was supposed to render exactly the surfaces that *were* visible then, but I couldn't get that to work. This is pretty similar, but there may be differences with opened doors and such. * Keyboard input improvements (mostly SDL2-only): - Support (hopefully) all keyboard keys on all kinds of keyboard layouts by using scancodes for otherwise unknown keys - Support typing in non-ASCII characters, if supported by Doom3 (it supports ISO-8859-1) - Support the clipboard also on non-Windows platforms You can paste text from the clipboard into the console or other edit fields with `Shift+Insert` - Explicit support for Right Ctrl, Alt and Shift keys (can be bound to different actions than their left counterparts) - Added `in_grabKeyboard` CVar to make sure dhewm3 gets *all* keyboard input Prevents the Windows-key or Alt-Tab or whatever from taking focus from the game - Added `in_ignoreConsoleKey` - if set to `1`, the console is only opened with Shift+Esc, and the "console key" (that key between Esc, 1 and Tab) can be freely bound to an action (and its char can be typed in the console without closing it). - Added (SDL2-only) "auto" option for `in_kbd`: When not disabling the console key, dhewm3 will try to automatically detect it if `in_kbd` is set to "auto" (now default) * Reworked mouse-input and -grabbing code, using absolute mouse mode in fullscreen GUIs (except for the PDA, because it's implemented weirdly). This made releasing the mouse in the main menu possible, as now the ingame cursor is at the same position as the system cursor. * `s_alReverbGain` CVar to reduce EFX reverb effect intensity (#365) * Pause (looped) sounds when entering menu (#330) * Fixes for looped sounds (#390) * Replace libjpeg with stb_image and libogg/libvorbis(file) with stb_vorbis - Now the only required external dependencies should be OpenAL, SDL, zlib and optionally libCURL (and of course the C and C++ runtimes) * (Optionally) use libbacktrace on non-Windows platforms for more useful backtraces in case of crashes (usually linked statically) * Fixed a deadlock (freeze) on Windows when printing messages from another thread * Fixed endless loop (game locking up at startup) if graphics settings couldn't be applied (#386) * Fixed some warnings and uninitialized variables (thanks *turol*!) * Work around dmap bug caused by GCC using FMA "optimizations" (#147) * Prevent dhewm3 from being run as root on Unix-like systems to improve security * Replaced most usages of `strncpy()` with something safer to prevent buffer overflows (remaining cases should be safe). - Just a precaution, I don't know if any of them could actually be exploited, but there were some compiler warnings in newer GCC versions. * Console output is now logged to `dhewm3log.txt` (last log is renamed to `dhewm3log-old.txt`) - On Windows it's in `My Documents/My Games/dhewm3/` - On Mac it's in `$HOME/Library/Application Support/dhewm3/` - On other Unix-like systems like Linux it's in `$XDG_DATA_HOME/dhewm3/` (usually `$HOME/.local/share/dhewm3/`) * Improved compatibility with Wayland (#426) * Work around assertion in AlphaLabs4 due to "ride_of_death" yeeting the dead "monster_zsec_shotgun_12" into the void (#409) * Support loading some mods known to need `fs_game_base d3xp` via Mods menu (currently, *The Lost Mission* and *LibreCoop d3xp* are supported) * Disable assertion in idSampleDecoderLocal::DecodeOGG() that triggered when starting a new Classic Doom3 game (#461)
found easy procedure to crash dhewm3 on linux with wayland ( didn´t test with x11)
wayland/gnome
desktop resolution 2560x1440@144z (nvidia driver 555.58.02 )
SDL_VIDEODRIVER=x11 // no problem with SDL_VIDEODRIVER=wayland
with X11 the resolution used by SDL changes to desktop resolution
works with dhewm 1.5.3
several ways to reproduce
in main screen
alt/enter to fullscreen
alt/enter to window -> crash
in main screen
alt/enter to fullscreen
open imgui
select video tab -> crash
in main screen
open imgui/video
change from Windowed to Fullscreen
apply -> crash
bt is not very useful, need to get libbacktrace and recompile
dhewm 1.5.3 switches seamlessly to full screen 2560x1440 and back to the configured resolution in windowed mode.
The text was updated successfully, but these errors were encountered: