Get Phobo Posted August 3, 2019 I noticed that, starting with version 4.0.0, GZDoom has had a new 640x400 minimum resolution. Was that design choice made for specific technical reasons, or was it just a deliberate choice with no specific reasons behind? To me, it is a unnecessary limitation that not only makes it impossible to use a resolution of 640x360 pixels (exactly one third of my monitors' native resolution)--which is necessary with large, demanding maps sometimes--but it also creates ugly black bars on a 16:9 screen. 0 Share this post Link to post
Graf Zahl Posted August 4, 2019 The reason is that the menu does not scale down to 320x200 with the new font and/or localized content. In order to make 320x200 work again there needs to be some separation between menu and game rendering, and with none of the developers having an interest in such low resolutions it is not particularly high on the list of priorities. 0 Share this post Link to post
Urthar Posted August 4, 2019 Yeah, 640x360 is a nice resolution for software renderer in wide screen. 0 Share this post Link to post
Get Phobo Posted August 4, 2019 (edited) 16 hours ago, Graf Zahl said: The reason is that the menu does not scale down to 320x200 with the new font and/or localized content. In order to make 320x200 work again there needs to be some separation between menu and game rendering, and with none of the developers having an interest in such low resolutions it is not particularly high on the list of priorities. Okay; and you couldn't make something 16:9-compatible, like the aforementioned 640x360, work? 6 hours ago, Urthar said: Yeah, 640x360 is a nice resolution for software renderer in wide screen. I use it with the OpenGL and Vulkan renderers. Vulkan is still a bit unstable, though, so it's gonna be OpenGL for me some more time. But playing large maps with Project Brutality can really demand such a low resolution. It gives a nice retro touch in a way, anyway. 0 Share this post Link to post
Graf Zahl Posted August 5, 2019 No, because then the screen wouldn't be tall enough anymore for some screens. What kind of system are you running? Vulkan-compatible systems that require that much upscaling are quite rare. 0 Share this post Link to post
Get Phobo Posted August 5, 2019 I was running a few larger maps with Project Brutality, which altogether was quite demanding. But the actual reason was that I had to switch to OpenGL, which made this lower resolution necessary, as the Vulkan renderer kept crashing. It's still a bit unstable, at least in conjunction with mods like PB. (I know you've mentioned that in the 4.x description, so it came to no surprise to me, but still...) 0 Share this post Link to post
Graf Zahl Posted August 5, 2019 If Vulkan keeps crashing, please make a bug report, listing your hardware specs and mods loaded. Otherwise these cannot be tested and potentially fixed. Vulkan is pretty nasty if some buffer is too small, there's little safeguards in that code for performance reasons. 0 Share this post Link to post
Get Phobo Posted August 22, 2019 Sorry, I almost forgot about this. So, it looks like the issues I've had with the Vulkan renderer are due to its enormous system memory consumption. I can reproduce those things over and over again, so the following info is reliable. Vulkan seems to require substantially more RAM than OpenGL does. Memory consumption is way higher than in OpenGL mode (with the same settings and mods). When I start the game witht the following settings: HQ resize mode - 4xBRZ, Project Brutality 3.0 DooDguy, and a 4x HD texture pack; and call the menu via Esc key, OpenGL mode uses slightly more RAM than Vulkan mode (1785 MB vs 1659 MB). After starting a new game, this changes radically, with OGL still requiring about the same 1.7 GB as in the menu, while Vulkan already doubles its needs to around 3.4 GB. Vulkan's VRAM usage is also higher, but that doesn't seem to cause any crashes. The exe's RAM commit can easily surpass 10 GB when using Vulkan, while it peaked at 7.6 GB during my OpenGL testing session. There is also always a visible spike in RAM consumption, when (re)loading/restarting a map, that doesn't occur when using OpenGL. That spike becomes truly extreme when HQ resizing is set to anything beyond 2x, causing the game to crash due to lack of memory. It doesn't happen with OpenGL, though, which allows me to play with up to 6x without crashing. The whole memory consumption pattern for Vulkan is also different from OpenGL. OpenGL loads and unloads stuff from VRAM while Vulkan seems to keep everything once loaded. This all is true for the current 4.2.0 exe on Windows (64-bit). Only the GZDoom exe crashes, it doesn't crash my whole system. 0 Share this post Link to post
ReaperAA Posted August 23, 2019 @Get Phobo I think it would be better if this issue is reported at zdoom forums since GZdoom devs are more active there. For now I will mention @Graf Zahl to see this. 0 Share this post Link to post
Get Phobo Posted August 23, 2019 I know. However, the ZDoom forums also happen to have some very shitty moderators, so there's that. Thank you, anyway. 0 Share this post Link to post
Gez Posted August 23, 2019 On jeudi 22 août 2019 at 5:11 AM, Get Phobo said: HQ resize mode - 4xBRZ, Project Brutality 3.0 DooDguy, and a 4x HD texture pack It's kinda redundant to use a HQ resize filter on a HD texture pack. I'm not surprised that you get high memory consumption, with 4x resize of 4x textures, you get 256 times the memory footprint. 0 Share this post Link to post
Get Phobo Posted August 23, 2019 (edited) No, HD textures are not resized. Only the bloodsplats on them are being resized when texture resizing is on. But those spikes and crashes occur even if I do not use HD textures, or if I enable resizing for sprites only, leaving the original IWAD textures, including the bloodsplats on them, completely untouched. The crash would just occur a bit later. It definitely occurs when sprite-only resizing is set to 5x or 6x, probably also 4x. I did some testing on that. It might crash or not on 4x. 3x for sprites only worked well, and 2x worked well for everything. That's my safe setting for Vulkan. Anything above would crash sooner or later due to lack of RAM. (I will do some further testing with less stuff loaded in RAM (no RAM disks, no Chrome windows) to see just how much RAM Vulkan really needs with the different settings. It definitely needs a lot more than OpenGL, that is clear.) Besides, if HD texture resizing were implemented, it would have to affect OpenGL as well, but it doesn't. It's also just a temporary spike each time. So there has to be something about the Vulkan renderer--a bug or a feature of some kind. 0 Share this post Link to post
Get Phobo Posted August 27, 2019 @Graf Zahl So, while I did some further testing with less stuff loaded in RAM, after a long period of crash-free playing, I got this weird crash: Out of a sudden the game would freeze, and its memory consumption would rise by around 3.8 GB. For as long as I kept the game/exe running, it would occupy the additional RAM. 0 Share this post Link to post