You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Have you checked that no other similar issue already exists?
I have searched and not found similar issues.
A clear and concise description of what the bug is.
My GZdoom setup includes an autoexec.cfg used to initialize various CVARs, among them are vid_preferbackend 2 and gl_texture_filter 0.
With the current 4.11.3 release, this results in the GLES renderer being used and in texture filtering being disabled.
With the latest CI artifacts (which I like to try from time to time) it seems that these cvar are evaluated after the video backend has been initialized, resulting in Vulkan and the default filtering being used.
By looking at the console output, I have the impression that the video backend is now initialized much earlier (eg: the gpu caps are among the first messages being printed) and thus before the autoexec file(s) has/have been parsed.
Is this behaviour here to stay?
Could the autoexec parsing be moved earlier during the engine startup sequence as well?
I'm attaching my test environment (minus the IWAD and GZdoom's binaries) where for each environment you'll find:
an autoexec.cfg which set up a bunch of CVARs with easily-detectable effects
a gzdoom.log file with the console output (compare it between environments, you'll notice how the video backend init and the autoexec parsing positions in the startup sequence have changed)
a screenshot which shows how the game appears right after launch (filtered vs unfiltered, scaled to 50% of my native resolution)
a populated gzdoom_portable.ini which shows how each CVARs has been stored with the expected value
the gzdoom.cmd I've used to automate/replicate the test
I can take a look at this and see if this can be changed, I agree it should be before the video backend is up. Both Autoexec and the command line should be parsed early on so that the user has a chance to specify what they want the backend to do beforehand.
GZDoom version
continuous integration as of commit 144caa0
Which game are you running with GZDoom?
Doom
What Operating System are you using?
Windows 10
Please describe your specific OS version
Windows 10 LTSC x64 (19044.4046)
Relevant hardware info
Intel i7-1260p, Intel Iris XE 96EUs
Have you checked that no other similar issue already exists?
A clear and concise description of what the bug is.
My GZdoom setup includes an autoexec.cfg used to initialize various CVARs, among them are
vid_preferbackend 2
andgl_texture_filter 0
.With the current 4.11.3 release, this results in the GLES renderer being used and in texture filtering being disabled.
With the latest CI artifacts (which I like to try from time to time) it seems that these cvar are evaluated after the video backend has been initialized, resulting in Vulkan and the default filtering being used.
By looking at the console output, I have the impression that the video backend is now initialized much earlier (eg: the gpu caps are among the first messages being printed) and thus before the autoexec file(s) has/have been parsed.
Is this behaviour here to stay?
Could the autoexec parsing be moved earlier during the engine startup sequence as well?
I'm attaching my test environment (minus the IWAD and GZdoom's binaries) where for each environment you'll find:
autoexec.cfg
which set up a bunch of CVARs with easily-detectable effectsgzdoom.log
file with the console output (compare it between environments, you'll notice how the video backend init and the autoexec parsing positions in the startup sequence have changed)gzdoom_portable.ini
which shows how each CVARs has been stored with the expected valueAttachment:
testing.zip
Steps to reproduce the behaviour.
Explain how to reproduce
Your configuration
Provide a Log
No response
The text was updated successfully, but these errors were encountered: