Skip to content
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

[BUG] Autoexec VS Engine Startup Sequence #2415

Closed
1 task done
liPillON opened this issue Feb 22, 2024 · 3 comments
Closed
1 task done

[BUG] Autoexec VS Engine Startup Sequence #2415

liPillON opened this issue Feb 22, 2024 · 3 comments
Labels

Comments

@liPillON
Copy link

liPillON commented Feb 22, 2024

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?

  • 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

Attachment:
testing.zip

Steps to reproduce the behaviour.

Explain how to reproduce

  1. download the latest gzdoom release and unzip it somewhere, put a supported IWAD in the same folder
  2. create an empty gzdoom_portable.ini in the same folder
  3. place the autoexec.cfg I've provided in the same folder
  4. launch the provided gzdoom.cmd
  5. notice how the video backend being used is effectively GLES
  6. now download the latest CI artifacts and unzip it over the release binaries, overwriting them
  7. launch the provided gzdoom.cmd again
  8. notice how the video backend as well the texture filtering mode being used are now the default (Vulkan and Trilinear)

Your configuration

see attachments

Provide a Log

No response

@liPillON liPillON added the bug label Feb 22, 2024
@madame-rachelle
Copy link
Collaborator

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.

@liPillON
Copy link
Author

FWIW: this is happening also in the latest vkdoom CI build

@liPillON
Copy link
Author

successfully tested the latest CI artifact, thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants