Throttle D3D12 wait loop.

[gofman]

And fix logging in it.

REFramework currently waits for d3d12.dll load by calling GetModuleHandleA() in a tight loop. That makes RE4 Demo load time with REFramework go up to ~15min in Wine / Proton. That is much less of an issue on Windows because the difference of loader locking model between modern Windows and Wine: on Wine, the loader lock is taken and spending most of the time in GetModuleHandleA() effectively stops loading the other DLLs for the most of the time. That is non-trivial to fix at once in Wine. Also, while on modern Windows this is much less of an issue (as loader lock is not taken for GetModuleHandle), it still generates a constant load in parallel to game's load and throttling this loop might improve loading time a bit on Windows as well.

[praydog]

Thanks for the PR. I did not really consider Proton here, nor did I even think this would be an issue. Mainly this was done because for some reason, the previous method of calling LoadLibraryA("d3d12.dll") constantly (only in RE4), caused the game to crash for some unexplainable reason, so had to switch to GetModuleHandleA.

[praydog]

A side note I guess: I don't know how this will fare in RE8. RE8 has some integrity checks that need to be patched almost immediately, so I'm not certain about the 50ms delay. The whole d3d12 waiting was done because it acts as a guaranteed signal that the executable has unpacked itself.

Same goes for MHRise, but I think the patch insertions are not as time-constrained.

[gofman]

A side note I guess: I don't know how this will fare in RE8. RE8 has some integrity checks that need to be patched almost immediately, so I'm not certain about the 50ms delay. The whole d3d12 waiting was done because it acts as a guaranteed signal that the executable has unpacked itself.

Same goes for MHRise, but I think the patch insertions are not as time-constrainted.

I guess if that depends on patching d3d12 right after load with certain games, the way it is done without delay is racy as well? Maybe in that case it can be done with LdrRegisterDllNotification()? The caveat here is the same loader lock (dll load notification is called with the lock held), although if all the patching action is performed by the same thread which received the notification it should be fine.