-
Notifications
You must be signed in to change notification settings - Fork 157
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
Allow for and implement window resizing #314
Comments
It is not supposed to be resized at all: on windows it is blocked by corresponding bits, linux/x11/WMs may ignore desired behavior and even do not notify window about changed position/size so I see no way to fix this on non-windows platforms |
The only way to do it is force a vid_restart for mod compatibility after the resize is finished. Might as well drop raw x11 support and only do SDL on non windows which has window resize event tracking |
I'm sorry if this sounds harsh and I understand that software development takes a lot of time and effort but in my opinion disallowing window resizing is a dirty hack to kind of solve issues related to ignorance of situations where the window will resize. The proper action to take would be to actually handle window resizing.
At least on X11 if I open up xev log
TL;DR: There are X11 ConfigureNotify events.
This is another option to consider. |
If Windows implementation is currently the best out of the supported platforms does it support resizing the whole desktop area and the window with it? In scenarios such as setting a 4k monitor down to 1080p while quake3e is running. |
Even still, restarting the whole game backend is required. Mod code has no idea about the resize until the qvm or dll is reloaded. Hence why resizing doesn't look correct. It is not a hack but a limitation put in place by the existing game code API. |
Okay, so window resizing will never be a completely smooth experience, but even if vid_restart is effectively done for each resize it would be far better than just straight up crashing on Vulkan or having most of the view be out of the window's area. I think that ideally the view could be resized at any time but after X amount of time since a resize the window should (perhaps opt-out optionally to see what breaks?) vid_restart so that mode code can sync up. This would also make it so that drag resizing looks smooth (though with potentially warped assets before a vid_restart) and after the resizing is done and rendering is restarted the experience should be back to normal, right? |
When the application is resized it doesn't behave ideally, and the current observable behaviour differs between Vulkan and OpenGL.
Vulkan
2025-01-13.01-34-16.mp4
When the window is resized vertically it does not recognise the resolution change. If the window is made smaller then the drawn pixels shift down and the bottom pixels are not drawn on screen anymore.
When the window's resolution is cut in half horizontally then Vulkan just crashes.
Crash log
OpenGL
The window resizing is not recognised here either but it doesn't crash. When the window is made smaller it doesn't shift where it draws making it seem like all other windows are drawn on top of it
2025-01-13.01-35-13.mp4
I tested this on X11 with a patched dwm as a Window Manager. Same behaviour on Debian and Arch.
I don't know if these are related to X11, Wayland or every operating system which allows resizing the window size of fullscreen applications without making it not fullscreen but windowed.
I also attempted
r_fullscreen 0
and then resizing the window but it doesn't want to change its size at all.The text was updated successfully, but these errors were encountered: