The problem with DW is that the game mixes 3D rendering with 2D rendering made directly on top of the backbuffer surface, retrieved through IDirect3DDevice8::GetBackBuffer.
Since the game is developed ecxclusively for 16bpp surfaces, DxWnd can cheat it using 32bit primary and backbuffers, but when the program tries to work directly on these surfaces it doesn't realize the color depth is not what expected.
So the trick is (more or less) create a fake backbuffer and keep moving pixels from and to the real and fake Backbuffer converting the color depth properly.
First attempts can either produce good 3D scened or good 2D scenes, but the trouble is that what the game should really offer is a mixture of the two types!
Boys, I hake to kiss this genious that handed such a beautiful code as the one in d3d8.dll wrapper!
This is a very preliminary release, just quick and dirty patched here and there, but a first integration of that code in DxWnd has produced a beautiful, working and fast windowized "dangerous waters" with 2D and 3D parts perfectly merged.
A stable release is now a priority!
This version should be pretty close to a release. There are still a few problems with the game: the choice of "options" in the main menu and a game minimize/restore will bring the program to death, but apart from this the game works a beauty! Exported file included in the archive, the injection hook mode helps creating the game window in the correct position and size, but the game works also with default hooking. The d3d8 backbuffer virtualization, thank to Mr. Jiri Dvorak (I suppose this is the name from the www.jiti-dvorak.cz website, there is no other reference in the source code) is turned on by setting the D3D / "Emulate 16bpp D3D8 backbuffer" flag. One important thing: this MS game has interfering shims, to make it running you have to neutralize them: the easiest way is to copy the game exe to another name (I chosed "dangerouswaters.noshim.exe").
Last edit: gho 2017-01-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Beta version removed: the uploaded v2.04.03 release has some more code cleanup and a crashing bug fixed. Head to the download area and enjoy "Dangerous Waters" on Win8-10. Setting it to fake-fullscreen mode, keep aspect ratio and hide desktop is a joy for the eyes!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
-
2017-01-08
Last edit: 2017-01-19
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The idea is good, but technical implementation is not so simple: the problem is that the hooking doesn't take place only when you 'run' the game, but also later on, when the game creates a window. So, starting a game with no hooking brings the problem to decide when starting the hoo again. The way it is currently coded leaves the choice to the humans (hook->stop and hook->start), but running a whole game sesion with no hooking may require some thinking ....
Starting the hook when the game terminate would seem the logical choice, but I'm not so sure about the reliability in DxWnd child death detection.
Let me think about it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
-
2017-01-08
Last edit: 2017-01-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
-
2017-01-10
Last edit: 2017-01-19
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Right click on menu entry and select "Run unhooked" (the last in the list).
I may also have fixed the Superbike problems, if I guessed it right (I can't test them all right now, I hope it will work).
According to my "predictions", the weak point could possibly be the case where the game opens a new window after the 5 seconds of internal fixed timeout: in that case it may (or may not!) happens that the game gets hooked again, and this time the hook inibition would be expired. Unfortunately, opening a new window is not the same thing as minimizing and restoring, so it is not so easy to find a possibly critical game.
Well, in any case, sooner or later we will know .... :)
P.s. the nice thing about good ideas is that they are simple: I didn't touch more than 10 lines of code!
You should move it to second in list, just below the "Run".
Uhm, too close to normal "run", so I fear it could be confusing, and also selected for error. I was rather thinking to go the opposite way, enabling the "run unhooked" command only when the GUI debug flag is set. After all, this command is useful for testers like you and me, but normal users may hardly understand its usage. I'll think about that a little more ...
If I enable "Auto Hide GUI", at a first launch I got kicked to desktop immediately
The problem is that if you run a game "unhooked", you lose the possibility to monitor the process status and so the GUI will never show again. I made a fix that leaves the GUI visible it the task is run in unhooked mode. But I can't understand why the GUI would get kicked to desktop: does the GUI process DxWnd.exe really die? It seems another XP specific problem.
Superbike problems did not fixed
I know about the Superbike problems related to the game, why do you refer to these here talking about the GUI?
In attach the GUI with latest fixes, including an optimization to ask to save the game configuration only when really necessary.
Dangerous Waters: the coding was not so bad, to avoid crashing the game on minimize/restore it seems enough to set the "Do not notify on task switch" flag.
Very recommended, since it wouldn't be pleasant to have your mission interrupted!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
About the "Run unhooked" menu command:
I'm still of the idea that a typical DxWnd user would be confused by such a command (honestly, I must admit that there are plenty of other more confusing things in the interface, but this is not a good reason to increase the entropy!). What I fear most is a bunch of posts claiming that DxWnd doesn't windowize the game just because they clicked on the wrong button ...
But if I don't want to increase the fear in a newby user, I don't either want to discourage the intent of some advanced users like many of the forum writers that could make a good use of this feature. So the idea was to start hiding the "advanced" features behind a "debug" mode. This is not at all unfriendly, because one only needs to check the debug flag in the global settings and from there on all advanced features will be available, at least unless the dxwnd.ini file gets deleted! And I'm not talking about a new flag, but the existing one that extends its scope to another few features.
The only thing that stopped me doing it this way is the fact that I need a little time to learn how to dynamically add a menu item to a MFC window menu, but I hope nobody is in a hurry, the hurried she-cat has made blind kittens (old italian proverb!)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
-
2017-01-12
Last edit: 2017-01-19
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You should love this. Maybe later on I will move the decision from the "debug" flag to an "Expert mode" menu item, so that it will be even easier to switch. One step at a time ....
Summarizing: you can switch the two modes going to Options->Global settings (at least for the moment...) and checking the "Enable Debug mode" flag. You'll notice that I took advantage of this feature to get rid of many other menu commands that are not absolutely necessary for a not expert user. And this is just the beginning: the whole interface could be revamped.
I believe that TigerAwkT3 would kill you ... ;)
where FilePath is derived from the game full pathname searching backwards for the last backslash. I'd bet it is one of those Win oddities that require the last path character to be a backslash or not (do you remember the endless "open file" story?).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Try this version. If you have the game in "c:\games\mygame.exe" this version opens "c:\games\" instead of "c:\games" . It works the same on Win7, so if it works also in WinXP it won't be necessary to add a platform test condition.
For a "Dangerous Waters" game. First steps, too soon to say done, but .... promising.
Last edit: gho 2017-01-06
The problem with DW is that the game mixes 3D rendering with 2D rendering made directly on top of the backbuffer surface, retrieved through IDirect3DDevice8::GetBackBuffer.
Since the game is developed ecxclusively for 16bpp surfaces, DxWnd can cheat it using 32bit primary and backbuffers, but when the program tries to work directly on these surfaces it doesn't realize the color depth is not what expected.
So the trick is (more or less) create a fake backbuffer and keep moving pixels from and to the real and fake Backbuffer converting the color depth properly.
First attempts can either produce good 3D scened or good 2D scenes, but the trouble is that what the game should really offer is a mixture of the two types!
Boys, I hake to kiss this genious that handed such a beautiful code as the one in d3d8.dll wrapper!
This is a very preliminary release, just quick and dirty patched here and there, but a first integration of that code in DxWnd has produced a beautiful, working and fast windowized "dangerous waters" with 2D and 3D parts perfectly merged.
A stable release is now a priority!
Last edit: gho 2017-01-07
This version should be pretty close to a release. There are still a few problems with the game: the choice of "options" in the main menu and a game minimize/restore will bring the program to death, but apart from this the game works a beauty! Exported file included in the archive, the injection hook mode helps creating the game window in the correct position and size, but the game works also with default hooking. The d3d8 backbuffer virtualization, thank to Mr. Jiri Dvorak (I suppose this is the name from the www.jiti-dvorak.cz website, there is no other reference in the source code) is turned on by setting the D3D / "Emulate 16bpp D3D8 backbuffer" flag. One important thing: this MS game has interfering shims, to make it running you have to neutralize them: the easiest way is to copy the game exe to another name (I chosed "dangerouswaters.noshim.exe").
Last edit: gho 2017-01-07
Beta version removed: the uploaded v2.04.03 release has some more code cleanup and a crashing bug fixed. Head to the download area and enjoy "Dangerous Waters" on Win8-10. Setting it to fake-fullscreen mode, keep aspect ratio and hide desktop is a joy for the eyes!
Last edit: 2017-01-19
The idea is good, but technical implementation is not so simple: the problem is that the hooking doesn't take place only when you 'run' the game, but also later on, when the game creates a window. So, starting a game with no hooking brings the problem to decide when starting the hoo again. The way it is currently coded leaves the choice to the humans (hook->stop and hook->start), but running a whole game sesion with no hooking may require some thinking ....
Starting the hook when the game terminate would seem the logical choice, but I'm not so sure about the reliability in DxWnd child death detection.
Let me think about it.
Last edit: 2017-01-21
Last edit: 2017-01-19
Maybe I got an idea. If I can succeed, it's the sort of you may like it ....
Right click on menu entry and select "Run unhooked" (the last in the list).
I may also have fixed the Superbike problems, if I guessed it right (I can't test them all right now, I hope it will work).
According to my "predictions", the weak point could possibly be the case where the game opens a new window after the 5 seconds of internal fixed timeout: in that case it may (or may not!) happens that the game gets hooked again, and this time the hook inibition would be expired. Unfortunately, opening a new window is not the same thing as minimizing and restoring, so it is not so easy to find a possibly critical game.
Well, in any case, sooner or later we will know .... :)
P.s. the nice thing about good ideas is that they are simple: I didn't touch more than 10 lines of code!
Last edit: gho 2017-01-10
Last edit: 2017-01-19
In attach the GUI with latest fixes, including an optimization to ask to save the game configuration only when really necessary.
Last edit: 2017-01-19
Triggered (sic!).
BTW let's get in sync with new release v2.04.04 (sometimes I need to know what we're exactly talking about!).
;)
Last edit: 2017-01-19
Last edit: 2017-01-19
below ....
Dangerous Waters: the coding was not so bad, to avoid crashing the game on minimize/restore it seems enough to set the "Do not notify on task switch" flag.
Very recommended, since it wouldn't be pleasant to have your mission interrupted!
About the "Run unhooked" menu command:
I'm still of the idea that a typical DxWnd user would be confused by such a command (honestly, I must admit that there are plenty of other more confusing things in the interface, but this is not a good reason to increase the entropy!). What I fear most is a bunch of posts claiming that DxWnd doesn't windowize the game just because they clicked on the wrong button ...
But if I don't want to increase the fear in a newby user, I don't either want to discourage the intent of some advanced users like many of the forum writers that could make a good use of this feature. So the idea was to start hiding the "advanced" features behind a "debug" mode. This is not at all unfriendly, because one only needs to check the debug flag in the global settings and from there on all advanced features will be available, at least unless the dxwnd.ini file gets deleted! And I'm not talking about a new flag, but the existing one that extends its scope to another few features.
The only thing that stopped me doing it this way is the fact that I need a little time to learn how to dynamically add a menu item to a MFC window menu, but I hope nobody is in a hurry, the hurried she-cat has made blind kittens (old italian proverb!)
Last edit: 2017-01-19
You should love this. Maybe later on I will move the decision from the "debug" flag to an "Expert mode" menu item, so that it will be even easier to switch. One step at a time ....
Summarizing: you can switch the two modes going to Options->Global settings (at least for the moment...) and checking the "Enable Debug mode" flag. You'll notice that I took advantage of this feature to get rid of many other menu commands that are not absolutely necessary for a not expert user. And this is just the beginning: the whole interface could be revamped.
I believe that TigerAwkT3 would kill you ... ;)
Last edit: 2017-01-19
Of course it works, it is the most useful command for a DxWnd hunter!
This is the impressive complexity of the source code of this function:
where FilePath is derived from the game full pathname searching backwards for the last backslash. I'd bet it is one of those Win oddities that require the last path character to be a backslash or not (do you remember the endless "open file" story?).
Try this version. If you have the game in "c:\games\mygame.exe" this version opens "c:\games\" instead of "c:\games" . It works the same on Win7, so if it works also in WinXP it won't be necessary to add a platform test condition.