Draft: hooklib: Add D3D11 and DXGI graphics hooks - [opened]

[icex2]

In GitLab by @felix on Oct 25, 2021, 22:19

Merges gfx -> master

New Feature

Summary

Add D3D11 and DXGI graphics hooks and a fullscreen fix for Initial D Zero.

Description

IDZ only supports D3D11 and Ongeki/Unity uses D3D11 by default so the existing D3D9 graphics hook would not apply to them. I also wanted to play Initial D Zero in full fullscreen or in borderless windowed.

Related Issue

The Initial D Zero fullscreen issue was documented and workaround binary patches were made and I like to run the game executables as close to stock as possible so I wanted to fix this at the API level.

How Has This Been Tested?

I tested Initial D Zero running in both windowed toggled via segatools.ini and seeing if it would run and stay maximized. I also tested to make sure Ongeki would startup and not crash in DXGI or D3D11 initialization (now I see why some people say that older Unity does not use D3D11 properly, they use both DXGI 1.0 and 1.1!).

Checklist

• Tested with the following games:
  • Initial D Zero 1.31
  • Initial D Zero 2.11
  • Initial D Zero 2.30
  • Ongeki 1.20
• Followed the developer (style) guidelines
• Updated existing doc of or add new doc to README file(s)
• Updated development documentation

[icex2]

In GitLab by @felix on Oct 25, 2021, 22:21

I marked this as a draft because there is some code duplication between IDXGIFactory::CreateSwapChain and D3D11CreateDeviceAndSwapChain. Should I factor out the code into a separate helper function?

[icex2]

In GitLab by @felix on Oct 25, 2021, 22:25

I also realized that CreateDXGIFactory2 is a thing so I will add a hook for that in case any game dynamically checks for it and also MSDN indicates it may be used internally by D3D.

[icex2]

In GitLab by @felix on Oct 25, 2021, 23:57

added 3 commits

• 690fd412 - fixup
• 5858caea - Draft: hooklib/gfx/dxgi.c: Add CreateDXGIFactory2 hook
• 14660f3f - Draft: hooklib/gfx/dxgi.c: Delegate IDXGIFactory hook selection to helper method

Compare with previous version

[icex2]

In GitLab by @felix on Oct 26, 2021, 24:00

added 4 commits

• f251283 - hooklib: Add D3D11 and DXGI graphics hooks
• b072f2d - idzhook: Force framed window for ServerBox.exe in graphics hook
• 636ed0f - Draft: hooklib/gfx/dxgi.c: Add CreateDXGIFactory2 hook
• a24cd0a - Draft: hooklib/gfx/dxgi.c: Delegate IDXGIFactory hook selection to helper method

Compare with previous version

[icex2]

Even this is likely never going to happen, I would check the return value for NULL and run into a controlled death rather than this just crashing without any clue.

Maybe we want to wrap malloc and realloc like bemanitools and have the guarding abstracted, so we don't have to do this everywhere all the time.

[icex2]

I might simplify this by just going with a static buffer size of MAX_PATH * 2. Or does the API imply some sort of edge cases?

Just call GetModuleFileNameW and if it returns an error, I would log it as an error with some info and just die.

[icex2]

Why do we need a a hook for d3d9 and d3d11 here? I would expect only one API to be active. Is there some kind of switch? If yes, how does the game (?) decide which one to use?

[icex2]

I would suggest moving this new block to a separate function to increase readability, e.g.

static void idz_force_fullscreen_serverbox(struct gfx_config* gfx_config)

[icex2]

I think this is fine for now, but might be worth moving the gfx related config stuff to it's own module under hooklib/gfx/config.h/.c

[icex2]

Why is this exposed to other modules now?

[icex2]

Regarding the general architecture, I would suggest to stick to a mostly copy-paste focused approach. We had a similar use-case in bemanitools with d3d8, d3d9 and d3d9ex hooks. Though most things are compatible, not all of them are.

IIRC I tried to re-use as much code as possible, but this created coupling that increased complexity and made it difficult to maintain: Say you fix something on a shared piece of code due to encountering an issue with d3d8. How do you know this is fine on the d3d9 and d3d9ex implementation? You would at least have to test one game using each API and trigger the specific code path.

Even at first glance it looks like copy-pasting increases maintenance, the experience from bemanitools shows the opposite.

Also, I would suggest to split those gfx configs and not use a shared one. Same reasoning.

[icex2]

Hm, that's a fair question. I think you are talking about the part "ensure window is maximized"? It's not very complex and cannot even be tested in isolation. I would stick to copy-pasting here for reasons given in my comment here.

[icex2]

That naming <_>

[icex2]

In GitLab by @tau on Oct 27, 2021, 24:42

I think there should be a separate "gfxhook" static library instead of making a nested directory inside hooklib.

[icex2]

In GitLab by @felix on Oct 27, 2021, 08:52

Luckily Microsoft has been mostly consistent with naming in this regard.

IDXGIAdapter
IDXGIAdapter1
IDXGIAdapter2
IDXGIAdapter3
IDXGIAdapter4
IDXGIFactory
IDXGIFactory1
IDXGIFactory2
IDXGIFactory3
IDXGIFactory4
IDXGIFactory5
IDXGIFactory6
IDXGIFactory7
etc