Implement Direct3D 8 Frontend

[AlpyneDreams]

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)

• Compile for Linux like dxvk-native AlpyneDreams/d8vk#15

Things to do before merge:

• Separate PR's for changes to common code and D3D9
  • [d3d9] Fix crash if device is freed with bound textures #3408
  • [d3d9] Initialize m_mapFlags to 0 #3510 - b2b89ee
  • [dxso] Implement bem instruction #3511 - 4a7c627
  • [d3d9] Fix std::hex in D3D9CommonTexture #3514 - 0dbc876
  • [util] replaceNaN: Use unaligned SIMD _mm_loadu_ps #3515 - 125cb1f
  • [build] Update libdisplay-info #3517
  • [util] Add str::split #3519
  • [util] Allow switching log file at runtime #3516
  • [d3d9] Add D3D8Bridge for d3d8 #3518 - DxvkD3D8Bridge
  • [util] replaceNaN: Align result #3547
  • The warning disable in 7d45fb6
• Remove setup_d3d8.sh and build_d3d8.sh?
• Rebase everything now and sort out things like build system changes
• Squash into one mega commit with co-authors - GitHub will do this for us

Things that can be done after the merge:

• [d3d8] Implement Dref scaling and fixed-function depth textures #3565
• Remove any upstream d3d8 workarounds in Proton
• CopyRects edge cases and optimizations
• All the issues
  • D3D9 Formats: AL16, R16, L16, AR16 AlpyneDreams/d8vk#68
• Plus these fun but minor things:
  • Support for "Curved Surfaces" aka ATI TruForm AlpyneDreams/d8vk#148
  • Dithering AlpyneDreams/d8vk#52
• Upstream: D3D8-related issues AlpyneDreams/d8vk#45
  • Attempting to daisy-chain D3D8TO9 with DXVK in C&C Generals ZH on Win10 #1498
  • [D3D9] Blood Rayne #1828 (Apparently works?)
  • Unreal Tournament 2004: Cannot tab back into the game #2605 (Apparently works?)
  • Marker interface for the D3D9 implementation #1798
• Upstream: D3D8 fixes that should be applied to D3D9 or DXSO too AlpyneDreams/d8vk#44
  • f974535 - [d3d8] EndScene on Reset (maybe?)
  • VSH: Inverse square root (rsq) hardcoded swizzle AlpyneDreams/d8vk#43
• D3D8-specific workarounds already in upstream AlpyneDreams/d8vk#40

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:

• Empires Dawn of the Modern World
• Anito: Defend a Land Enraged

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.

[doitsujin]

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.

[PatrickvL]

Would it make sense to split off and merge the Direct3D 9 chances in this pull request separately?

[doitsujin]

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.

[AlpyneDreams]

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

[qwertychouskie]

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.

Wouldn't squashing everything remove authorship information of the commits? There are commits from more than 1 person in the D8VK repo.

[Blisto91]

Just gonna note here that for my own commits i don't care

[WinterSnowfall]

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.

[Blisto91]

It's also possible to add everyone as coauthor if relevant.

[doitsujin]

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.

[Bitwolfies]

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.

[WinterSnowfall]

Question, once merged will any upstream D3D8 workarounds in proton have to be removed?

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]

I've cleaned up the rest of d3d8_include.h

[pchome]

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.

idk,

namespace d3d9 {
#include <guiddef.h>
#include <d3d9.h>
}

didn't checked further, it compiles w/o all those redefines

[AlpyneDreams]

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. __mingw_uuidof is expected to be in the root namespace. We don't currently use __uuidof for d3d9 objects, so we could #define the macro as a no-op, but that feels lazy, and I think there's no point fixing what isn't broken.

[pchome]

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).

[AlpyneDreams]

To clarify: it's closing and (re)opening brackets looks bugprone
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.

[qwertychouskie]

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.

[WinterSnowfall]

just wanted to check in in the progress here.

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.

[mrdeathjr28]

Hi

anyone knows why this still dont be merged (appear 13 tasks done, seems all tasks) ?

thanks

[Blisto91]

There is a goal of having it merged for the dxvk 2.4 release. Just needs to be reviewed beforehand.

[flibitijibibo]

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?

https://github.com/flibitijibibo/dxvk/tree/d8vk