-
Notifications
You must be signed in to change notification settings - Fork 776
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
Implement Direct3D 8 Frontend #3411
base: master
Are you sure you want to change the base?
Conversation
I think once we're at a point where this can be merged, I'd squash everything into one commit again, like we did for D3D9. Probably a good idea to rebase this whole thing now and sort out things like the build system changes though. |
Would it make sense to split off and merge the Direct3D 9 chances in this pull request separately? |
Ideally, yes. Any changes to common code as well. |
I'd make an exception for D3D9Bridge since that's just part of the d3d8 architecture. Everything else I can try to split off like #3408 |
Wouldn't squashing everything remove authorship information of the commits? There are commits from more than 1 person in the D8VK repo. |
Just gonna note here that for my own commits i don't care |
That's not really a problem. I don't think anyone will mind (I certainly don't). And for the record probably 98%+ of the code is Alpyne's work (and dedication) anyway. |
It's also possible to add everyone as coauthor if relevant. |
Yeah that. This is what we did with the d9vk merge as well, it's not that hard to make git put out a list of authors and add everyone as co-authors. |
Question, once merged will any upstream D3D8 workarounds in proton have to be removed? I ask because I got a patch merged for both Bloodrayne terminal cuts that force the local D3D8 wrapper to be used, as it fellback to wined3d otherwise and gave awful performance. |
I'm not sure how Proton handles dll overrides, but the situation will be a bit tricky for games that ship their own d3d8.dll for one reason or another, since a native override will load the dll they ship, not d8vk's. So the answer is ideally yes, they should be removed and replaced by a global override, however users may still have to manually rename/delete game shipped d3d8.dlls themselves to properly leverage d8vk, depending on what those dlls actually do. Some are just pass-throughs with some fixes, as in the case of Better Rayman, which is fine, but the BloodRayne games ship what is essentially d3d8to9, which is not what we want to load once d8vk gets merged. |
I've cleaned up the rest of |
idk, namespace d3d9 {
#include <guiddef.h>
#include <d3d9.h>
} didn't checked further, it compiles w/o all those redefines |
This compiles, but it'll just generate a bunch of useless structs in the d3d9 namespace, and __uuidof won't actually work for d3d9 objects. |
To clarify: it's closing and (re)opening brackets looks bugprone #define something \
} \
do_something \
{ but if others are ok with this, I don't care much too (for now). |
The macro is only used at the top level and is reset to default behavior immediately after including d3d9.h. I have never had an issue with Microsoft or MingW's d3d9.h. If anyone else is bothered by it I could come up with a new way to resolve UUIDs for namespaced types, but I don't think it's necessary. |
Not to nag, but just wanted to check in in the progress here. It seems that all the prerequisites have been merged, and it would be cool to see d3d8 support finally made official. |
While all the above actions are indeed checked, there will still be some refactoring and upcoming reviews that have to be addressed most likely, so the PR is still very much WIP at the moment. You can always use d8vk in the meantime, it's equally official (albeit downstream for now)... and very much functional. |
Hi anyone knows why this still dont be merged (appear 13 tasks done, seems all tasks) ? thanks |
There is a goal of having it merged for the dxvk 2.4 release. Just needs to be reviewed beforehand. |
Did a rebase of this PR over here, includes an additional commit that makes the native build work, which should fix the last TODO before reviewing/merging this? |
D8VK is far more feature complete at this point than I believe D9VK was when it was merged into DXVK in 2019. There are still maybe a few dozen edge case games that haven't been fixed yet but every game in this list plus many more do work at this point.
Issues that would need to be closed before merging: (a lot of this is just admin)
Things to do before merge:
[util] Allow switching log file at runtime #3516The warning disable in 7d45fb6Things that can be done after the merge:
Note about static linking: We are moving back to dynamic linking. The following games were fixed specifically when we added static linking, but currently work with the latest main even with dynamic linking:
Not having issues at any point in my testing include: Advent Rising. Not tested but speculated to maybe have had issues: Acceleration of Suguri 2, Acceleration of SUGURI X-Edition HD.