Closed nmlgc closed 1 year ago
Windows 11 22H2 added some sort of additional DLL injection prevention that DDrawCompat now needs to work around. I experienced that hangup on my system, so it might actually affect everyone.
However, narzoul not only released version 0.3.2 to fix just this issue, but also version 0.4.0 shortly after. That version introduces vast glitches in Shuusou Gyoku in 16-bit mode:
And minor ones in 8-bit mode:
With all the added configuration settings in 0.4.0, it might be possible to configure these glitches away, but why should we bother if the game runs perfectly on 0.3.2. In view of these developments, it might make sense to prioritize either this issue or #4 a bit higher.
At its core, DDrawCompat forces the game to run with a 32-bit primary surface, redirects all 16-bit and 8-bit rendering offscreen, and then upsamples the offscreen image to the primary surface. This raises the question of how much would be fixed if the game just ran at 32-bit itself:
diff --git a/GIAN07/GIAN.CPP b/GIAN07/GIAN.CPP
index 6860e4b..fd26093 100644
--- a/GIAN07/GIAN.CPP
+++ b/GIAN07/GIAN.CPP
@@ -78 +78,2 @@ extern void ConfigLoad(void)
- if(ConfigDat.BitDepth!=8 && ConfigDat.BitDepth!=16) break;
+ ConfigDat.BitDepth = 32;
+ if(ConfigDat.BitDepth!=8 && ConfigDat.BitDepth!=16 && ConfigDat.BitDepth!=32) break;
@@ -291 +292 @@ static void ConfigInit(void)
- ConfigDat.BitDepth = 8;
+ ConfigDat.BitDepth = 32;
Surprisingly, that's all it takes for the game to run at full speed on all systems we've tested so far. The graphical glitches in this mode are merely a result of some blitting routines not supporting 32-bit yet. Implementing that is way simpler than the original idea of merging DDrawCompat though, so I'll go for that.
The cheaper option for compatibility with modern Windows. For a more thorough option that would also enable ports to non-Windows systems, see #4.
While the pre-built DDrawCompat DLLs are basically all you need to get Shuusou Gyoku running flawlessly on modern Windows, their nature of being proxy DLLs may introduce additional issues. In my testing today, they just flat out weren't loaded if there was a
DWM8And16BitMitigation
set for the binary's path in bothHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers
andHKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers
Wine users on Linux will also need to manually configure a DLL override.
This can be as simple and cheap as defining a DLL name that's different from
ddraw.dll
and statically linking to that one, or we could just look at its source code and manually fix the actual issues that require the DLL in the first place.