It is incredible to find, after several years of development and improvements, a single game that shows so many different and unresolved problems.
This one is Aaron vs. Ruth, available with a little search and patience using your favourite old games finder (hem...).
Here is a list of problems found so far:
unstretched intro movies
main menu dialog moved to upper-left corner
killing the window (using Alt-F4 or the X button) sets screen resolution to 640x480
The first problem was easy to fix, it only needed scaling the coordinates in the DrawDibDraw wrapper, I have a patched dxwnd.dll that fixes the movies.
But the other two problems are tougher, and what's worse, D3DWindower seems able to handle both of them!
On the bright side, though, D3DWindower seems to have palette problems.
to be continued ...
Last edit: gho 2018-08-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Using the attached dxwnd & export, the game is almost playable.
The moved dialog box can be brought back to upper left game window corner by turning the "Remap client rect" flag, though I wonder why!
Troubles then come easily when you try to stretch the window larger than its native size, or simply adding a window border. But I saw that the same sort of problems are in common with D3DWindower, so this tips the scales somehow.
All this has nothing to do with a strange cache overflow message that sometimes shows just before a matchplay, but usually trying a few times you can skip it. It doesn't seem related to hooking actions, but you never know ...
I move here some info coming from other threads about this game problems:
Cluodstr posted these:
Window size & position -> Free, the screen still doesn't move when trying to drag and move the window to another location (1.png)
Strange artifacts when clicking the minimize button or the task bar icon (2.png)
The Quit dialog box doesn't center to a main window which is a default behavior. This issue also happens with any games that showing a dialog box (3.png)
About the bug1 screenshot, some pictures are clipped. To have some more insight I compared the unscaled and correct screenshot of the 640x480 game with the scaled one (see picture). This shows that the clipping regions are ok, what's wrong is the picture (a DIB!) placement.
I say DIB because a test with a void DIB functions wrapper showed that all screen regions with graphic artifacts were black in this case. Probably DxWnd is not managing the DIB color depth correctly.
Another bug with no screenshots: the game menus have yellow words and one of them become white when selected, then when you click or press the enter key, no matter where the mouse cursor is, the while selection is activated. The problem is that with no DxWnd hooking the white text selection promptly follows the mouse, while using DxWnd there's some sort of delay.
Even more curiously, I got the impression (but maybe it doesn't always work like this) that moving the mouse from up to down works far better than from down to up: sometimes to pick the first menu item I find it easier to move the mouse in circle, outside the menu and upward and then move to the first item from the top!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Last but not least, another bug that may be caused by DxWnd indirectly.
The game often terminates with this error panel claiming there's a problem with the used color cache. I think that could depend on the pixel colors mapped from 8bit to 32bit, with the possible increase in number. And curiously, it doesn' always happen ....
Sorry for being a little absent recently, but apart from some personal tasks another cause was the bumping of my head on this Aaron problems.
At least, I got one result: the badly rendered squares are DIB images in DIB_PAL_COLORS format that is supported only in native 8bpp desktop. Bringing them to 32bpp desktops in color emulation needs some extra work, but at least I learnt how to interpret and dump the graphic format (a really weird one!) so that a possible strategy could be to convert DIB_PAL_COLORS format to a more convenient DIB_RBG_COLORS format.
These are some dumps of the missing pieces (they fit in the bug2.png and bug3.png screenshots above):
Slowly making progresses on DIB manipulation.
The problem here, on this game, is that DIB are associated to a palette, but unlike the ddraw typical scenario, there can be (and here there is!) a different palette for each device context and these palettes are different from the ddraw palette. DxWnd can intercept the palette creation but in an emulation mode it can't associate them to 32bit DC, so they get lost.
The result is an image that, after a few steps, gets a random color table. Anyway, I fixed the dump routine and here is some nice picture.
A side effect of my testing on this game DIBs: I got increasingly annoyed by the MaxUsedColorCache error pop-up that almost sistematically was interrupting my debugging sessions, so I tried to understand what happened. In the end, I came up with a small fix that seems to eliminate the problem apparently with no side effects.
So, if anyone is interested, I share here my fixed exe to replace the previous one.
The bug shown in the bug2.png screenshot above comes after a GetDIBits call.
The call is supposed to return a byte stream. Because of the emulation, the stream returned belongs to a 32bit bitmap, but probably the game expects a 8 bit stream and draws the pixels 4 times (that is, 32 : 8 = 4) wider than the supposed width and with bad colors.
Should I un-emulate a 8 to 32 bit conversion? Not an easy task ...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is what you get if you try a conversion back from 32bpp to 8bpp. This tentative code has no reverse palette matching yet, but I dare say that the result is promising!
Some improvement, but where the colors are gone?
This is not the only problem: it's not clear how the game renders this buffer obtained by GetDIBits and the image (ignoring the color problem) is ok only at 1:1 scaling ratio. If you set some width coordinate, the DIB images get scrambled.
It is incredible to find, after several years of development and improvements, a single game that shows so many different and unresolved problems.
This one is Aaron vs. Ruth, available with a little search and patience using your favourite old games finder (hem...).
Here is a list of problems found so far:
The first problem was easy to fix, it only needed scaling the coordinates in the DrawDibDraw wrapper, I have a patched dxwnd.dll that fixes the movies.
But the other two problems are tougher, and what's worse, D3DWindower seems able to handle both of them!
On the bright side, though, D3DWindower seems to have palette problems.
to be continued ...
Last edit: gho 2018-08-05
Using the attached dxwnd & export, the game is almost playable.
The moved dialog box can be brought back to upper left game window corner by turning the "Remap client rect" flag, though I wonder why!
Troubles then come easily when you try to stretch the window larger than its native size, or simply adding a window border. But I saw that the same sort of problems are in common with D3DWindower, so this tips the scales somehow.
All this has nothing to do with a strange cache overflow message that sometimes shows just before a matchplay, but usually trying a few times you can skip it. It doesn't seem related to hooking actions, but you never know ...
I move here some info coming from other threads about this game problems:
Cluodstr posted these:
Some more from myself.
Here are three other types of problem
About the bug1 screenshot, some pictures are clipped. To have some more insight I compared the unscaled and correct screenshot of the 640x480 game with the scaled one (see picture). This shows that the clipping regions are ok, what's wrong is the picture (a DIB!) placement.
I say DIB because a test with a void DIB functions wrapper showed that all screen regions with graphic artifacts were black in this case. Probably DxWnd is not managing the DIB color depth correctly.
Last edit: gho 2019-10-29
Another bug with no screenshots: the game menus have yellow words and one of them become white when selected, then when you click or press the enter key, no matter where the mouse cursor is, the while selection is activated. The problem is that with no DxWnd hooking the white text selection promptly follows the mouse, while using DxWnd there's some sort of delay.
Even more curiously, I got the impression (but maybe it doesn't always work like this) that moving the mouse from up to down works far better than from down to up: sometimes to pick the first menu item I find it easier to move the mouse in circle, outside the menu and upward and then move to the first item from the top!
Last but not least, another bug that may be caused by DxWnd indirectly.
The game often terminates with this error panel claiming there's a problem with the used color cache. I think that could depend on the pixel colors mapped from 8bit to 32bit, with the possible increase in number. And curiously, it doesn' always happen ....
Last edit: gho 2019-10-30
Last edit: vpn20 2020-10-15
Sorry for being a little absent recently, but apart from some personal tasks another cause was the bumping of my head on this Aaron problems.
At least, I got one result: the badly rendered squares are DIB images in DIB_PAL_COLORS format that is supported only in native 8bpp desktop. Bringing them to 32bpp desktops in color emulation needs some extra work, but at least I learnt how to interpret and dump the graphic format (a really weird one!) so that a possible strategy could be to convert DIB_PAL_COLORS format to a more convenient DIB_RBG_COLORS format.
These are some dumps of the missing pieces (they fit in the bug2.png and bug3.png screenshots above):
Last edit: gho 2019-11-04
Slowly making progresses on DIB manipulation.
The problem here, on this game, is that DIB are associated to a palette, but unlike the ddraw typical scenario, there can be (and here there is!) a different palette for each device context and these palettes are different from the ddraw palette. DxWnd can intercept the palette creation but in an emulation mode it can't associate them to 32bit DC, so they get lost.
The result is an image that, after a few steps, gets a random color table. Anyway, I fixed the dump routine and here is some nice picture.
A side effect of my testing on this game DIBs: I got increasingly annoyed by the MaxUsedColorCache error pop-up that almost sistematically was interrupting my debugging sessions, so I tried to understand what happened. In the end, I came up with a small fix that seems to eliminate the problem apparently with no side effects.
So, if anyone is interested, I share here my fixed exe to replace the previous one.
It seems that I finally got a way to dump DIB graphic. Now I just have to understand what's going wrong when I try to blit them to screen ....
The bug shown in the bug2.png screenshot above comes after a GetDIBits call.
The call is supposed to return a byte stream. Because of the emulation, the stream returned belongs to a 32bit bitmap, but probably the game expects a 8 bit stream and draws the pixels 4 times (that is, 32 : 8 = 4) wider than the supposed width and with bad colors.
Should I un-emulate a 8 to 32 bit conversion? Not an easy task ...
This is what you get if you try a conversion back from 32bpp to 8bpp. This tentative code has no reverse palette matching yet, but I dare say that the result is promising!
Next step: reverse palette matching. For a first attempt, not bad!
Some improvement, but where the colors are gone?
This is not the only problem: it's not clear how the game renders this buffer obtained by GetDIBits and the image (ignoring the color problem) is ok only at 1:1 scaling ratio. If you set some width coordinate, the DIB images get scrambled.