The CD version will have three renderer mode to choose from: Direct3D, Software, 3dfx(Glide).
3dfx: not test
Direct3D: using Dxwnd, the game give an error message
Software: run okay but very choppy, frame-skipping all over the place. I tried the "Optimize CPU" and some flag on the Compat. tab but no help either. Yet the game requires only Pentium 200MHz to run at highest setting...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This seems another interesting case! I don't know if I can help with the software emulation (it's always slow, whenever you get it) but I'm curious about the Direct3D dielog: it talks about a failure, but the log shows no error.
B.t.w. I was almost sure it was one game I already managed, but it seems I was wrong!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2016-07-02
As I found on vogons forum, the game don't even work well for the target specs (Pentium IIs on a Voodoo2). Use Glide wrapper is the only solution.
About Direct3D mode, the game query the "B3D_DeviceInfo" key on registry, also call the SystemParametersInfo function but error 183 happen.
The SystemParametersInfoA: Action=61 error is ininfluent: it's an attempt to stop the screensaver, it could have been a good trail, but I neutralized the error and nothing changed. The game uses the B3D_DeviceInfo registry key to select one of the three dlls in the "Device libraries" subfolder (in effect, though the key is visible in hex code because it has extra info, it begins with the dll filename!).
A curious thing is that I deleted the B3D_DeviceInfo registry key to chose the sw mode and the game keeps remembering the same mode and telling the same error.
I doubt too that it never worked decently without 3DFX glide mode! But I want to see where this mysterioud D3D error comes from!
p.s. going out for weekend, I won't be so easily reached. Next week maybe I'm giving a little present...
Last edit: gho 2016-07-02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2016-07-02
That is strange. If I remove the B3D_DeviceInfo key then the game show a message to change the renderer, and I am able to switch to SW mode. Do you sure you not use the Emulate registry feature?
Ughr... more new topics incoming :-(
Last edit: Anonymous 2016-07-02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm bewildered!
I deleted the registry key, and the game keep selecting the D3D renderer.....
By the way, in Win10 fullscreen mode, the game works perfectly in D3D!!!
I tried to uninstall it, I did it successfully and now the game setup doesn't work any more!!!
Do I have to start believing in fairies, elfs and goblins?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2016-07-02
just keep believing in God and keep praying and just try to stay strong for the existence of this project, gho.
Last edit: Anonymous 2016-07-02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I chose the D3D renderer and 800x600 resolution 16-bit colors.
The installer was 16bit so I used virtual pc to install. No registry import was necessary since the game created the registry values when run for the first time.
However these registry values went into the Windows VirtualStore folder: [HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE\Wow6432Node\Melbourne House]
So if you have deleted the registry key and the game still remembers your rendering device check the VirtualStore registry path also. You can also do a search in regedit to find the values.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I fear that the demo could be a much easier target.
In the full version, the most annoying thing is the splash screen (the one with the "wait loading" text osr something similar) that loads the Data/pleaseWait.bmp image. This spash is covering my OllyDBG session, so tracking the point where the D3D error is originated is impossible.
This part is executed as a respose to the CreateWindow WM_CREATE message during window creation (just search from code referencing the string "pleaseWait.bmp"), so AFAIK should not depend on the CreateWindow args but from the window class (that is "DethKarz" exactly as the window name) but I can't find any RegisterClass call in the assembly.
Could it be that the class is registered by the installer? But if so, how could the installer register a class whose default WindowProc is within a separate exe?
There is something I'm missinge here .....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2016-07-03
This spash is covering my OllyDBG session, so tracking the point where the D3D error is originated is impossible.
Try again with Olly always on top (the option from Window tab), work for me.
Last edit: Anonymous 2016-07-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Finally I managed to run the game with OllyDBG without troubles. The trick is to set the max resolution to 640x480, so that DxWnd understands that the initial 640x480 splash screen is in fullscreen mode and take the appropriate countermeasures.
Now I've got to this partial result: the problem is that the routine @406940 returns a boolean flag, either 0 => error condition or 1 => ok.
The result code seems tied to the content of the memory global @53EE48 that gets set to 1 at 478676 and set to 0 at 47881D. Why that happens is yet to find.
Approaching the problem from another side, I found that you can run the game in nonwindowed and nonemulated mode ("Main / Run in window" unchecked and "DirectX / Emulation" set to None, Primary buffer or Locked surface). The curious thing is that the game stops working if you either set windowed mode or set emulated surface, it is not necessary to set both!
The suspect is that the error is somehow linked to the EnumDisplayModes or GetDisplayMode calls, maybe I return some capability that doesn't fit, but I checked the logs and found no clues.
Last edit: gho 2016-07-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hell!
Here is the damned piece of assembly that, within the Vertigo_Direct3D module and after a DirectDrawEnumerateExA call, loops trying to find a suitable video mode and is so picky to exclude all possibilities and return a fake directdraw error code 80004005 (see @3D816A7: MOV EAX, 80004005).
Since this loop doesn't go into error for unwindowed unemulated modes, I should only (sic!) understand what it doesn't like from my video modes emulation.
Hard? It's clear like water: it's a procedure with 3 nested loops, likely to check for screen size, color depth and, in the inner loop, something more that doesn't match expectations, so that the loop exits after having cycled all possible devices in 03D816B0 RETN after setting the 80004005 return code in 03D816A7. If the JE SHORT 03D816B1 at 03D8168A did jump, then the routine would terminate at 03D816CD RETN with a 0 (DD_OK) return code set in 03D816C7 XOR EAX,EAX.
So, the question is: what's written in DS:[EAX+138] ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2016-07-04
you mean you gonna to figure out what went wrong then? So just recall my previous post as 'easy' instead.
Last edit: Anonymous 2016-07-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, "easy" for me meant that it took no more that it took a whole day of debugging to understand what's going on. I'm so damnedly close..... the trick is that the renderer loops through the devica capabilities and needs a flag to be TRUE. This flag, when running in windowed or emulated mode is 0, in fullscreen mode is 1. The flag is at offset 0x138 from the beginning of a data structure, so I have to understand to what capability field it corresponds and the trick should become simple, force it to 1 and it should work.
No more words, let me continue .....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Bad news: I thought it was a field in the device capabilities descriptor, but it is not. It must be some other info that the application retrieves and places there for future use, but now I have to guess where it comes form. Apparently, it doesn't get from any hooked call, because the log trace doesn't show differences that may imply this change. More work, sic! .....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
At last, I discovered something very interesting.
As I said, the problem is that the D3D Vertigo driver does not find any suitable video mode to continue and stops. In doing that, it checks this boolean flag located in a data structure replicated for each device (so that it doesn't have a fixed address) and visible by searching for instructions with DS:[reg+13C] reference, where reg is EAX, ECX or EDX.
Now this flag is set here
0398154F MOV DWORD PTR DS[EDX+13C],1
and this happens after a series of conditional jumps that skip this part if the color depth is 8 bit, this one in particular:
039814F1 CMP ECX, 8
039814F4 JNE SHORT 0398150D
....
0398150A RETN 8
Wondering why this piece of code behaves differently with DxWnd windowized or emulated mode, here is the reason:
The game starts, sets a 32BPP splash fullscreen window (the one with "please wait"), then starts a 8BPP paletized fullscreen intro movie window. When this movie is terminated, the operating system automatically brings back the color depth to 32BPP and, when the color depth is checked, the flag is set.
When the game is started in windowed mode, it seems that there is no automatic recovery of the color depth, the screen remains at 8BPP color and the setting fails.
If the game is started in fullscreen but emulated mode, the color depth never changes, but DxWnd simulates the switch to 8BPP and nothing is telling that at the window closure the color depth should be logically recovered.
In conclusion, I believe that the problem is to find a general way to fake an automatic return to the original color depth in DxWnd. I could verify this by using some trick, just in case I'm wrong....
Last edit: gho 2016-07-06
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That is interesting. So if I understood this correctly the reason why the demo version works fine would be the lack of an intro movie.
If this is the case would deleting the intro movie file help? Or is it it streamed from the CD?
Also is the movie using smacker or bink or some other format? It might be possible to try a newer dll version at least if it is in .smk or .bik format.
Last edit: Riitaoja 2016-07-06
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Wow! the theory was correct.
I couldn't find where this damn'd "Melbourne House" splash movie came from, after having unmounted the CD and rename all possible file. Could it be embedded within the code? Now I am surprised by nothing at all. So, to cut this short, I hacked the exe getting rid of the splash movie call (quite easy to find by searching for the right CreateWindowEx call) and produced this Dethkarz.nomovie.exe file.
Guess what? The game works perfectly with default settings!
Now the job is not over, I still have to manage the resolution change for closed fullscreen window, but at least I know I am on the right path.
If you don't care for perfection, here is the patched game and some screenshots.
Saving the desktop color mode when it changes and recovering it after that the new primary window is destroyed seems a good solution on Win10, but it doesn't work on Win7! These platform details are kiling me. Too bad, I thought I had found the good solution .....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ah! here it is: it needed a "Force clipper" flag and a few fixes to make it working ok also on Win7.
Here is the replacement dll and the exported file. @cloudstr: where have you gone? You started this thread, you deserve the final word.
The CD version will have three renderer mode to choose from: Direct3D, Software, 3dfx(Glide).
This seems another interesting case! I don't know if I can help with the software emulation (it's always slow, whenever you get it) but I'm curious about the Direct3D dielog: it talks about a failure, but the log shows no error.
B.t.w. I was almost sure it was one game I already managed, but it seems I was wrong!
As I found on vogons forum, the game don't even work well for the target specs (Pentium IIs on a Voodoo2). Use Glide wrapper is the only solution.
About Direct3D mode, the game query the "B3D_DeviceInfo" key on registry, also call the SystemParametersInfo function but error 183 happen.
Last edit: Anonymous 2016-07-02
It's a desperate case! Even Wine staff surrended: https://appdb.winehq.org/objectManager.php?sClass=version&iId=4063&iTestingId=1131
The SystemParametersInfoA: Action=61 error is ininfluent: it's an attempt to stop the screensaver, it could have been a good trail, but I neutralized the error and nothing changed. The game uses the B3D_DeviceInfo registry key to select one of the three dlls in the "Device libraries" subfolder (in effect, though the key is visible in hex code because it has extra info, it begins with the dll filename!).
A curious thing is that I deleted the B3D_DeviceInfo registry key to chose the sw mode and the game keeps remembering the same mode and telling the same error.
I doubt too that it never worked decently without 3DFX glide mode! But I want to see where this mysterioud D3D error comes from!
p.s. going out for weekend, I won't be so easily reached. Next week maybe I'm giving a little present...
Last edit: gho 2016-07-02
That is strange. If I remove the B3D_DeviceInfo key then the game show a message to change the renderer, and I am able to switch to SW mode. Do you sure you not use the Emulate registry feature?
Ughr... more new topics incoming :-(
Last edit: Anonymous 2016-07-02
I'm bewildered!
I deleted the registry key, and the game keep selecting the D3D renderer.....
By the way, in Win10 fullscreen mode, the game works perfectly in D3D!!!
I tried to uninstall it, I did it successfully and now the game setup doesn't work any more!!!
Do I have to start believing in fairies, elfs and goblins?
just keep believing in God and keep praying and just try to stay strong for the existence of this project, gho.
Last edit: Anonymous 2016-07-02
The demo downloaded from here:
https://archive.org/details/DETHKARZ
Works fine on my Win7 PC with Dxwnd and without it too.
I chose the D3D renderer and 800x600 resolution 16-bit colors.
The installer was 16bit so I used virtual pc to install. No registry import was necessary since the game created the registry values when run for the first time.
However these registry values went into the Windows VirtualStore folder:
[HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE\Wow6432Node\Melbourne House]
So if you have deleted the registry key and the game still remembers your rendering device check the VirtualStore registry path also. You can also do a search in regedit to find the values.
I fear that the demo could be a much easier target.
In the full version, the most annoying thing is the splash screen (the one with the "wait loading" text osr something similar) that loads the Data/pleaseWait.bmp image. This spash is covering my OllyDBG session, so tracking the point where the D3D error is originated is impossible.
This part is executed as a respose to the CreateWindow WM_CREATE message during window creation (just search from code referencing the string "pleaseWait.bmp"), so AFAIK should not depend on the CreateWindow args but from the window class (that is "DethKarz" exactly as the window name) but I can't find any RegisterClass call in the assembly.
Could it be that the class is registered by the installer? But if so, how could the installer register a class whose default WindowProc is within a separate exe?
There is something I'm missinge here .....
Try again with Olly always on top (the option from Window tab), work for me.
Last edit: Anonymous 2016-07-04
Finally I managed to run the game with OllyDBG without troubles. The trick is to set the max resolution to 640x480, so that DxWnd understands that the initial 640x480 splash screen is in fullscreen mode and take the appropriate countermeasures.
Now I've got to this partial result: the problem is that the routine @406940 returns a boolean flag, either 0 => error condition or 1 => ok.
The result code seems tied to the content of the memory global @53EE48 that gets set to 1 at 478676 and set to 0 at 47881D. Why that happens is yet to find.
Approaching the problem from another side, I found that you can run the game in nonwindowed and nonemulated mode ("Main / Run in window" unchecked and "DirectX / Emulation" set to None, Primary buffer or Locked surface). The curious thing is that the game stops working if you either set windowed mode or set emulated surface, it is not necessary to set both!
The suspect is that the error is somehow linked to the EnumDisplayModes or GetDisplayMode calls, maybe I return some capability that doesn't fit, but I checked the logs and found no clues.
Last edit: gho 2016-07-04
Hell!
Here is the damned piece of assembly that, within the Vertigo_Direct3D module and after a DirectDrawEnumerateExA call, loops trying to find a suitable video mode and is so picky to exclude all possibilities and return a fake directdraw error code 80004005 (see @3D816A7: MOV EAX, 80004005).
Since this loop doesn't go into error for unwindowed unemulated modes, I should only (sic!) understand what it doesn't like from my video modes emulation.
I feel for you, those glory assembly code is very hard to be understood. I try to patch the message dialog on Dethkarz.exe but without success.
Last edit: Anonymous 2016-07-04
Hard? It's clear like water: it's a procedure with 3 nested loops, likely to check for screen size, color depth and, in the inner loop, something more that doesn't match expectations, so that the loop exits after having cycled all possible devices in 03D816B0 RETN after setting the 80004005 return code in 03D816A7. If the JE SHORT 03D816B1 at 03D8168A did jump, then the routine would terminate at 03D816CD RETN with a 0 (DD_OK) return code set in 03D816C7 XOR EAX,EAX.
So, the question is: what's written in DS:[EAX+138] ?
you mean you gonna to figure out what went wrong then? So just recall my previous post as 'easy' instead.
Last edit: Anonymous 2016-07-04
Sorry, I realized that changing platform the addressing changes. I doubt you could retrieve these instructions at the same addresses on your XP.
Or to be more clear, even if they are the same, my stupidity will prevent me from getting any clearance.
Last edit: Anonymous 2016-07-05
Well, "easy" for me meant that it took no more that it took a whole day of debugging to understand what's going on. I'm so damnedly close..... the trick is that the renderer loops through the devica capabilities and needs a flag to be TRUE. This flag, when running in windowed or emulated mode is 0, in fullscreen mode is 1. The flag is at offset 0x138 from the beginning of a data structure, so I have to understand to what capability field it corresponds and the trick should become simple, force it to 1 and it should work.
No more words, let me continue .....
Bad news: I thought it was a field in the device capabilities descriptor, but it is not. It must be some other info that the application retrieves and places there for future use, but now I have to guess where it comes form. Apparently, it doesn't get from any hooked call, because the log trace doesn't show differences that may imply this change. More work, sic! .....
At last, I discovered something very interesting.
As I said, the problem is that the D3D Vertigo driver does not find any suitable video mode to continue and stops. In doing that, it checks this boolean flag located in a data structure replicated for each device (so that it doesn't have a fixed address) and visible by searching for instructions with DS:[reg+13C] reference, where reg is EAX, ECX or EDX.
Now this flag is set here
0398154F MOV DWORD PTR DS[EDX+13C],1
and this happens after a series of conditional jumps that skip this part if the color depth is 8 bit, this one in particular:
039814F1 CMP ECX, 8
039814F4 JNE SHORT 0398150D
....
0398150A RETN 8
Wondering why this piece of code behaves differently with DxWnd windowized or emulated mode, here is the reason:
The game starts, sets a 32BPP splash fullscreen window (the one with "please wait"), then starts a 8BPP paletized fullscreen intro movie window. When this movie is terminated, the operating system automatically brings back the color depth to 32BPP and, when the color depth is checked, the flag is set.
When the game is started in windowed mode, it seems that there is no automatic recovery of the color depth, the screen remains at 8BPP color and the setting fails.
If the game is started in fullscreen but emulated mode, the color depth never changes, but DxWnd simulates the switch to 8BPP and nothing is telling that at the window closure the color depth should be logically recovered.
In conclusion, I believe that the problem is to find a general way to fake an automatic return to the original color depth in DxWnd. I could verify this by using some trick, just in case I'm wrong....
Last edit: gho 2016-07-06
That is interesting. So if I understood this correctly the reason why the demo version works fine would be the lack of an intro movie.
If this is the case would deleting the intro movie file help? Or is it it streamed from the CD?
Also is the movie using smacker or bink or some other format? It might be possible to try a newer dll version at least if it is in .smk or .bik format.
Last edit: Riitaoja 2016-07-06
Movies on the CD, I extracted it but the 8bit mode is set in any case. But we're closer ....
Last edit: gho 2016-07-06
Wow! the theory was correct.
I couldn't find where this damn'd "Melbourne House" splash movie came from, after having unmounted the CD and rename all possible file. Could it be embedded within the code? Now I am surprised by nothing at all. So, to cut this short, I hacked the exe getting rid of the splash movie call (quite easy to find by searching for the right CreateWindowEx call) and produced this Dethkarz.nomovie.exe file.
Guess what? The game works perfectly with default settings!
Now the job is not over, I still have to manage the resolution change for closed fullscreen window, but at least I know I am on the right path.
If you don't care for perfection, here is the patched game and some screenshots.
Saving the desktop color mode when it changes and recovering it after that the new primary window is destroyed seems a good solution on Win10, but it doesn't work on Win7! These platform details are kiling me. Too bad, I thought I had found the good solution .....
Ah! here it is: it needed a "Force clipper" flag and a few fixes to make it working ok also on Win7.
Here is the replacement dll and the exported file.
@cloudstr: where have you gone? You started this thread, you deserve the final word.