nmlgc / ssg

秋霜玉 / Shuusou Gyoku
MIT License
22 stars 5 forks source link

Implement a 32-bit graphics mode #3

Closed nmlgc closed 1 year ago

nmlgc commented 2 years ago

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 both

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.

nmlgc commented 2 years 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: DDrawCompat 0 4 0 breakage 16-bit

And minor ones in 8-bit mode: DDrawCompat 0 4 0 breakage 8-bit

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.

nmlgc commented 1 year ago

Funded in ReC98 transactions T0212 and T0215.

nmlgc commented 1 year ago

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.