Wow, interesting case!
As happens very often, the error message is misleading, the log shows that there is no memory problem but rather a failed creation of a hardware accelerated D3D session version 1 (IID_IDirect3DHALDevice).
QueryInterface(1): lpdds=3f039b0(BACK) REFIID=84e63de0(IID_IDirect3DHALDevice)
QueryInterface: Got interface for IID_IDirect3DDevice version 1
...
QueryInterface: ERROR lpdds=3f039b0 REFIID=84e63de0 obp=0 ret=887602ea(unknown) at 193
It seems that the problem could be overtaken by setting the "DirectX(2) / Forces HEL" or also "DirectX(2) / No HAL device" flags, but I've made the test with a bad game RIP that crashes right after, in any case with another error (a missing file).
Tonight is too late to make a decent test applying your instructions, I'll do it tomorrow. In the meanwhile, you could try as well and maybe you'll have a better luck.
update
Ah, I think I saw the problem, the ZBUFFER is not registered with proper capabilities. Be patient, I have to find the proper way to fix it without breaking all the other games behaviour....
Last edit: gho 2017-04-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here is the fix for Wipeout XL. I tested it with the nasty RIP, but I'm pretty confident it may work also with the full game. As I said, the problem was not assigning the proper simulated capabilities to the ZBUFFER surface, that DxWnd always build on fast system memory but the D3D pretends to match the attachee surface memory type.
Instructions: replace this dll on top of last dxwnd release v2.04.23 (uploaded minutes ago ...)
the game runs with default settings, but only too fast.
Setting "DirectX(2) / VSync" to "ON" makes it as fast as it was meant to be
Setting theFPS limitation (frame per second / limit / delay) can make it slower. Time stretching doesn't seem to produce any effect, but I have to investigate why ....
Please, report what's going on.
P.s. the game doesn't seem to react very well to focus lost or window closing. Later I'll try to mind these problems as well.
Vsync will work if I disable surface optimization in the Radeon app:
There seems to be a general Z-order issue, as well as polygons being culled:
BTW,
The demo does provide software rendering such as MMX, RAMP (https://archive.org/details/WIPEOUT_201406), do you think is this something you can force apps to show or the game code should be modified ?
Thank you.
Last edit: aybe 2017-04-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Z-Order issues tend to be quite hardware-dependent, if I can't replicate them it is difficult to provide help. In any case, so far DxWnd can only let you pick one of the Direct3D tweaks in Direct3D tab. You could try one of these:
Clean ZBUFFER @0.0 fix
Clean ZBUFFER @0.0 fix
Clean ZBUFFER hard
alone or in combination with "Dynamic ZBUFFER fix".
Do you have similar problems in fullscreen mode too? Or disabling surface emulation?
Forcing a different renderer is possible and I made some experiments, but I judged it as useless since the game almost always crashed, requiring other arrangements more that the simple renderer switch. But that was with a very demanding game, it is possible that WipeoutXL could better cope with such a change: I'll try and let you know. In particular, it is highly probable that a software renderer will reduce the ZBUFFER problems.
*** update ***
I installed the game and DxWnd release on my second pc equipped with Win10 64bit and an AMD Radeon M5 200 series video card, and the texture clipping effect is perfectly visible. Also, none of the tricks I suggested or others that I tried was working. I'm going to try a renderer switch, but this effects is visible in other games too, does enyone have some patch to suggest?
Last edit: gho 2017-04-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually it's just like Star Wars Shadows of the Empire, where it works too fast but properly in an Intel IGPU but fails on AMD GPU. Not sure if that'll help you out but GOG version they released simply works now : https://www.gog.com/game/star_wars_shadows_of_the_empire seems like in addition to MS ACT patch they've rolled out some custom ddraw DLL.
For Wipeout I've tried to force HEL for the full game but then the game will say you need a 3D accel, I guess code has been stripped out from the game.
The only official patch I know is WipEout XL Network Patch v0.9 Beta @ https://archive.org/details/WOXLN1 but it does not change anything for DxWnd.
I did try Z-buffer settings but none worked, and other surface emulations all hang the game with a black screen which quits a little after :(
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
a possiblestrategy, though not at all easy, could be to copy from GOG: roughly speaking, this is what I should (would) do:
1) run the normal game with DxWnd and collect ddraw traces
2) run the GOG game version and collect the actual ddraw traces (that is, not the calls to the ddraw wrapper but the calls to the actual ddraw.sll in system folder)
3) compare the logs, find the differences and try to emulate.
Easy to tell, a little less to do. Wish me good luck.
This, of course, unless someone who knows wouldn't be so kind to talk ....
Last edit: gho 2017-04-06
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's a shame that many old games run very well on Wine, you've never considered importing their entire stack emulated in OpenGL ? (not an easy task I agree)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, I considered it and even tried it, grabbing one build of Wine libraries compiled for Windows.
The result was not so exciting: OpenGL is not always available with hw drivers for all cards, and if you use sw emulation the performance results are awful. In addition, the game compatibility was not good at all, the games that mostly interested me simply crashed.
Last but not least, some internet article (it shouldn't be difficult to find it) mentioned a dependency problem: recent Win10 OpenGL are based on ddraw, so if you stack all sw layers you get ddraw emulated by OpenGL emulated by ddraw .... and this is a loopback, can't work unless you make some nasty trick like renaming ddraw.dll or such. The scenario seems much more troublesome and complex than the current DxWnd one, where most games simply work and a few give problems (for the moment ...).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
About the demo, yes it offers 3 different renderers (Ramp, RGB and D3D) but the results are not so exciting: apart from the resolution limited to 640x480, Ramp has artifacts, RGB shows a black scene and D3D doesn't work. Anyway, it could prove useful to learn something about how to switch renderers.
Here are some preliminary tests, forcing the renderer value. It seems that there are two classes of renderer, the HW that requires video memory surfaces and the SW that goes along with system memory surfaces. You can switch renderer type within the SW class (MMX, Ramp, RGB) though with strange results, but you can't switch a SW class to the HAL renderer. The screenshot filenames tell the supposed renderer 2 (to) the forced renderer. Could this become useful? Who knows ...
I tried to compare "Wipeout XL" and "SW Shadov of the Empire" (SWSotE in short) with their respective GOG versions. The situation is a little different from expected:
1) Wipeout XL GOG seems still in people's wish list, it was probably never released
2) SWSotE GOG works fine, though GOG locked the renderer to HAL only
3) DxWnd hack for SWSotE supports also RGB renderer, but at an incredibly slow frame rate
4) DxWnd SWSotE runs fine (and in window!) but polygons are misplaced (see screenshot: the mech legs seem twisted!)
5) GOG did not use any wrapper ddraw.dll for SWSotE
anyone could at least help giving a name to this effect? Is it bad culling? uncleared ZBUFFER? Any clue to find a recipy?
From what I can tell with my experience fiddling with shaders and so on, the polygons the camera is facing are being culled out while they shouldn't be, i.e. Superman vision to see through things.
Now what could be the cause of this ?
When a camera 'near clipping plane' is too far this kind of weird effect happens, what should be visible is culled, resulting in a see-through effect.
Why is that happening ?
I don't know, is some matrix or whatever that affects the calculation is mis-interpreted or lost, resulting in a mostly perfect result. Some rounding issues or casting to an inappropriate number type ?
It is quite hard to tell when looking at the legs, but looking at the head definitely remembers this kind of issue.
Also, while the legs seem closer to user, there might be an angle involved in the calculation.
Hope that makes sense to you :)
Last edit: aybe 2017-04-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Does it makes sense to me? Well, just a little, but it is a track and I can follow this path. DxWnd has to deal with a lot of programming details, and it hasn't everything under control: if the cause of the problem is the "culling", I can start digging in the code, adding the missing hooks for the D3D methods that are involved in this mechanism, analyze the logs, decide a strategy, implement and produce a fix .... but it is a hell of a job, and it would be quite reassuring if I could know that such a hack exists that produces the wanted effect, even without source code: at least it would ensure that the goal is reacheable and the effort is in the right direction.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can't you spot out the difference between SWOTE for GOG and under DxWnd ? (not easy I agree)
I don't really know the DirectX beast, is it something that devs are put under control where you have a limited scope ? Or is it like for example Amiga where there would be no kind of 'well-known pattern' ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i've been trying the latest version of dxwnd as of today but it seems like situation hasn't improved much, 3d models cannot be seen and therefore the track in game.
Thank you for the DDrawCompat link, I'll surely test it. But a solution that fixes a fullscreen game could be different from one that works in window mode, the windowizing process is more complex. Let's see ....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A very quick test: the ddraw.dll file from DDRawCompat bundle is compatible with DxWnd: if you copy the DDRawCompat ddraw.dll file to the game folder and configure DxWnd to run the game, you can get the game running in window and without artifcts.
That's good news, it provides a quick solution to the problem and proves that it is also possible to fix the game in window mode somehow. Very interesting!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Even though you made a great job documenting the software, it's still incredibly difficult to use, mainly because noobs lack the necessary knowledge to understand how exactly each option would affect an executable.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The game doesn't have a very good timing control: it runs as fast as possible.
In addition, DDrawCompact seems to increase the efficiency and the game runs even faster.
The situation is partially recovered by DxWnd with the suggested exported configuration that includes the "DirectX(2) / vSync ON" flag that ensure you can't have more than 60 FPS. In addition, if you want the game even slower, you can set s delay in the "Timing / Limit" field, something between 20 to 100 mSec should do fine. Unfortunately, if you use a high delay value, the game will start to be choppy.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In addition to the audio emulation issues, which was resolved in another thread, I have an issue with the sky texture.
Both with DxWnd and without DxWnd this texture doesn't render at all and my sky is black on my Nvidia in all maps. If I do a textures dump, the sky is there. The picture texture.256.256.R5G6B5.0CB32CA4.bmp shows a texture from the PHENITIA PARK map. It should look like this: https://youtu.be/bcu_KfPxAFM?t=354
I haven't come up with any solution.
Hi !
The following wrappers are able to make it run through Windows 10 though speed being too fast:
dgvoodoo
ddrawcompat
I've been trying to run the game with DxWnd in a hope to slow it down but unfortunately I always get the following error:
Could you give it a try ?
To install the game in Win10:
Thanks !
Wow, interesting case!
As happens very often, the error message is misleading, the log shows that there is no memory problem but rather a failed creation of a hardware accelerated D3D session version 1 (IID_IDirect3DHALDevice).
It seems that the problem could be overtaken by setting the "DirectX(2) / Forces HEL" or also "DirectX(2) / No HAL device" flags, but I've made the test with a bad game RIP that crashes right after, in any case with another error (a missing file).
Tonight is too late to make a decent test applying your instructions, I'll do it tomorrow. In the meanwhile, you could try as well and maybe you'll have a better luck.
update
Ah, I think I saw the problem, the ZBUFFER is not registered with proper capabilities. Be patient, I have to find the proper way to fix it without breaking all the other games behaviour....
Last edit: gho 2017-04-05
Here is the fix for Wipeout XL. I tested it with the nasty RIP, but I'm pretty confident it may work also with the full game. As I said, the problem was not assigning the proper simulated capabilities to the ZBUFFER surface, that DxWnd always build on fast system memory but the D3D pretends to match the attachee surface memory type.
Instructions: replace this dll on top of last dxwnd release v2.04.23 (uploaded minutes ago ...)
the game runs with default settings, but only too fast.
Setting "DirectX(2) / VSync" to "ON" makes it as fast as it was meant to be
Setting theFPS limitation (frame per second / limit / delay) can make it slower. Time stretching doesn't seem to produce any effect, but I have to investigate why ....
Please, report what's going on.
P.s. the game doesn't seem to react very well to focus lost or window closing. Later I'll try to mind these problems as well.
Last edit: gho 2017-04-05
Ok so on my HD7850, the full version of the game, no Win95 compatibility set in Windows, no other settings in DxWnd
Missing background:
Depth order is wrong:
sky is in front
press F5 to disable it, things look better
And here Alt-Tab does not crash the game.
Thanks !
Also,
Vsync will work if I disable surface optimization in the Radeon app:
There seems to be a general Z-order issue, as well as polygons being culled:
BTW,
The demo does provide software rendering such as MMX, RAMP (https://archive.org/details/WIPEOUT_201406), do you think is this something you can force apps to show or the game code should be modified ?
Thank you.
Last edit: aybe 2017-04-05
Z-Order issues tend to be quite hardware-dependent, if I can't replicate them it is difficult to provide help. In any case, so far DxWnd can only let you pick one of the Direct3D tweaks in Direct3D tab. You could try one of these:
Clean ZBUFFER @0.0 fix
Clean ZBUFFER @0.0 fix
Clean ZBUFFER hard
alone or in combination with "Dynamic ZBUFFER fix".
Do you have similar problems in fullscreen mode too? Or disabling surface emulation?
Forcing a different renderer is possible and I made some experiments, but I judged it as useless since the game almost always crashed, requiring other arrangements more that the simple renderer switch. But that was with a very demanding game, it is possible that WipeoutXL could better cope with such a change: I'll try and let you know. In particular, it is highly probable that a software renderer will reduce the ZBUFFER problems.
*** update ***
I installed the game and DxWnd release on my second pc equipped with Win10 64bit and an AMD Radeon M5 200 series video card, and the texture clipping effect is perfectly visible. Also, none of the tricks I suggested or others that I tried was working. I'm going to try a renderer switch, but this effects is visible in other games too, does enyone have some patch to suggest?
Last edit: gho 2017-04-05
Actually it's just like Star Wars Shadows of the Empire, where it works too fast but properly in an Intel IGPU but fails on AMD GPU. Not sure if that'll help you out but GOG version they released simply works now : https://www.gog.com/game/star_wars_shadows_of_the_empire seems like in addition to MS ACT patch they've rolled out some custom ddraw DLL.
For Wipeout I've tried to force HEL for the full game but then the game will say you need a 3D accel, I guess code has been stripped out from the game.
The only official patch I know is WipEout XL Network Patch v0.9 Beta @ https://archive.org/details/WOXLN1 but it does not change anything for DxWnd.
I did try Z-buffer settings but none worked, and other surface emulations all hang the game with a black screen which quits a little after :(
a possiblestrategy, though not at all easy, could be to copy from GOG: roughly speaking, this is what I should (would) do:
1) run the normal game with DxWnd and collect ddraw traces
2) run the GOG game version and collect the actual ddraw traces (that is, not the calls to the ddraw wrapper but the calls to the actual ddraw.sll in system folder)
3) compare the logs, find the differences and try to emulate.
Easy to tell, a little less to do. Wish me good luck.
This, of course, unless someone who knows wouldn't be so kind to talk ....
Last edit: gho 2017-04-06
Yes, good luck :)
It's a shame that many old games run very well on Wine, you've never considered importing their entire stack emulated in OpenGL ? (not an easy task I agree)
Yes, I considered it and even tried it, grabbing one build of Wine libraries compiled for Windows.
The result was not so exciting: OpenGL is not always available with hw drivers for all cards, and if you use sw emulation the performance results are awful. In addition, the game compatibility was not good at all, the games that mostly interested me simply crashed.
Last but not least, some internet article (it shouldn't be difficult to find it) mentioned a dependency problem: recent Win10 OpenGL are based on ddraw, so if you stack all sw layers you get ddraw emulated by OpenGL emulated by ddraw .... and this is a loopback, can't work unless you make some nasty trick like renaming ddraw.dll or such. The scenario seems much more troublesome and complex than the current DxWnd one, where most games simply work and a few give problems (for the moment ...).
Yes, I guess you've decided to roll-out your own stack because in the end it's definitely better :)
About the demo, yes it offers 3 different renderers (Ramp, RGB and D3D) but the results are not so exciting: apart from the resolution limited to 640x480, Ramp has artifacts, RGB shows a black scene and D3D doesn't work. Anyway, it could prove useful to learn something about how to switch renderers.
I confirm the exact behavior as yours over here, using DxWnd !
Ironically, it runs rather well in VirtualBox,
Here are some preliminary tests, forcing the renderer value. It seems that there are two classes of renderer, the HW that requires video memory surfaces and the SW that goes along with system memory surfaces. You can switch renderer type within the SW class (MMX, Ramp, RGB) though with strange results, but you can't switch a SW class to the HAL renderer. The screenshot filenames tell the supposed renderer 2 (to) the forced renderer. Could this become useful? Who knows ...
Last edit: gho 2017-04-06
Looks like there's some palettization issue !
Could be, yet another weapon in your sleeve to make old games to work :)
I tried to compare "Wipeout XL" and "SW Shadov of the Empire" (SWSotE in short) with their respective GOG versions. The situation is a little different from expected:
1) Wipeout XL GOG seems still in people's wish list, it was probably never released
2) SWSotE GOG works fine, though GOG locked the renderer to HAL only
3) DxWnd hack for SWSotE supports also RGB renderer, but at an incredibly slow frame rate
4) DxWnd SWSotE runs fine (and in window!) but polygons are misplaced (see screenshot: the mech legs seem twisted!)
5) GOG did not use any wrapper ddraw.dll for SWSotE
anyone could at least help giving a name to this effect? Is it bad culling? uncleared ZBUFFER? Any clue to find a recipy?
From what I can tell with my experience fiddling with shaders and so on, the polygons the camera is facing are being culled out while they shouldn't be, i.e. Superman vision to see through things.
Now what could be the cause of this ?
When a camera 'near clipping plane' is too far this kind of weird effect happens, what should be visible is culled, resulting in a see-through effect.
Why is that happening ?
I don't know, is some matrix or whatever that affects the calculation is mis-interpreted or lost, resulting in a mostly perfect result. Some rounding issues or casting to an inappropriate number type ?
It is quite hard to tell when looking at the legs, but looking at the head definitely remembers this kind of issue.
Also, while the legs seem closer to user, there might be an angle involved in the calculation.
Hope that makes sense to you :)
Last edit: aybe 2017-04-07
Does it makes sense to me? Well, just a little, but it is a track and I can follow this path. DxWnd has to deal with a lot of programming details, and it hasn't everything under control: if the cause of the problem is the "culling", I can start digging in the code, adding the missing hooks for the D3D methods that are involved in this mechanism, analyze the logs, decide a strategy, implement and produce a fix .... but it is a hell of a job, and it would be quite reassuring if I could know that such a hack exists that produces the wanted effect, even without source code: at least it would ensure that the goal is reacheable and the effort is in the right direction.
It's certainly a simple thing though the trick is to find what is it ...
The author of glrage fixed out rendering issues in Wipeout for ATI CIF, maybe you can get some inspiration from his repository ?
https://github.com/ata4/glrage/issues/3
Can't you spot out the difference between SWOTE for GOG and under DxWnd ? (not easy I agree)
I don't really know the DirectX beast, is it something that devs are put under control where you have a limited scope ? Or is it like for example Amiga where there would be no kind of 'well-known pattern' ?
bump
i've been trying the latest version of dxwnd as of today but it seems like situation hasn't improved much, 3d models cannot be seen and therefore the track in game.
FWIW
I've tried latest https://github.com/narzoul/DDrawCompat/releases/tag/experimental
It's almost perfect, maybe that can give you an idea on how to support from within dxwnd ?
cheers
Thank you for the DDrawCompat link, I'll surely test it. But a solution that fixes a fullscreen game could be different from one that works in window mode, the windowizing process is more complex. Let's see ....
A very quick test: the ddraw.dll file from DDRawCompat bundle is compatible with DxWnd: if you copy the DDRawCompat ddraw.dll file to the game folder and configure DxWnd to run the game, you can get the game running in window and without artifcts.
That's good news, it provides a quick solution to the problem and proves that it is also possible to fix the game in window mode somehow. Very interesting!
Indeed !
I haven't been to slow the game down, though.
Even though you made a great job documenting the software, it's still incredibly difficult to use, mainly because noobs lack the necessary knowledge to understand how exactly each option would affect an executable.
The game doesn't have a very good timing control: it runs as fast as possible.
In addition, DDrawCompact seems to increase the efficiency and the game runs even faster.
The situation is partially recovered by DxWnd with the suggested exported configuration that includes the "DirectX(2) / vSync ON" flag that ensure you can't have more than 60 FPS. In addition, if you want the game even slower, you can set s delay in the "Timing / Limit" field, something between 20 to 100 mSec should do fine. Unfortunately, if you use a high delay value, the game will start to be choppy.
In addition to the audio emulation issues, which was resolved in another thread, I have an issue with the sky texture.
Both with DxWnd and without DxWnd this texture doesn't render at all and my sky is black on my Nvidia in all maps. If I do a textures dump, the sky is there. The picture texture.256.256.R5G6B5.0CB32CA4.bmp shows a texture from the PHENITIA PARK map. It should look like this: https://youtu.be/bcu_KfPxAFM?t=354
I haven't come up with any solution.
Last edit: huh 2022-12-07