A finicky RPG from Hong Kong

[redunka-zver]

Hi, I hope I won't bother you too much, but I wonder if there could be any hope for playing this DX7 game on a modern OS, like Win7/10?

This is the game plus official patch: https://drive.google.com/drive/folders/1OTGcDUkIkMU14oDvkK2CWTo7AlIHap70?usp=share_link

Without applying updated EXE the game boots and plays first video in fullscreen, but the second video starts in a tiny window in the top-left corner of the screen. After the second video ends, that small window stays black while playing the game's main menu's music, and some invisible error messages start popping up (this all happens with or without DDrawCompat). Those errors don't appear when Win98 compat mode is enabled, but using it together with DDrawCompat makes the game freeze on second video somehow.

Out of other DDraw wrappers I think the closest one to work was WineD3D: the game will actually go into menu and gameplay, but the videos are black (although they're fullscreen). Apparently, with WineD3D the windows for videos also don't close off properly and linger in the background, sometimes interferring with the inputs. The DxWnd folks are having their try at this too, but it looks like they're not having much luck either, as mitigating one issue just seems to bring some another.

Then there's also that second EXE (official patch) that doesn't work at all for some reason. Always throws this error at startup and then a bunch of others that don't disappear even with Win98 compatibility mode. I tried using alternative load methods from the wiki in case if the game ignores local ddraw.dll, but that didn't help.

Not sure if there's any use in these, but here's logs from loading both updated and old EXEs (without any other compat settings enabled): DDrawCompat_logs.zip

I don't really mind if I would have to use DDrawCompat together with some other tool (like DxWnd), but I worry that the game might actually end up being a lost cause with all those issues and it won't ever work on anything higher than WinXP…

[ghotik]

I quickly sneak in just to say that the DxWnd team (hem..) would be glad to partecipate for everything may be unrelated to ddraw problems alone. My guess is that the game doesn't have ddraw problems only and maybe a combined configuration DxWnd+DDrawCompat could be a winning team. Regards, gho.

[ghotik]

I suspect that this game could be a collection of oddities. Anyway ... Trying to debug the game (attached to DxWnd, but in the initial steps this should make no big difference) and in the hope not to tell inaccurate informations, the initial error message comes from the general purpose error handling routine that meets an unexpected error 0x80004002. The error is returned from here:

CPU Disasm
Address   Hex dump          Command                                  Comments
0041946E  |.  FF11          CALL DWORD PTR DS:[ECX]

but do not expect this to be a ddraw error, in effect it is generated by the game executable here:

CPU Disasm
Address   Hex dump          Command                                  Comments
66CB237A  |.  B8 02400080   MOV EAX,80004002

after two memcmp operations:

CPU Disasm
Address   Hex dump          Command                                  Comments
66CB233C  |.  6A 10         PUSH 10                                  ; /count = 16.
66CB233E  |.  68 1824C866   PUSH 66C82418                            ; |buf2 = DDRAW.66C82418 -> 00
66CB2343  |.  FF75 0C       PUSH DWORD PTR SS:[EBP+0C]               ; |buf1
66CB2346  |.  E8 7802FEFF   CALL <JMP.&msvcrt.memcmp>                ; \MSVCRT.memcmp
66CB234B  |.  83C4 0C       ADD ESP,0C
66CB234E  |.  85C0          TEST EAX,EAX
66CB2350  |.- 74 2F         JZ SHORT 66CB2381
66CB2352  |.  6A 10         PUSH 10                                  ; /count = 16.
66CB2354  |.  68 542DC866   PUSH 66C82D54                            ; |buf2 = DDRAW.66C82D54 -> 85
66CB2359  |.  FF75 0C       PUSH DWORD PTR SS:[EBP+0C]               ; |buf1
66CB235C  |.  E8 6202FEFF   CALL <JMP.&msvcrt.memcmp>                ; \MSVCRT.memcmp
66CB2361  |.  83C4 0C       ADD ESP,0C
66CB2364  |.  85C0          TEST EAX,EAX
66CB2366  |.- 74 19         JZ SHORT 66CB2381

my guess is that the game is checking the ddraw GUID to match two possible values. In effect, using a DxWnd tweak that forces a NULL GUID for the DirectDraw session seems to bypass this initial error message so that you can enjoy the following ones ... :(

p.s. among other things I found remarkable the reference, in the chunk of assembly just inspected, of the reference to the GDI32.GdiEntry13 call, reported as an alias of the legacy DdQueryDisplaySettingsUniqueness function ( https://learn.microsoft.com/en-us/windows/win32/api/ddrawgdi/nf-ddrawgdi-ddquerydisplaysettingsuniqueness )

CPU Disasm
Address   Hex dump          Command                                  Comments
66CB22CE  |.  FF15 44E0D566 CALL DWORD PTR DS:[<&GDI32.GdiEntry13>]  ; [GDI32.GdiEntry13

[ghotik]

Wait a minute! I made a little confusion here, mixing the original and patched releases .... This is what I found: the "official fix" was built with no direct reference to ddraw:DirectDrawCreate, instead the developers used the ordinal 9 that probably WAS a reference to DirectDrawCreateEx but it no longer is and points now to DirectDrawCreateClipper. So, to cut the thing short, I edited the KLS.exe PE replacing the ordinal 9 with ordinal 8 and the game starts and work as a beauty! I still have to check if the same problem happens also for DirectSound and DirectInput, but at least I got the game finally running!

[ghotik]

DirectInput and DirectSound references seem ok, so there should be no need for further patching here. In attach the patched executable, good as long as Microsoft won't change the ordinal numbers again. Maybe a better patch would eliminate the ordinal numbers and replace them with function names, but not today. The game seems perfectly playable, but of course you can head to DxWnd for a locale translation (it seems to require a traditional Chinese Big5 locale support) and running it in window. KSL.patched.zip

[redunka-zver]

@ghotik, thank you so much for finally solving this case! With your patched executable (and .dxw config from the thread at SourceForge) it really does work wonderfully! Since DxWnd alone seems to be enough, I guess I should not waste Narzoul's time any more and close this issue now. ^^

[elishacloud]

the "official fix" was built with no direct reference to ddraw:DirectDrawCreate, instead the developers used the ordinal 9 that probably WAS a reference to DirectDrawCreateEx but it no longer is and points now to DirectDrawCreateClipper. I still have to check if the same problem happens also for DirectSound and DirectInput, but at least I got the game finally running!

@ghotik, Does the same issue happen with DirectSound and DirectInput? What was the final outcome of this game?

[ghotik]

@elishacloud: as I said the final result seems good and there are no troubles with DirectSound and DirectInput ordinal numbers, but the game being Chinese doesn't let me make a final judgement. Someone should try to test it a little more thoroughfully.