This case, signaled by cloudstr, is becoming quite interesting.
It has three main problems, all different each other and possibly independent.
1) Can't be run in surface emulation mode, unless you check the debug flags for disabling SYSTEMMEMORY options in surface creations, but this way it becomes terribly slow and choppy. Fortunately, it works pretty well in not emulated mode.
2) It makes use of the user32.dll CreateDesktop() call, and crashes unless this call is disabled (fortunately, this is easy...)
3) with the above tricks set, it shows the intro movies and the menues, but when about to enter in real 3D mode and start a race, it shows an error panel telling about a "no errorcode" error, see log for more info (but the log isn't telling much!)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2015-05-27
"no errorcode" error happens in fullscreen too, I find help and did figure out that there was a patch that may fix the problem and also improve the performance:
Good, but it doesn't work: I have the CD version, downloaded and applied the 1.32 patch (and the rest of te procedure ...) but the "no errorcode" error is still there, both with and without DxWnd.
Well, at least one can say that it's a "perfect" emulation: either way, you get the same result!
Tomorrow I'll try some disassembling to try to understand what is this mysterious error with no name. Now I'm going to have some sleep....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2015-05-28
yay, figure out how to fix "no errorcode" ;)
Applying 1.32 patch > run game, in the upper left corner of loading screen, click the "Device Setup" extreme fast > click Renders setting > Uncheck "Use PAL8 textures", may check other flag to improve quality > Done! Yet the game still runs quite choppy.
It sucks that the PAL8 flag revert back to enable everytime running the game... ugggh. Hope we can understand what PAL8 textures does for the game.
Last edit: Anonymous 2015-05-28
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2015-05-28
"Use PAL8 textures" is a common problem on some racing games like Rally Master. The PAL8 textures in the game engine are NOT compatible with the ATI drivers. Disabling PAL8 textures will allow you to run the game.
Thank you cloudstr!
The game demo (I got the file, at last) runs unexpectedly smooth and with no need for SYSTEMMEMORY patching and with the trick you suggested enters the 3D race mode (see shots).
This provide a reference case to investigate the differences and should make it easier to find a fix!
P.s. in the game demo, the disabled PAL8 configuration is stored and retained. Maybe you just have to exit the game gracefully or press some ok button somewhere to make it permanent....
Hi,
I recently installed the STCC game again after more than 20 years, ran it on an old PC from that time period that I held on to.
Got a question for @ghotik:
How did you find and extract the textures?
I have been trying to extract the cars to look at some of the sponsors from then on the Audi.
The Audi is embedded in the file named car03A.pdo.
Best Regards,
J.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The textures can be extracted by setting DxWnd in Extended mode (from titlebar menu "Options > Extended mode") then "Modify" and going to the "3D" Tab set the "Texture handling" selector to "Dump". When you run the game all textures processed by the game will be dumped. More details are in the help pages in the "3D" section.
This is all about dumping the textures. To modify them is a little trickier, if you plan to do that I'm going to give you some more hints.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Another difference between the demo and full game release is the fact that the demo is not using user32.dll Desktop calls, so it's not necessary a patched DxWnd release that intercepts the CreateDestopEx function.
It should be VERY interesting to analyze what makes the difference that allows emulated mode working in the demo and not working in the full game. My hope is to understand the reason why a few games still can't run in surface emulation mode (that is AERO friendly and gives the best performances with no additional pain in general) and fix the problem.
*** update ***
I'm now trying to compare demo and full game on the same PC, but they both fail in running in emulated mode. Hence, the problem could be the different PC I used to run the demo. Likely, there's some missing video capability...
But this means that perhaps you can run the full game on your PC.
I just uploaded the v2.03.23 release that make the last changes needed to run STCC and CloseCombat2 to everybody.
Last edit: gho 2015-05-28
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2015-05-28
Close Combat still a one hell of problem for me. In game, press F8 to change resolution.
As default the resolution is 800x600, the game stretch to fullscreen -> Dxwnd failed
Changing resolution to 1024x768, very interesting that Dxwnd work in this case. But the window stuck in the upper left corner screen..
Actually Dxwnd DOES hook the game, but just on 1024x768 resolution and the result is so-so. I'm running XP so maybe that is the problem, or the new registry query calls need some improvement?
Dxwnd-OG and D3Dwindower have succeeded windowed the game though.
I deleted it because I thought you had problems with the registry, but then I saw from the logs that you didn't!
In any case, I was suggesting to use this dxwnd.reg file that holds both the full game and demo registry values (they use a different key value)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2015-05-29
No luck here, but this gives me a thought that my display resolution is not large enough to contain the game window. I always set resolution to 1024x768, cause I had an old monitor and set higher doesn't bring any benefit other than decrease the performance.
What is your display resolution? Do you think 1600x1200 is a minimal
resolution for seeing the window game?
Last edit: Anonymous 2015-05-29
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No, in emulation mode the screen resolution need to be just enough to contain the entire window, otherwise the ddraw blit operations would give an error. But from the logs it seems that the game does a full set of registry checks and settings and then simply closes before even trying to access the screen. I have to analyze that a little better, but I anticipate that here there's a few days holiday and I think I'll be away spending some time with the family (and away from the PC!).
I'll bring the portable with me, but just in case...
See ya later! (next wednsday at the most) ;)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This game seems very interesting and useful to try to better understand some problems abour older D3D surface emulation.
This is what I found out so far:
1) depending on the PC I'm using (same OS Win7 64bit, just different video card) the game supports DxWnd default surface emulation mode.
2) the difference in the two cases is that the CreateSurface call either succeeds or fail
3) the difference (debugging the d3d assembly!) seems to be in the availability of the ZBUFFER surface reference attached to the virtual primary surface, that is not present at a given memory address. Surprisingly, there is no difference in the behaviour of the ddraw calls called within d3d!
4) where the operation fails, disabling the DDSCAPS_SYSTEMMEMORY option in the virtual primary surface creation fixes the problem, but the game becomes incredibly slow, so this is not a good solution!
5) Apparently, the AddAttachedSurface operation between primary and ZBUFFER succeeds in both cases.
The reason why I spend so much time about this is that I hope to understand the reason why some games don't support surface emulation to fix the problem and provide a unified and much simpler game configuration for all d3d games up to the introduction of d3d8/9. That would reduce the DxWnd configuration nightmare!
@aqrit: if you're interested, I can provide more details about where to look inside the d3d assembly.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This case, signaled by cloudstr, is becoming quite interesting.
It has three main problems, all different each other and possibly independent.
1) Can't be run in surface emulation mode, unless you check the debug flags for disabling SYSTEMMEMORY options in surface creations, but this way it becomes terribly slow and choppy. Fortunately, it works pretty well in not emulated mode.
2) It makes use of the user32.dll CreateDesktop() call, and crashes unless this call is disabled (fortunately, this is easy...)
3) with the above tricks set, it shows the intro movies and the menues, but when about to enter in real 3D mode and start a race, it shows an error panel telling about a "no errorcode" error, see log for more info (but the log isn't telling much!)
It's on my list....
Last edit: gho 2015-05-27
"no errorcode" error happens in fullscreen too, I find help and did figure out that there was a patch that may fix the problem and also improve the performance:
http://www.team-ulm.de/Forum/1737/108098/
Sadly the patch is only applied for CD version and useless for demo..
http://m0001.gamecopyworld.com/games/pc_stcc.shtml
Good, but it doesn't work: I have the CD version, downloaded and applied the 1.32 patch (and the rest of te procedure ...) but the "no errorcode" error is still there, both with and without DxWnd.
Well, at least one can say that it's a "perfect" emulation: either way, you get the same result!
Tomorrow I'll try some disassembling to try to understand what is this mysterious error with no name. Now I'm going to have some sleep....
yay, figure out how to fix "no errorcode" ;)
Applying 1.32 patch > run game, in the upper left corner of loading screen, click the "Device Setup" extreme fast > click Renders setting > Uncheck "Use PAL8 textures", may check other flag to improve quality > Done! Yet the game still runs quite choppy.
It sucks that the PAL8 flag revert back to enable everytime running the game... ugggh. Hope we can understand what PAL8 textures does for the game.
Last edit: Anonymous 2015-05-28
"Use PAL8 textures" is a common problem on some racing games like Rally Master. The PAL8 textures in the game engine are NOT compatible with the ATI drivers. Disabling PAL8 textures will allow you to run the game.
http://www.compatdb.org/forums/topic/25171-rally-masters-which-agp-card/
Thank you cloudstr!
The game demo (I got the file, at last) runs unexpectedly smooth and with no need for SYSTEMMEMORY patching and with the trick you suggested enters the 3D race mode (see shots).
This provide a reference case to investigate the differences and should make it easier to find a fix!
P.s. in the game demo, the disabled PAL8 configuration is stored and retained. Maybe you just have to exit the game gracefully or press some ok button somewhere to make it permanent....
Last edit: gho 2015-05-28
Oh, my! What an huge amount of customization possibilities.... textures are all there, exposed for possible updates (see just a few examples)!
Hi,
I recently installed the STCC game again after more than 20 years, ran it on an old PC from that time period that I held on to.
Got a question for @ghotik:
How did you find and extract the textures?
I have been trying to extract the cars to look at some of the sponsors from then on the Audi.
The Audi is embedded in the file named car03A.pdo.
Best Regards,
J.
The textures can be extracted by setting DxWnd in Extended mode (from titlebar menu "Options > Extended mode") then "Modify" and going to the "3D" Tab set the "Texture handling" selector to "Dump". When you run the game all textures processed by the game will be dumped. More details are in the help pages in the "3D" section.
This is all about dumping the textures. To modify them is a little trickier, if you plan to do that I'm going to give you some more hints.
Another difference between the demo and full game release is the fact that the demo is not using user32.dll Desktop calls, so it's not necessary a patched DxWnd release that intercepts the CreateDestopEx function.
It should be VERY interesting to analyze what makes the difference that allows emulated mode working in the demo and not working in the full game. My hope is to understand the reason why a few games still can't run in surface emulation mode (that is AERO friendly and gives the best performances with no additional pain in general) and fix the problem.
*** update ***
I'm now trying to compare demo and full game on the same PC, but they both fail in running in emulated mode. Hence, the problem could be the different PC I used to run the demo. Likely, there's some missing video capability...
But this means that perhaps you can run the full game on your PC.
I just uploaded the v2.03.23 release that make the last changes needed to run STCC and CloseCombat2 to everybody.
Last edit: gho 2015-05-28
Close Combat still a one hell of problem for me. In game, press F8 to change resolution.
As default the resolution is 800x600, the game stretch to fullscreen -> Dxwnd failed
Changing resolution to 1024x768, very interesting that Dxwnd work in this case. But the window stuck in the upper left corner screen..
Actually Dxwnd DOES hook the game, but just on 1024x768 resolution and the result is so-so. I'm running XP so maybe that is the problem, or the new registry query calls need some improvement?
Dxwnd-OG and D3Dwindower have succeeded windowed the game though.
Last edit: Anonymous 2015-05-28
Hey gho, can't see your new comment. Please post again
I deleted it because I thought you had problems with the registry, but then I saw from the logs that you didn't!
In any case, I was suggesting to use this dxwnd.reg file that holds both the full game and demo registry values (they use a different key value)
No luck here, but this gives me a thought that my display resolution is not large enough to contain the game window. I always set resolution to 1024x768, cause I had an old monitor and set higher doesn't bring any benefit other than decrease the performance.
What is your display resolution? Do you think 1600x1200 is a minimal
resolution for seeing the window game?
Last edit: Anonymous 2015-05-29
No, in emulation mode the screen resolution need to be just enough to contain the entire window, otherwise the ddraw blit operations would give an error. But from the logs it seems that the game does a full set of registry checks and settings and then simply closes before even trying to access the screen. I have to analyze that a little better, but I anticipate that here there's a few days holiday and I think I'll be away spending some time with the family (and away from the PC!).
I'll bring the portable with me, but just in case...
See ya later! (next wednsday at the most) ;)
This game seems very interesting and useful to try to better understand some problems abour older D3D surface emulation.
This is what I found out so far:
1) depending on the PC I'm using (same OS Win7 64bit, just different video card) the game supports DxWnd default surface emulation mode.
2) the difference in the two cases is that the CreateSurface call either succeeds or fail
3) the difference (debugging the d3d assembly!) seems to be in the availability of the ZBUFFER surface reference attached to the virtual primary surface, that is not present at a given memory address. Surprisingly, there is no difference in the behaviour of the ddraw calls called within d3d!
4) where the operation fails, disabling the DDSCAPS_SYSTEMMEMORY option in the virtual primary surface creation fixes the problem, but the game becomes incredibly slow, so this is not a good solution!
5) Apparently, the AddAttachedSurface operation between primary and ZBUFFER succeeds in both cases.
The reason why I spend so much time about this is that I hope to understand the reason why some games don't support surface emulation to fix the problem and provide a unified and much simpler game configuration for all d3d games up to the introduction of d3d8/9. That would reduce the DxWnd configuration nightmare!
@aqrit: if you're interested, I can provide more details about where to look inside the d3d assembly.
Some time (and DxWnd releases) have passed by, and it is a pleasure to see that now this game runs perfectly smooth with DxWnd default options.