Skip to content

Conversation

@AL2009man
Copy link
Contributor

@AL2009man AL2009man commented Sep 17, 2025

Originally: To change between DirectX 12 and Vulkan API: you'd need to go to config.toml's GraphicsAPI to either D3D12 or Vulkan. Now, you can choose Graphics APIs directly through the In-Game Video Settings, addressing #501

image

If Auto is selected (assuming you selected Auto and you restarted the game): the "Currently Using" text wll be showing if it's DirectX 12 (DX12) or Vulkan (VULKAN) renderer, this should make it easier to troubleshoot without needing to press [F1].

however: there are three things that needs to be updated and tested before this PR to be merged

  • Ensure that the Graphics API UI should NOT be shown when using Linux&MacOS/Vulkan only build
    • Right now: I have not tested the Linux version, and I don't have access to the Mac device at the moment
  • Localized the title and description across all languages
    • right now: it's very "Google Translated" in a placeholdery way beyond English text (that can be updated, too!), those needs to be replace with proper localized text
  • Thumbnail image, with DirectX 12 and Vulkan logos (optional)

Originally: To change between DirectX 12 and Vulkan API: you'd need to go to `config.toml` 's GraphicsAPI to either D3D12 or Vulkan. Now, you can choose Graphics APIs directly through the In-Game Video Settings!
@blueskythlikesclouds
Copy link
Member

This is something we discussed during development and deliberately not added to the options menu due to so much misinformation going around Direct3D 12 vs Vulkan. People switch to Vulkan thinking it makes their game run better when there are so many issues with it on Windows especially when it comes to driver performance.

I do not think this is an option we will ever be exposing in the user facing interface.

@AL2009man
Copy link
Contributor Author

AL2009man commented Sep 18, 2025

This is something we discussed during development and deliberately not added to the options menu due to so much misinformation going around Direct3D 12 vs Vulkan. People switch to Vulkan thinking it makes their game run better when there are so many issues with it on Windows especially when it comes to driver performance.

I do not think this is an option we will ever be exposing in the user facing interface.

If Red Dead Redemption 2, Baldur's Gate 3 and Deadlock, one of them is Triple-A commercially released game, let's users to changes Graphics API, then so can UnleashedRecomp. They're no excuse in the world where giving PC Players can fine-tune crucial graphics settings, it's the same level of energy as Digital Extreme not giving the ability to set 16x Anisotropic Filtering in Warframe for insane reasons.

Not everyone is familiar with config.toml and they'll have to go out of their way to find out about it, heck: they might prefer using Vulkan over DX12 due to other hardships with other commercial games (and I'm one of those people)...and might not even be aware that Vulkan exists on the Windows build.

Please reconsider, and if you REAAAALY don't wanna make it easy to access: at least make it easily accessible without requiring users to burry around deep into Windows files just to switch. Take notes from how Massive Entertainment's Avatar: Frontiers of Pandora approach their "Unobtanium" Graphics setting preset, as it's only accessible via launch argument.

edit: Alternatively; adding the ability to switch Graphics APIs via Launch Arguments like selected Unity-based games already does, like typing -vulkan or -dx12, at least it's slightly easier than AppData.

@blueskythlikesclouds
Copy link
Member

Launch argument might be acceptable, but what is your use case for Vulkan on Windows exactly? The only case I can understand is working around graphical bugs which don't happen on NVIDIA or AMD anyway. Besides that Vulkan has nothing over D3D12, you have one frame of extra latency due to lacking native DXGI and the CPU impact is much higher.

@AL2009man
Copy link
Contributor Author

AL2009man commented Sep 18, 2025

Launch argument might be acceptable, but what is your use case for Vulkan on Windows exactly? The only case I can understand is working around graphical bugs which don't happen on NVIDIA or AMD anyway. Besides that Vulkan has nothing over D3D12, you have one frame of extra latency due to lacking native DXGI and the CPU impact is much higher.

for my case: it's a matter of personal preference, due to poor experience with commercially shipped DX12 games, really more down to do with stability. It's rare to find a DX12-based commercial game that is actually stable.

That's why, whenever given the option: I try to use Vulkan as my primary Graphics API whenever possible (even if I'm Nvidia GPU + AMD CPU). The vast majority of games that I noticed tends to let you do that via Launch arguments, but some (as I mentioned earlier) gives you a more direct button switch that is easily accessible to the end-user.

Basically: if we wanna do the Launch argument method: I can close this PR infavor of Launch argument.

@blueskythlikesclouds
Copy link
Member

blueskythlikesclouds commented Sep 19, 2025

Okay, but how does Unleashed Recompiled work in D3D12 compared to Vulkan for you? I'm trying to understand why choosing graphics API is something majority of the user base would want. Nearly all data points at Vulkan working worse than D3D12 for this project on Windows. Other games exposing the option does not mean much for us. What matters is how frequently the option would need to be used and whether it'd be beneficial for majority of the user base.

@AL2009man
Copy link
Contributor Author

Okay, but how does Unleashed Recompiled work in D3D12 compared to Vulkan for you? I'm trying to understand why choosing graphics API is something majority of the user base would want. Nearly all data points at Vulkan working worse than D3D12 for this project on Windows. Other games exposing the option does not mean much for us. What matters is how frequently the option would need to be used and whether it'd be beneficial for majority of the user base.

in UnleashedRecomp's case: it works as I would expect from a game whose developer actually knows how to properly use DirectX 12.

at the same time: I do believe Vulkan works better on AMD/Intel cards (as it was the case back in #502) than on Nvidia's, there is a definite use-cases as a backup or fallback. otherwise: John Linneman and Alex Batallia of Digital Foundry wouldn't know that it's possible to switch between DX12 and Vulkan since it's not easily accessible outside of config.toml

@blueskythlikesclouds
Copy link
Member

blueskythlikesclouds commented Sep 19, 2025

Unfortunately I have several examples of people reporting me that their performance basically halvened once we put the Vulkan redirection in place for working around graphical bugs in old D3D12 drivers. In fact, some people went and switched back to D3D12 to squeeze out more performance, only to have graphical bugs again and come to report that to us, something that we deliberately made a workaround for!

I keep my stance that this option should not be directly exposed to the users. I don't think there's any point for supporting launch arguments, either. It's not really much different than having it in the config.toml.

@AL2009man
Copy link
Contributor Author

AL2009man commented Sep 19, 2025

I keep my stance that this option should not be directly exposed to the users. I don't think there's any point for supporting launch arguments, either.

If that's going to be the case, then Launch argument will have to be a compromised between "exposing directly" and "not wanting the general public having access to it".

Both serves the same purpose, but the only difference is that one is a far more convenient/standardized and far quicker way to change it than learning how to find a AppData (if I recall: that file is hidden by default?) file > UnleashedRecomp and do it from there...low-key be more useful for non-Steam Shrotcuts or Big Screen Interfaces. :/

edit: for now: I'll be closing this PR until further notice...unless a wave of people suddenly got interest on it.

@AL2009man AL2009man closed this Sep 19, 2025
@blueskythlikesclouds
Copy link
Member

You're missing my point. I'm saying that the default graphics API the Auto option gives you is already what users would need to play the game. There's absolutely no reason for anyone to tinker with the graphics API option as of the latest version. The only reason to switch would be probably user curiosity, and I'm sure such user would go the lengths to figure out how to edit this config.toml file anyway.

And yeah sure. I'll also be closing the issue you referenced since I made my stance clear.

@DeaTh-G
Copy link
Contributor

DeaTh-G commented Sep 19, 2025

I agree with Skyth's points here, exposing this option to the game's menus will lead to more problems than solutions on the long term.

We already have the Auto setting route people to a specific Graphics API depending on certain vendor information or driver versions due to reports of graphical issues and providing the ability to easily switch off the correctly displaying API whilst gaining a couple FPS will result in false positive issues being created due to faulty driver implementations of the past. This code can be seen, and expanded here. Doing it this way ensures that the game shows up the most correct way to everyone.

As for the launch argument, it is quite frankly unnecessary, simply because of fact that from a user accessibility (which this option doesn't need for the above reasons) it is no different from including it in a configuration file within the AppData folder.
The end user would still need to explicitly go out of their way to learn about the existence of the launch arguments all the same as with the configuration file's location which is already explained here in the README.

The only benefit the launch argument would have is being able to more quickly switch between Graphics APIs, however this seems like an unnecessary use-case outside of development purposes as the user facing experience is ensured to be the best one possible through the way the project is coded and will continue to be coded.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants