https://bugs.winehq.org/show_bug.cgi?id=39718
Bug ID: 39718 Summary: d3d9.dll trick for Fallout 3 no longer working in Steam Product: Wine Version: 1.7.55 Hardware: x86 OS: Mac OS X Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs@winehq.org Reporter: b.adamski@mac.com
Created attachment 52967 --> https://bugs.winehq.org/attachment.cgi?id=52967 Crash Log File
In order to get Fallout 3 work with Intel graphic boards, a modified d3d9.dll file needs to be installed in the game directory:
/Program Files/Bethesda Softworks/Fallout 3/d3d9.dll for the standalone version of Fallout 3.
/Program Files/Steam/SteamApps/common/Fallout 3 goty/d3d9.dll or /Program Files/Steam/SteamApps/common/Fallout 3/d3d9.dll for the Steam version of Fallout 3.
In addition the modified d3d9.dll file needs to get registered in winecfg. Add "d3d9 (native, builtin)" in the 'Libraries' tab.
The trick worked perfectly fine until Steam released an update on August 19th 2015. With the new Steam version the trick does no longer work. Fallout 3 crashes when starting a new game or loading a save game. Please find the crash log attached. This is a different crash then the typical "new game crash" that the d3d9 trick is supposed to solve.
There seems no impact from OS X or Wine engine updates. The standalone version of Fallout 3 is not affected, the trick still works absolutely fine here.
I did not find any similar reports about Fallout 3 in Steam on Wine under Linux or natively in Steam on Windows.
You can download the standalone wrapper version for OS X here: http://portingteam.com/files/file/8182-fallout-3-goty/
You can download the Steam wrapper version for OS X here: http://portingteam.com/files/file/8213-fallout-3-and-fallout-new-vegas-on-st...
You find a forum discussion about the problem here: http://portingteam.com/topic/10637-fallout-3-d3d9dll-trick-for-intel-gpus-no...
https://bugs.winehq.org/show_bug.cgi?id=39718
mactrix b.adamski@mac.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |b.adamski@mac.com
https://bugs.winehq.org/show_bug.cgi?id=39718
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
--- Comment #1 from Austin English austinenglish@gmail.com --- I'm not sure that we want to support a 'native' d3d9 (but that's a question for the d3d guys), but could you please run a regression test to find out what changed: http://wiki.winehq.org/RegressionTesting
https://bugs.winehq.org/show_bug.cgi?id=39718
--- Comment #2 from Nikolay Sivov bunglehead@gmail.com --- Yes, from Wine point of view it's more interesting to get it work without any modifications, and random third party dlls. If some modified dll taken from Wine doesn't work with current Wine anymore you should ask a person who developed this custom version. I'd say, invalid.
https://bugs.winehq.org/show_bug.cgi?id=39718
--- Comment #3 from Sebastian Lackner sebastian@fds-team.de --- (In reply to mactrix from comment #0)
I did not find any similar reports about Fallout 3 in Steam on Wine under Linux or natively in Steam on Windows.
Its a bit difficult to say if the incompatibility issue with this replacement dll is a valid bug, when you don't know if it works on Windows. Based on the fact that it also still works with older standalone versions, I fear there is not much we can do.
The main issue (Fallout 3 crashes on Intel graphic cards) might be valid though. Please provide a new log without replacement dlls or other overrides installed.
Is there any information available what this dll is supposed to do?
https://bugs.winehq.org/show_bug.cgi?id=39718
Michael Stefaniuc mstefani@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|regression | CC| |mstefani@redhat.com
--- Comment #4 from Michael Stefaniuc mstefani@redhat.com --- I'll let others decide if this is invalid or not. But it definitely isn't a Wine regression and a regression test in Wine won't help:
"The trick worked perfectly fine until Steam released an update on August 19th 2015. With the new Steam version the trick does no longer work."
https://bugs.winehq.org/show_bug.cgi?id=39718
--- Comment #5 from Rosanne DiMesio dimesio@earthlink.net --- (In reply to mactrix from comment #0)
You can download the standalone wrapper version for OS X here: http://portingteam.com/files/file/8182-fallout-3-goty/
You can download the Steam wrapper version for OS X here: http://portingteam.com/files/file/8213-fallout-3-and-fallout-new-vegas-on- steam/
That's Wineskin.
https://bugs.winehq.org/show_bug.cgi?id=39718
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
--- Comment #6 from Austin English austinenglish@gmail.com --- (In reply to Michael Stefaniuc from comment #4)
I'll let others decide if this is invalid or not. But it definitely isn't a Wine regression and a regression test in Wine won't help:
"The trick worked perfectly fine until Steam released an update on August 19th 2015. With the new Steam version the trick does no longer work."
Ah, Steam change, not Wine. I'm going to say invalid until there's evidence otherwise.
https://bugs.winehq.org/show_bug.cgi?id=39718
--- Comment #7 from Rosanne DiMesio dimesio@earthlink.net --- (In reply to Sebastian Lackner from comment #3)
The main issue (Fallout 3 crashes on Intel graphic cards) might be valid though.
That was already reported and closed as invalid in bug 36226. According to that bug report, "The game requires ATI or Nvidia graphics cards" and the minimum system requirements listed on the Steam store page for Fallout 3 confirm that.
However, AFAICT the hacked dll originated on Windows and was reported to work there (http://forums.techgage.com/showthread.php?t=5052), so it could be argued that it should work in Wine, too, if it still works in Windows since that Steam update.
https://bugs.winehq.org/show_bug.cgi?id=39718
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #8 from Austin English austinenglish@gmail.com --- Closing.
https://bugs.winehq.org/show_bug.cgi?id=39718
--- Comment #9 from mactrix b.adamski@mac.com --- All,
I appreciate the feedback.
Yes, Fallout 3 only supports ATI and Nvidia cards. However, due to its popularity the d3d9 trick is the only possible workaround to make the game work on Intel GPUs, which are quite common these days. As I said the d3d9 trick worked perfectly on OS X with Wine until Steam released an update on Aug 19th.
The trick still works perfectly fine with the standalone version of Fallout 3 (no Steam involved).
I am unable to interpret the crash log so I can't say what has changed in Steam that causes the new crash.
If you want to review the situation without the modified d3d9.dll file then check these two bugs:
https://bugs.winehq.org/show_bug.cgi?id=32973
https://bugs.winehq.org/show_bug.cgi?id=36226
https://bugs.winehq.org/show_bug.cgi?id=39718
mactrix b.adamski@mac.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |UNCONFIRMED Resolution|INVALID |---
--- Comment #10 from mactrix b.adamski@mac.com --- Sorry, I think you closed this bug too quickly as invalid.
It's not the same issue like bug 36226, otherwise I wouldn't have posted it.
Claiming limited support for ATI and Nvidia graphic cards is not correct as the d3d9 trick adds support for Intel GPUs. Even if it's more like an unofficial hack it should work just fine.
The d3d9 trick works fine with the standalone version of Fallout 3 on OS X under Wine. It only stopped working with the Steam version so the reasons for this must be something else.
I am going to change the status back to Unconfirmed for a second look.
https://bugs.winehq.org/show_bug.cgi?id=39718
--- Comment #11 from Rosanne DiMesio dimesio@earthlink.net --- The question is, does the dll still work in Windows since the Steam update? If the answer is no, the problem is not a Wine bug.
https://bugs.winehq.org/show_bug.cgi?id=39718
--- Comment #12 from mactrix b.adamski@mac.com --- (In reply to Rosanne DiMesio from comment #11)
I fully agree but I couldn't figure it out. I don't have Boot Camp with Windows and I couldn't find similar reports for Windows on the web.
In general users struggle to get Fallout 3 to work but I couldn't find any specific reports that the d3d9 trick stopped working under Steam.
Is anyone able to find any hint in the crash log?
https://bugs.winehq.org/show_bug.cgi?id=39718
--- Comment #13 from Bruno Jesus 00cpxxx@gmail.com --- Is the crash consistent or it changes between attempts?
If wine is compiled with debug symbols the backtrace will be more complete, maybe giving a better clue.
https://bugs.winehq.org/show_bug.cgi?id=39718
--- Comment #14 from mactrix b.adamski@mac.com --- (In reply to Bruno Jesus from comment #13)
Is the crash consistent or it changes between attempts?
100% consistent and reproducible:
Removing the modified d3d9.dll file launches the game but causes a crash a few seconds later (see Bug 32973). This is 100% consistent and reproducible even on native Windows. This issue is unrelated to Wine or OS X.
Having the modified d3d9.dll file enabled in the Steam version from Aug 19th or later causes Fallout 3 to crash instantly when clicking "New", "Continue" or after loading a save game. It's a different issue and crash than reported in Bug 32973.
The d3d9 trick works fine with Steam versions before Aug 19th and with the standalone version (no Steam involved) of Fallout 3. I don't know what happens in a native Windows setup.
https://bugs.winehq.org/show_bug.cgi?id=39718
swswine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |swswine@gmail.com
--- Comment #15 from swswine@gmail.com --- I've googled for this d3d9.dll hack for Fallout 3, here is the description from it's README:
"the D3D9.dll file should go into your fallout 3 file. it will trick the game into thinking you have an nvidia geforce 7000."
Have anyone tried to trick the game through Wine useful registry key: HKEY_CURRENT_USER/Software/Wine/Direct3D/VideoPciVendorID and VideoPciDeviceID? I do not have the game to try myself, but it is likely easier to make the same hack through Wine (this way or maybe some other) rather than to make custom d3d9 dlls always work.
https://bugs.winehq.org/show_bug.cgi?id=39718
--- Comment #16 from mactrix b.adamski@mac.com --- (In reply to swswine from comment #15)
Well, it depends the point of view which of the two approaches is easier. For me it's way easier to place a file into a folder rather than editing a registry key.
If you give me detailed instructions then I can give it a try.
https://bugs.winehq.org/show_bug.cgi?id=39718
--- Comment #17 from swswine@gmail.com --- Created attachment 52994 --> https://bugs.winehq.org/attachment.cgi?id=52994 Registry file to make wine report NVIDIA GeForce Go 7300 GPU
(In reply to mactrix from comment #16)
(In reply to swswine from comment #15)
Well, it depends the point of view which of the two approaches is easier.
Yes, I am saying from the point of view of making such a workaround.
If you give me detailed instructions then I can give it a try.
1. Run regedit.exe under wine prefix you use to run the game
2. Import attached registry file.
The card reported by wine d3d subsystem should be now NVIDIA GeForce Go 7300. I just chose the card from the list recognized by wine closest to 7000, I do not know if the game supports this particular one. Maybe some other should be selected (is there a list of supported cards somewhere)?
After your testing is finished remove registry values (those 2 in registry file) from registry if you don't want to trick all the other apps under this wine prefix.
https://bugs.winehq.org/show_bug.cgi?id=39718
--- Comment #18 from mactrix b.adamski@mac.com --- (In reply to swswine from comment #17)
Cool. The game no longer crashes with the imported registry file (and by removing the d3d9.dll file and the winecfg entry). Quality settings are set to 'Low' but it works. I don't know if the GeForce Go 7300 is the most suitable choice.
Thanks for the tip, though it's a bit complex to explain to average users.
Also I didn't understand the part how to exclude other apps from the modified registry and to only apply it to Fallout 3.
https://bugs.winehq.org/show_bug.cgi?id=39718
--- Comment #19 from swswine@gmail.com --- (In reply to mactrix from comment #18)
(In reply to swswine from comment #17)
Cool. The game no longer crashes with the imported registry file (and by removing the d3d9.dll file and the winecfg entry). Quality settings are set to 'Low' but it works. I don't know if the GeForce Go 7300 is the most suitable choice.
Is the 'Low' is an automatically imposed limit or the game just don't work if you set higher settings? If the first is true than changing video card ID to some newer one should help, otherwise changing the card reported still has a chance to help but less likely.
Thanks for the tip, though it's a bit complex to explain to average users.
Well, I suppose if users can find and copy a custom dll for the fix than they can find and import registry file equally well (this should work just by clicking the file in Explorer actually). It is also safer as almost no chance to get a malware with such a fix. If you know some places where the players of Fallout 3 search for such sort of tricks, maybe it would be a good idea to deliver this registry file there.
Also I didn't understand the part how to exclude other apps from the modified registry and to only apply it to Fallout 3.
You can't within the same wine prefix. So you should either use a separate wine prefix for Fallout 3 or remove/add those keys when required. The first variant (to keep dedicated wine prefixes for different apps) is quite a common approach actually. If not to bother switching them manually (and also easily switch wine versions), PlayOnLinux manages these prefixes perfectly for me.
https://bugs.winehq.org/show_bug.cgi?id=39718
--- Comment #20 from mactrix b.adamski@mac.com --- (In reply to swswine from comment #19)
I included the modified d3d9.dll file in my ports, the user only needs to add the d3d9 entry in winecfg if his Mac is equipped with an Intel GPU. If you read all the reports out there then you recognize that users struggle a lot with Fallout 3. My port with detailed instructions was the first to work on Macs with Intel graphic boards which is the majority of Macs these days.
In addition to the standalone version I also got the Steam version to work but the trick stopped working with the Steam release from Aug 19th. Through Steam I was also able to make Fallout Las Vegas work on OS X, which was pretty sweet. It's very nice to have both Fallout titles work within the same Steam wrapper on OS X. If this isn't possible anymore with the modified registry and I need to different wrappers then I can also point to the standalone version of Fallout 3 where the bug doesn't occur.
https://bugs.winehq.org/show_bug.cgi?id=39718
--- Comment #21 from swswine@gmail.com --- (In reply to mactrix from comment #20) It's very nice to have both Fallout titles work within the
same Steam wrapper on OS X.
I think most likely standalone Fallout won't suffer from this registry tweak, so it might be still possible. The only thing to do is probably to find a better choice for device ID if it really affects supported quality settings.
dlls/wined3d/wined3d_private.h has the list of device IDs for cards it knows (for nvidia the constants are named CARD_NVIDIA_...). You can try changing device ID to 0x0FD1 for instance which stands for GeForce GT 650M), vendor ID should remain the same.
https://bugs.winehq.org/show_bug.cgi?id=39718
--- Comment #22 from Austin English austinenglish@gmail.com --- (In reply to mactrix from comment #20)
(In reply to swswine from comment #19)
I included the modified d3d9.dll file in my ports, the user only needs to add the d3d9 entry in winecfg if his Mac is equipped with an Intel GPU.
I don't think you should be shipping binary dlls from the internet with a Wine package.
https://bugs.winehq.org/show_bug.cgi?id=39718
--- Comment #23 from mactrix b.adamski@mac.com --- (In reply to Austin English from comment #22)
I don't think you should be shipping binary dlls from the internet with a Wine package.
Why? In terms of security reasons the same could be said for the Wine package itself, why should the Wine package be save? And what harm can a dll file do on a Mac?
https://bugs.winehq.org/show_bug.cgi?id=39718
--- Comment #24 from Austin English austinenglish@gmail.com --- (In reply to mactrix from comment #23)
(In reply to Austin English from comment #22)
I don't think you should be shipping binary dlls from the internet with a Wine package.
Why? In terms of security reasons the same could be said for the Wine package itself, why should the Wine package be save? And what harm can a dll file do on a Mac?
Wine itself is open source, binary dlls are not. Wine (and the dll) can do whatever the user has permission to do. A malicious attacker could make a modified dll that is aware of Linux/OSX and execute specific code for those environments, e.g., to read /etc/passwd, ~/.ssh/id_*, ~/.gnupg, look in ~/.mozilla for saved passwords, etc.
See also: http://wiki.winehq.org/FAQ#head-3cb8f054b33a63be30f98a1b6225d74e305a0459
https://bugs.winehq.org/show_bug.cgi?id=39718
--- Comment #25 from mactrix b.adamski@mac.com --- (In reply to Austin English from comment #24)
The specific dll file we are taking about here has been tested and reviewed. It is save and does not cause any harm. Asking the user to download this file from the open Internet is more risky as it can be replaced.
Wine is open source but the user still needs to trust the provider of a port, which is me in this case. I could include any kind of dirty crap within my Wine port if I wanted, dll files or whatever. It's a matter about trust. Since the ports got a few thousand downloads and no complaints can be found in the comments I think trust isn't the problem here. I am trying to fix a problem and that dll file is part of the solution. Like it or not.
https://bugs.winehq.org/show_bug.cgi?id=39718
--- Comment #26 from Nikolay Sivov bunglehead@gmail.com --- I don't think we care about modified Wine dlls that you're using, it's not a part of a project once you modified it, and it's immediately unsupported because of that (unless of course you can describe modifications you made to it, attach a diff etc). Replacing Wine dll with dlls from older releases is not supported too of course, it might work for you, until it doesn't. If registry override from comment 17 works for you, that's what you should be using.
https://bugs.winehq.org/show_bug.cgi?id=39718
--- Comment #27 from mactrix b.adamski@mac.com --- (In reply to Nikolay Sivov from comment #26)
I fully agree and I wouldn't raise this issue if the dll wouldn't work at all.
The question for me is why did the dll work perfectly fine with Steam versions before Aug 19 and why does the dll work perfectly fine with the standalone version of Fallout 3? The dll only causes a crash with the Steam version of Fallout 3 and only with Steam versions from Aug 19 and later.
https://bugs.winehq.org/show_bug.cgi?id=39718
--- Comment #28 from Austin English austinenglish@gmail.com --- (In reply to mactrix from comment #27)
(In reply to Nikolay Sivov from comment #26)
I fully agree and I wouldn't raise this issue if the dll wouldn't work at all.
The question for me is why did the dll work perfectly fine with Steam versions before Aug 19 and why does the dll work perfectly fine with the standalone version of Fallout 3? The dll only causes a crash with the Steam version of Fallout 3 and only with Steam versions from Aug 19 and later.
From that evidence it seems obvious that it was triggered by a change in Steam.
https://bugs.winehq.org/show_bug.cgi?id=39718
--- Comment #29 from mactrix b.adamski@mac.com --- (In reply to Austin English from comment #28)
From that evidence it seems obvious that it was triggered by a change in Steam.
Yes it seems. In this case the issue would also occur on native Steam versions under Windows. So far I don't have confirmation this is the case.
https://bugs.winehq.org/show_bug.cgi?id=39718
--- Comment #30 from swswine@gmail.com --- (In reply to mactrix from comment #29)
Yes it seems. In this case the issue would also occur on native Steam versions under Windows. So far I don't have confirmation this is the case.
Your tweak d3d9.dll tricks the game by proxying IDirect3D9 interface and GetAdapterIdentifier method. In the game's point of view the effect is exactly the same as what happens when Wine tricks the game in it's method implementation (that's what we got through registry overload). Your crash log shows the crash in a different interface not related to Direct3D at all (it is in IDirectInput device). This means that there is most likely some memory corruption happens before the crash. Your custom d3d9 most likely has some bug in interface proxying (inaccurate reference counting/freeing of the interface). Such sort of bug may be invisible forever or may be triggered by some changes in the interface usage or implementation, or just happen randomly. Confirming whether it still works under Windows will really give you nothing. It may work, or crash, or crash sometimes, or crash on some slightly different configuration, or even begin to crash on some different computer with the same configuration. This is not related to Wine. It is practically not possible to fully simulate Windows environment in such aspects, it would mean copying it completely. There are only two ways to go: - a good one: use registry tweak (or ask Wine developers if they want to make this d3d configuration setting available per application through environment variables); - a bad one: rewrite tweak dll without the bug and test it. The last one is really ugly if to talk about port using Wine: you already have an open source dll to tweak in wine and whatever you want to do in this sense is easier and more reliable to do there, even if to hardcode card info right into GetAdapterIdentifier as your tweak dll does.
https://bugs.winehq.org/show_bug.cgi?id=39718
--- Comment #31 from mactrix b.adamski@mac.com --- (In reply to swswine from comment #30)
Thanks for the great feedback.
That makes me wonder, do you think this would be a suitable feature request for Wine:
Allowing to mimic various graphic adapters through registry but within a user friendly interface, e.g. through winecfg. A user friendly way would be similar to the 'Applications settings' in winecfg where the user can configure different Windows versions to different exe files. Having this ability also for graphic adapters would be a great user experience.
What do you think?
https://bugs.winehq.org/show_bug.cgi?id=39718
--- Comment #32 from swswine@gmail.com --- (In reply to mactrix from comment #31)
Allowing to mimic various graphic adapters through registry but within a user friendly interface, e.g. through winecfg. A user friendly way would be similar to the 'Applications settings' in winecfg where the user can configure different Windows versions to different exe files. Having this ability also for graphic adapters would be a great user experience.
What do you think?
Well, I am not a Wine developer and I am not sure so far if my opinion on the matter makes sense. Just a few thoughts on that: 1. Playing with Direct3D tweaks available now in the registry is for advanced users. It is much more advanced than just to go and change something in the registry with regedit when you know what should be changed. I am not sure things like that should be available in the winecfg GUI level. The registry keys are documented in Wine. 2. These tweaks are available through winetricks and PlayOnLinux (while PlayOnlinux does not show card model tweak, just the other options). I do not know much about Wineskin, maybe it has that also? 3. I would think that these settings could be potentially duplicated in environment variable settings (like WINEDLLOVERRIDES for dll overrides). This would allow for per-app setting. But I may be missing something: maybe Wine developers had some solid reasons not doing so. Or these options are just too exotic to deal with them neatly. 4. I've read description of your port on portingteam, which includes manual DLL override through winecfg. You can ask user to apply registry file with video card tweak (dll override is now not required). It will be just easier for the user than manually overriding dlls. BTW dll override you did through winecfg can be done through reg file also. I do not know what is Mac port wrapper exactly, if it has some place for scripting you could automate the whole thing.
https://bugs.winehq.org/show_bug.cgi?id=39718
--- Comment #33 from mactrix b.adamski@mac.com --- (In reply to swswine from comment #32)
Sorry for being such a Mac moron but UX in Wine already sucks big time because it's made by engineers for engineers, not for end users and especially not for Mac users. :-)
PlayOnlinux or using winetricks in Wineskin don't make it much better, UX still sucks. One problem with winetricks is that you apply it to the entire wrapper. In my case I want to run the PC version of Steam in one wrapper and then Fallout 3 and Fallout New Vegas through that Steam setup. I only need to apply the d3d9 trick for Fallout 3, not for Fallout New Vegas so winetricks or the registry overwrite is not suitable here. Wineskin allows to apply different Windows versions to different exe files through a pretty good winecfg interface. So I can set Fallout 3 to run in Windows XP mode while Fallout New Vegas can run in Windows Vista mode and Steam itself can run in Windows 7 mode (just as an example) - all this within the same wrapper. This is nicely done in winecfg under Wineskin, that's why I am wondering if the same couldn't be done for graphic adapters.
https://bugs.winehq.org/show_bug.cgi?id=39718
--- Comment #34 from Austin English austinenglish@gmail.com --- (In reply to mactrix from comment #29)
(In reply to Austin English from comment #28)
From that evidence it seems obvious that it was triggered by a change in Steam.
Yes it seems. In this case the issue would also occur on native Steam versions under Windows. So far I don't have confirmation this is the case.
Triggered by, not necessarily caused by. It may end up being valid or invalid, the point is that the Steam changes were the first appearance of the bug.
https://bugs.winehq.org/show_bug.cgi?id=39718
--- Comment #35 from swswine@gmail.com --- (In reply to mactrix from comment #33)
(In reply to swswine from comment #32)
PlayOnlinux or using winetricks in Wineskin don't make it much better, UX still sucks. One problem with winetricks is that you apply it to the entire wrapper. In my case I want to run the PC version of Steam in one wrapper and then Fallout 3 and Fallout New Vegas through that Steam setup. I only need to apply the d3d9 trick for Fallout 3, not for Fallout New Vegas so winetricks or the registry overwrite is not suitable here. Wineskin allows to apply different Windows versions to different exe files through a pretty good winecfg interface. So I can set Fallout 3 to run in Windows XP mode while Fallout New Vegas can run in Windows Vista mode and Steam itself can run in Windows 7 mode (just as an example) - all this within the same wrapper. This is nicely done in winecfg under Wineskin, that's why I am wondering if the same couldn't be done for graphic adapters.
As far as I understand what is UX, the word "UX" cannot stand near setting PciVendorID manually either way (through some GUI, regedit or vim). The same holds true for overriding dlls manually. If you care about UX Apple way you simply can't ask users to set such sort of scary things at all. If you are already asking users to run winecfg each time to switch between the games (or even just once to install the game), why can't you just give them 2 reg files instead to double click? Or just make a shell script wrappers for game start which will update registry each time?
https://bugs.winehq.org/show_bug.cgi?id=39718
--- Comment #36 from mactrix b.adamski@mac.com --- (In reply to swswine from comment #35)
I am not saying my approach with the d3d9 file offers the best UX. I am proposing a better UX through official settings in winecfg. Like this I could prepare a suitable wrapper for the end user.
You also seem to misunderstand something with my current approach. The user does not need to run winecfg each time they switch between the games. You set it up once and you're done.
https://bugs.winehq.org/show_bug.cgi?id=39718
--- Comment #37 from Rosanne DiMesio dimesio@earthlink.net --- mactrix & sxwine: third party wrappers, including Wineskin and POL, are not supported here, and how to incorporate the workaround into such things is irrelevant to this bug. Please take that discussion to the Wineskin or POL forum.
https://bugs.winehq.org/show_bug.cgi?id=39718
mactrix b.adamski@mac.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
--- Comment #38 from mactrix b.adamski@mac.com --- I decided to solve this issue by using the registry trick (thanks swswine).
https://bugs.winehq.org/show_bug.cgi?id=39718
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #39 from Austin English austinenglish@gmail.com --- Closing.
https://bugs.winehq.org/show_bug.cgi?id=39718
--- Comment #40 from mactrix b.adamski@mac.com --- FYI,
I updated my Steam wrapper to Wine 1.9.5 and also Steam got updated. The issue is gone. Not sure if the Wine or Steam update fixed it but the d3d9.dll trick is working again just like before.
-
wine-bugs＠winehq.org