Closed pchome closed 5 years ago
DXVK config files are no ini files and I refuse to implement anything that breaks current configuration files that people might be using.
Why do we suddenly need support for python libraries that were made for a different purpose?
I don't think it should break current configuration files.
I just think that currently [DEFAULT]
treated as a game executable named DEFAULT
, but could be just default section. Could be either present or not.
Python is just a simple example.
I'm just asking for a good reason to add code which is completely useless to the way DXVK functions. Yes, it's easy to add, but it's also the kind of nonsense that makes code a nightmare to maintain if you add enough of it.
I understand. Unfortunately I have no other reasons. Only those:
zenity
support and it could be a simple GUI over dxvk.conf
I personally using protonfixes
, it's the only reason I currently care about. But protonfixes
should just add/clean fake sections in generated config files.The default section shouldn't be exactly named "DEFAULT", use any name you like ("general", "dxvk", ...). I suggest only a default section which don't be compared to exe.
Anyway, feel free to close this request.
I hope you don't mind if I offer my two cents on this. I dislike the current ability to specify an exe name for localized options in a system-wide config because games can have their executables with the same names. NFS comes to mind which uses speed.exe
as names in some titles.
A different approach to this would be config merging, i.e. setting DXVK_CONFIG="<global_path>;<local_path>"
would iterate them sequentially and merge the configs. Configuration from the exe dir could be prefixed or suffixed depending on the merge order. I don't know how easy it would be to implement but to me it is seems like a more unified way to handle this.
That being said, I am neither for nor against said change as I am not actively using it.
I really don't get why there's so much fuss about the config file. Here's a rule on how it should be used 99% of the time:
The only valid reason to use the configuration file is to try out workarounds that aren't enabled by default for a given game yet, or to force-enable/disable Vsync in some games that don't have an in-game option. If there's a game which doesn't work without a given option set, please file a pull request or bug report so that DXVK can apply it by default in the next release.
The global config thing was requested because it allows Lutris scripts to enable workarounds before they make it into a DXVK release, which was a good reason to add it.
Multiple games using the same exe name are a problem, yes, but it's also an issue for the built-in workarounds which probably cannot be solved in any reasonable way. It's also fairly rare so it shouldn't be much of an issue in practice.
In any case, you can still just put a separate dxvk.conf next to the game exe and put your per-game options there. None of this is rocket science, and it shouldn't be; I just get the feeling that some of you want to make it rocket science for no good reason.
The global scope is just the same as the default section you are proposing. This is completely unnecessary.
I just get the feeling that some of you want to make it rocket science for no good reason.
Not me :)
I don't usually use nor global config, neither config in game's directory. But that thing (protonfixes) generates temporary config file for current game, and all "rocket science" is under the hood:
Useful tool for me, even if I want to on/off Vsync. But now there is a problem. And I want to know, if proposed change won't happen in DXVK, then I just going to change protonfixes code.
And I want to know, if proposed change won't happen in DXVK, then I just going to change protonfixes code.
That's probably the better solution.
In addition to per-app-configuration could you please add
[DEFAULT]
and/or[default]
section support?Would look more like INI file
Easier to use with python's
configparser
(requires section,default_section == "DEFAULT"
)At least protonfixes using this to generate DXVK config files (and likely broken now).