I'm sorry for bombing with questions just like that.
Some time ago I've bought Incoming (by Rage) and acquired it lately from GOG. The problem is - it doesn't work. I've read it worked with AMD hardware until Catalyst 13.2 beta 7.
This is the error message
CreateSurface for Z-buffer failed.
Action not supported.
I've also used qAPI to trace the file. The most interesting result is:
I've read that Crimson Skies behaves in a similar way. I've tried its' fix but it didn't work. When I pick ones myself - it errors out that the game can't find proper device.
Any idea what should I look at?
Best Regards,
Marek
Last edit: Marek 2014-02-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm sorry to say that both games are working nicely on Win7 and with (or without) dxwnd. That makes quite harder to fix a problem that I can't see.
Have you tried to run the game with dxwnd? In order to do that you have to temporarily disable compatibility options from the game executables incoming.exe and forces.exe
You could also activate dxwnd logs (not all of them, the first 4 trace options should do fine - see screenshot) run the game just enough to replicate the problem and send the log (compressed!) to me.
Could you provide a link to qAPI (if it is a free product)? I never heard of it and it could be handy...
At a first glance, I see that you configured Incoming to run with "Automatic mode" emulation mode, that is not working either on my PC: switch it to "Locked surface" and try again.
On the contrary, Incoming Forces can be configured both in Automatic mode or Locked surface.
If you prefer try to import the export file here in attach (you have to delete the previoue dxwnd game entry and, after the import operation, to update the game path to point to the correct folder). If the game still doesn't work, please send logs again.
I've never like Incoming Forces that much so I installed only Incoming.
Anyway - thank you for the profile. The outcome's the same, unfortunately.
Here's the log: http://pastebin.com/jppcH22q
Can DXWnd bypass the problem if required caps are removed from the drivers?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Interesting:
Now the log shows a strange error in these lines:
CreateSurface: Version=1 lpdd=1443e78 SurfaceDesc: [CreateSurface] Flags=47(DDSD_CAPS+HEIGHT+WIDTH+ZBUFFERBITDEPTH) Width=640 Height=480 Caps=24000(DDSCAPS_VIDEOMEMORY+ZBUFFER)
CreateSurface: lpDDZBuffer=0 save ZBUFFER caps=24000(DDSCAPS_VIDEOMEMORY+ZBUFFER)
CreateSurface: CreateSurface ERROR res=80004001(DDERR_UNSUPPORTED) at 2554
Apparently you can't create a ZBUFFER with these characteristics in video memory. Fortunately, video memory problems are common enough to have a dedicated flag: in dxwnd try to set the DirectX "switch VIDEO to SYSTEM on fail" flag and try again, always posting the new log in case of another failure!
P.s. if you succeed, try Incoming with the time stretching option! It could be a little unfair if you slow time down, but you could also simulate a "nightmare level" if you speed it up. I use it to avoid being killed within the first minute or so.
Last edit: gho 2014-02-20
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, tried it with the option you suggested. Seems it errors out with the same message: http://pastebin.com/xZm4HhqK
This time around the error msgbox is in the busy state (isn't being drawn).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, I got it (my fault again, sorry): the recovery logic implied by the "switch VIDEO to SYSTEM on fail" is triggered by the DDERR_OUTOFVIDEOMEMORY error. Here, the program shows another error, DDERR_UNSUPPORTED. So, there are two possible fixes: I apologize using you as a beta tester, but I have no other way. The first one is to include the DDERR_UNSUPPORTED in the triggering condition to switch to system memory, that is what I did in the debug dll uploaded here: just replace it in the dxwnd folder and see what happens (keeping the "switch VIDEO to SYSTEM on fail" turned on). It this does not work, I could try to fake there's no support for some ZBUFFER-ing capability in the GetCaps method and try to make the program chose another path.
CreateSurface: CreateSurface ERROR res=80004001(DDERR_UNSUPPORTED) at 2554
EUREKA - it works :) I totally don't mind being beta tester ;)
There are still issues though. The best way would be for me to record a movie and post it somewhere. Unfortunately neither FRAPS, nor DXTORY seem to work.
Anyway - there are clipping issues i.e. you can see object on the other side of the hill, that shouldn't normally be visible (I guess it's Z-buffer related). Check the attached image.
I'm afraid the new problems will be tougher to handle, because there seems to be no specific error message to track that.
I'll try to get some help, but in the meanwhile you coul do some experiments setting these flags to see if anything changes for the better:
Video: disable fogging (should get rid of the fog)
Clean ZBUFFER @0.0 fix
Clean ZBUFFER @1.0 fix
I'm not expecting the myracle, but it is easy enough to be worth trying.
And for sure the fog should disappear....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here comes an experiment with SetRenderState value for D3DRENDERSTATE_ZFUNC parameter set always to D3DCMP_LESS, avoiding some settings to D3DCMP_ALWAYS that may cause the problem.
The dll should be replaced on the dxwnd folder, as usual.
Does it produce any good effect?
That is interesting.
I tried to apply the suggested fix, but probably because I have not the right graphic card, the game crashes.
Too bad the post in the gog forum is not telling what capability has to be turned on or off, since it would be relatively easy to emulate this behaviour through dxwnd.
But I don't think we can find it out proceeding blindly one cap at a time and sending you a new release to test each time.... it would require years.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes - going CAP by CAP won't solve anything.
I've used DirectX Caps Viewer with and without this .dll file (only for the Direct3D9 section. I think DXGI and DirectDraw sections are irrelevant, am I correct?). You can find the logs in the attachment. Unfortunately these logs are wall of text and this program doesn't output it in any better form.
Feeding the two files to a diff manager (like Araxis Merge) make it easier to find the differences, but they are too many and too obscure indeed. At a first glance it seems that the wrong driver has extra capabilities for these three render target formats. I'll try to mask them and see what happens....
@ghotik i tried to lunch Incoming GOG Edition on Win10 but i get the error "CreateSurface for Z-buffer failed. The pixel format was invalid as specified".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The game is working here on my Win10. Probably the problem depends on the video card and drivers.
Could you upload here a dxwnd.log file with all details about ddraw errors? Please, configure the logs exactly as in the attached picture. If the game terminates in error immediately, the log should not be too big.
Strange.
Did you search the file in the game folder? (I suppose so ...)
There could be a permission problem in the game folder, or maybe the game changed its working directory before opening the log.
Some tests you could make:
1) repeat the test with DxWnd running as administrator
2) search for the "dxwnd.log" file in the game folder and all subfolders
3) search for the "dxwnd.log" file in the DxWnd folder (when the log file can't be opened in the local directory, DxWnd opens it in its own folder).
This evening I'll do the test by myself. Though the game is working on my computer, maybe I can understand what's going on with the logs ...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello gho.
I'm sorry for bombing with questions just like that.
Some time ago I've bought Incoming (by Rage) and acquired it lately from GOG. The problem is - it doesn't work. I've read it worked with AMD hardware until Catalyst 13.2 beta 7.
This is the error message
I've also used qAPI to trace the file. The most interesting result is:
And the details:
I've read that Crimson Skies behaves in a similar way. I've tried its' fix but it didn't work. When I pick ones myself - it errors out that the game can't find proper device.
Any idea what should I look at?
Best Regards,
Marek
Last edit: Marek 2014-02-18
I'm sorry to say that both games are working nicely on Win7 and with (or without) dxwnd. That makes quite harder to fix a problem that I can't see.
Have you tried to run the game with dxwnd? In order to do that you have to temporarily disable compatibility options from the game executables incoming.exe and forces.exe
You could also activate dxwnd logs (not all of them, the first 4 trace options should do fine - see screenshot) run the game just enough to replicate the problem and send the log (compressed!) to me.
Could you provide a link to qAPI (if it is a free product)? I never heard of it and it could be handy...
Last edit: gho 2014-02-18
Yes, qAPI is a free product. The project is located here: http://apitrace.github.io/
I've pasted the debug on Pastebin: http://pastebin.com/Bj9bCwET
BTW - I have W7 x64 with AMD Radeon R9 270X and Catalyst 14.1 Beta 1 drivers.
Last edit: Marek 2014-02-19
At a first glance, I see that you configured Incoming to run with "Automatic mode" emulation mode, that is not working either on my PC: switch it to "Locked surface" and try again.
On the contrary, Incoming Forces can be configured both in Automatic mode or Locked surface.
If you prefer try to import the export file here in attach (you have to delete the previoue dxwnd game entry and, after the import operation, to update the game path to point to the correct folder). If the game still doesn't work, please send logs again.
Last edit: gho 2014-02-19
I've never like Incoming Forces that much so I installed only Incoming.
Anyway - thank you for the profile. The outcome's the same, unfortunately.
Here's the log:
http://pastebin.com/jppcH22q
Can DXWnd bypass the problem if required caps are removed from the drivers?
Interesting:
Now the log shows a strange error in these lines:
CreateSurface: Version=1 lpdd=1443e78 SurfaceDesc: [CreateSurface] Flags=47(DDSD_CAPS+HEIGHT+WIDTH+ZBUFFERBITDEPTH) Width=640 Height=480 Caps=24000(DDSCAPS_VIDEOMEMORY+ZBUFFER)
CreateSurface: lpDDZBuffer=0 save ZBUFFER caps=24000(DDSCAPS_VIDEOMEMORY+ZBUFFER)
CreateSurface: CreateSurface ERROR res=80004001(DDERR_UNSUPPORTED) at 2554
Apparently you can't create a ZBUFFER with these characteristics in video memory. Fortunately, video memory problems are common enough to have a dedicated flag: in dxwnd try to set the DirectX "switch VIDEO to SYSTEM on fail" flag and try again, always posting the new log in case of another failure!
P.s. if you succeed, try Incoming with the time stretching option! It could be a little unfair if you slow time down, but you could also simulate a "nightmare level" if you speed it up. I use it to avoid being killed within the first minute or so.
Last edit: gho 2014-02-20
OK, tried it with the option you suggested. Seems it errors out with the same message:
http://pastebin.com/xZm4HhqK
This time around the error msgbox is in the busy state (isn't being drawn).
Ok, I got it (my fault again, sorry): the recovery logic implied by the "switch VIDEO to SYSTEM on fail" is triggered by the DDERR_OUTOFVIDEOMEMORY error. Here, the program shows another error, DDERR_UNSUPPORTED. So, there are two possible fixes: I apologize using you as a beta tester, but I have no other way. The first one is to include the DDERR_UNSUPPORTED in the triggering condition to switch to system memory, that is what I did in the debug dll uploaded here: just replace it in the dxwnd folder and see what happens (keeping the "switch VIDEO to SYSTEM on fail" turned on). It this does not work, I could try to fake there's no support for some ZBUFFER-ing capability in the GetCaps method and try to make the program chose another path.
CreateSurface: CreateSurface ERROR res=80004001(DDERR_UNSUPPORTED) at 2554
Last edit: gho 2014-02-22
EUREKA - it works :) I totally don't mind being beta tester ;)
There are still issues though. The best way would be for me to record a movie and post it somewhere. Unfortunately neither FRAPS, nor DXTORY seem to work.
Anyway - there are clipping issues i.e. you can see object on the other side of the hill, that shouldn't normally be visible (I guess it's Z-buffer related). Check the attached image.
There's also LOG file below
I'm afraid the new problems will be tougher to handle, because there seems to be no specific error message to track that.
I'll try to get some help, but in the meanwhile you coul do some experiments setting these flags to see if anything changes for the better:
Video: disable fogging (should get rid of the fog)
Clean ZBUFFER @0.0 fix
Clean ZBUFFER @1.0 fix
I'm not expecting the myracle, but it is easy enough to be worth trying.
And for sure the fog should disappear....
I've checked the flags - nothing's changed. See the screenshot. In the next post I'll upload the .log file.
Mentioned log file...
Here comes an experiment with SetRenderState value for D3DRENDERSTATE_ZFUNC parameter set always to D3DCMP_LESS, avoiding some settings to D3DCMP_ALWAYS that may cause the problem.
The dll should be replaced on the dxwnd folder, as usual.
Does it produce any good effect?
Last edit: gho 2014-02-22
Unfortunately not :(
Everything's the same.
EDIT:
I got the game running perfectly. unreal1time posted solution on GOG:
http://www.gog.com/forum/incoming_incoming_forces/incoming_graphics_problem/page1"
Basically, you're supposed to place a driver DLL containing required CAPS in the .exe's location. And now it works perfectly. Just for how long? - nobody knows.
Last edit: Marek 2014-02-24
That is interesting.
I tried to apply the suggested fix, but probably because I have not the right graphic card, the game crashes.
Too bad the post in the gog forum is not telling what capability has to be turned on or off, since it would be relatively easy to emulate this behaviour through dxwnd.
But I don't think we can find it out proceeding blindly one cap at a time and sending you a new release to test each time.... it would require years.
Yes - going CAP by CAP won't solve anything.
I've used DirectX Caps Viewer with and without this .dll file (only for the Direct3D9 section. I think DXGI and DirectDraw sections are irrelevant, am I correct?). You can find the logs in the attachment. Unfortunately these logs are wall of text and this program doesn't output it in any better form.
Feeding the two files to a diff manager (like Araxis Merge) make it easier to find the differences, but they are too many and too obscure indeed. At a first glance it seems that the wrong driver has extra capabilities for these three render target formats. I'll try to mask them and see what happens....
Would you mind trying the latest release? I fixed a problem about ZBUFFER in d3d7, maybe Incoming is effected.....
Thanks for the update.
I've tried the newest version and there's still problem with clipping.
@ghotik i tried to lunch Incoming GOG Edition on Win10 but i get the error "CreateSurface for Z-buffer failed. The pixel format was invalid as specified".
The game is working here on my Win10. Probably the problem depends on the video card and drivers.
Could you upload here a dxwnd.log file with all details about ddraw errors? Please, configure the logs exactly as in the attached picture. If the game terminates in error immediately, the log should not be too big.
I dont see any log file.. Selected all like on the screenshot and run multiple times. No file is created...
Strange.
Did you search the file in the game folder? (I suppose so ...)
There could be a permission problem in the game folder, or maybe the game changed its working directory before opening the log.
Some tests you could make:
1) repeat the test with DxWnd running as administrator
2) search for the "dxwnd.log" file in the game folder and all subfolders
3) search for the "dxwnd.log" file in the DxWnd folder (when the log file can't be opened in the local directory, DxWnd opens it in its own folder).
This evening I'll do the test by myself. Though the game is working on my computer, maybe I can understand what's going on with the logs ...
1) Always use Administrator mode
2) no luck here..
3) no luck here too..
i will give you an update when i will find that file