doitsujin / dxvk

Vulkan-based implementation of D3D8, 9, 10 and 11 for Linux / Wine
zlib License
13.01k stars 834 forks source link

Feature Request: support default section in config file #1072

Closed pchome closed 5 years ago

pchome commented 5 years ago

In addition to per-app-configuration could you please add [DEFAULT] and/or[default] section support?

doitsujin commented 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?

pchome commented 5 years ago

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.

doitsujin commented 5 years ago

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.

pchome commented 5 years ago

I understand. Unfortunately I have no other reasons. Only those:

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.

loathingKernel commented 5 years ago

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.

doitsujin commented 5 years ago

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:

  1. Don't use it.

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.

misyltoad commented 5 years ago

The global scope is just the same as the default section you are proposing. This is completely unnecessary.

pchome commented 5 years ago

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.

doitsujin commented 5 years ago

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.