Implement Direct3D 8 Frontend #3411
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. |
AlpyneDreams
force-pushed
the
main
branch
2 times, most recently
from
4955b36
to
03dc731
Compare
|
Officially ready for first round of code review! |
|
Can do.
Fixed. That was left over from changes to the d3d9 meson.
This is exactly the same as the MingW implementation of this macro except it allows us to include d3d9 in a namespace. The macro is used a lot throughout d3d9.h. The program would not compile if d3d9 was not included in a namespace. I could re-format it maybe but I don't really see what's wrong with it specifically? |
Changed regex to cover both the retail and demo versions of the game.
|
|
|
Don't forget to change the Github repo description as well |
|
|
|
|
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.