Here is another interesting case. The game works with default dxwnd options except that it runs too fast. The "Optimize CPU" flag does not reduce game speed enough but the Timing option limit 40 msec (1000/40 = 25FPS) seems to do the trick. For running in windowed mode the Input option "Force cursor clipping" is useful.
Also with v2_03_91_fx2_build the window intial size has to be set to 0,0 or there is a crash.
Now the game should run fine but only in software rendering mode. If running in Direct3D the game crashes every time a mission is completed or aborted. It is possible to avoid this by setting the emulation to "Locked Surface" but this seems to mess the colors in the game menu graphics.
The demo version of the game supports only Direct3D and Glide rendering and it should be enough to see the crashing when aborting a mission.
Comparing the CD retail game in software mode and the D3D mode I found out that the logs appear similar until in the D3D version you get the following errors: DDERR_OUTOFVIDEOMEMORY
followed by: DDERR_NOTFOUND
and then: DDERR_OUTOFMEMORY
After that it seems to start repeating with the errors: DDERR_NOCOLORKEY **
and: DDERR_NOTFOUND**
Uh, interesting case: I think I trascurated this game, it was never tried with (or without) DxWnd.
On my Win10 with defaul configuration the game crashes right before the mission start, which is an improvement respect the fact that without DxWnd I just see a black screen and nothing moves.
Looking for the error logs I found perhaps something interesting:
The reference to MCI_SET_TIME_FORMAT could define a new and unsupported time measurement, so if this is the case some addition to DxWnd logic will be required. Yumm, some tasty code!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Are you seeing the same thing with the window initial size on your machine? That is with dxwnd v2_03_90 I can set the window resolution manualy but on v2_03_91 I have to set it to 0,0 or the game crashes at start up.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Wow! Nice game.....
I installed from the 2CD release, then I had to set the compatibility "Hide empty CDROM drives" because the game expects to find data on the FIRST available CD-Rom driver.
The game started ok (there are some minor glitches, but nothing really serious) but you can't leave or minimize the window because it jumps in the upper left corner of the screen and there's no way to have it back.
I'm looking for patches and new releases, because I suspect there should be different versions around and their behaviour with DxWnd could be quite different.
I tested Heavy Gear v.1.2 on Virtual Windows machines and it worked on Windows Millenium Edtion but crashed on Windows XP the same way as it does on Win7.
So maybe getting the Direct3D mode of version 1.0 working without the end of mission crash would be an easier task.
By the way I have read that the game Interstate 76 uses the same game engine as Heavy Gear.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Uhm, debugging this crash is a real pain: I'm not a good mech writer, I can hardly get to the crash point! Do you know some quicker way to get to the crash?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What an exciting hunt!
First I noticed that the problem occurs only when running the game in emulation modes. Without emulation and in Win10 navigating the menues is very hard, but not impossible: look at the "unemulated.png" attach, exiting the game from there doesn't crash.
So I started with OllyDBG and soon discovered that there were problems trying to use the Palette object, likely because it was deallocated. Looking at the logs I got these:
Well, ok, you saw that before me, but such an error means very little, in fact it doesn't prevent the game to work. But the palette doesn't get the extra reference, so when you Release it you should take this into proper account. Heavy Gear trusts that the operation didn't fail and release the palette object a fixed number of times, trying to release a deleted object.
So the only possible fix is to ass an extra reference if there is a failure. Just one tiny extra line of code and .... the game WORKS!
Screenshots and dxwnd.dll in attach, enjoy, I'm going to sleep quite happily!
Very well.
This could be the battle plan from now on. Please, read it and revise if you think there's possibly more than this:
1) stretch game movies - that is avoid game crashing when GDI stretching modes are selected
2) make patched version 1.2 playable
3) test for possible resource leakage (you may hate being crashed in the middle of a long mission!)
4) try to apply 1.1 patch only (on Win10 the installer hangs on a black screen)
5) check for texture dumping & hacking, in case anyone may want to hack the game.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First update (likely Riitaoja already knew, but maybe someone else could be interested):
Patch hgp187d.exe stops in a black window if launched with a double-click of the mouse. Better run a command prompt and run it from there, a dialog box will show and will let you apply the patch.
The patched game is still playable with DxWnd.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unbelievable! The v1.2 patch problem has nothing to do with ZBUFFERING or whatever.
The programs get caught in an endless loop of FreeLibrary() calls because it expects a 0 return code (as if it were a reference counter!), that is actually an error code. The proper return code should be a not null value, like TRUE, but this is not understood by the program?
I should check if on old OS like Win95/98 the FreeLibrary call had a different retcode meaning.
In any case, this will require a dedicated flag, since setting the FreeLibrary retcode to 0 could impact other programs.
But the game WORKS and has much better graphic effects!!!!
Last edit: gho 2016-10-17
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That is very exciting news. I was sure that it was not going to be possible to get the 1.2 version working since it has not worked since the Windows 9x days. Interesting to see how the graphics improve with that version of the game in Direct3d mode!
For the v1.1 (hgp187d.exe) patch on Windows7 it installed without any special tricks. There was a windows registry update error at the end but that may have been due to not running the patcher with admin rights. In any case 1.1 seems to work but it does not do anything very noticable to the game in Direct3D mode. However it does make the 3dfx graphics look slightly better.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was sure that it was not going to be possible to get the 1.2 version working since it has not worked since the Windows 9x days
Man, you have no faith! Enjoy this fine beta (in attach) that makes the patched release playable. IMO it is really far better than the unpatched release! Please, note the Compat. / "fix FreeLibrary" new flag that is needed to simulate the FreeLibrary behavior of the old glorious days of Win9X!
P.s. the 1.2 patch adds support for 3DFX cards, but if you don't have one you can add a glide2x.dll file to the game folder from any glide wrapper just to avoid a irritating dialog box at game startup.
Do not forget bilinear filtering, desktop workarea, keep aspect ratio and, at least on Win7, hide desktop background. Win10 is still giving me some troubles .... ;)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There is quite an old version available from 2002 (version 0.08 Final) with source code and I tested it together with Dxwnd and to my suprise it worked. Well there were many graphical errors but at least it did not crash like it does if I use any other wrapper like nGlide or DgVoodoo together with dxwnd.
If you are interested in testing it out download the Release 0.08 Final and place the Glide2x.dll to the Heavy Gear folder. Set the graphics type to 3dfx in the combat variables of heavy gear. Do not use the "Hook Glide libs" flag of dxwnd or it will crash.
Ofcourse the Openglide wrapper is not as good as the nGlide and DgVoodoo wrappers but atleast it could provide some insight into the mysterious world of 3dfx/Glide emulation.
The idea is very good and is already in my future plans, I simply didn't have enough time to "implement" it. But having a stable and working open source project could be a perfect startup.
Right now I was bumping my head on the seemingly silly problem of the movies: the game seems to use different movie rendering engines (AviPlayer, SmackW32) all deeply buried in layers of dynamically loaded dll, so that DxWnd is getting lost and can't find the hook point to intervene.
It is all a matter of geometry relocation: if you want to enjoy a centered intro movie, enable debug settings and set "FullRECT Blit". The movie will be rendered as it should be, but after that the game will crash!
Last edit: gho 2016-10-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here is another interesting case. The game works with default dxwnd options except that it runs too fast. The "Optimize CPU" flag does not reduce game speed enough but the Timing option limit 40 msec (1000/40 = 25FPS) seems to do the trick. For running in windowed mode the Input option "Force cursor clipping" is useful.
Also with v2_03_91_fx2_build the window intial size has to be set to 0,0 or there is a crash.
Now the game should run fine but only in software rendering mode. If running in Direct3D the game crashes every time a mission is completed or aborted. It is possible to avoid this by setting the emulation to "Locked Surface" but this seems to mess the colors in the game menu graphics.
The demo version of the game supports only Direct3D and Glide rendering and it should be enough to see the crashing when aborting a mission.
The demo can be downloaded from here:
https://archive.org/details/hgdemo
My tests were done on a Win7 64bit machine.
Comparing the CD retail game in software mode and the D3D mode I found out that the logs appear similar until in the D3D version you get the following errors:
DDERR_OUTOFVIDEOMEMORY
followed by:
DDERR_NOTFOUND
and then:
DDERR_OUTOFMEMORY
After that it seems to start repeating with the errors:
DDERR_NOCOLORKEY **
and:
DDERR_NOTFOUND**
Attached is a short and a long version of the log starting from where the errors begin in the D3D demo version of the game.
Uh, interesting case: I think I trascurated this game, it was never tried with (or without) DxWnd.
On my Win10 with defaul configuration the game crashes right before the mission start, which is an improvement respect the fact that without DxWnd I just see a black screen and nothing moves.
Looking for the error logs I found perhaps something interesting:
The reference to MCI_SET_TIME_FORMAT could define a new and unsupported time measurement, so if this is the case some addition to DxWnd logic will be required. Yumm, some tasty code!
Are you seeing the same thing with the window initial size on your machine? That is with dxwnd v2_03_90 I can set the window resolution manualy but on v2_03_91 I have to set it to 0,0 or the game crashes at start up.
Wow! Nice game.....
I installed from the 2CD release, then I had to set the compatibility "Hide empty CDROM drives" because the game expects to find data on the FIRST available CD-Rom driver.
The game started ok (there are some minor glitches, but nothing really serious) but you can't leave or minimize the window because it jumps in the upper left corner of the screen and there's no way to have it back.
I'm looking for patches and new releases, because I suspect there should be different versions around and their behaviour with DxWnd could be quite different.
All my earlier tests were done with version 1.0.
The Patches scrolls has 1.1 and 1.2 patch for Heavy Gear.
http://www.patches-scrolls.de/patch/2003/7/
With the smaller 1.1 patch I did not notice any difference in the games behaviour.
With the larger 1.2 patch the game is now crashing for me too if I try to start the mission no matter if I run in software or Direct3d.
It might be nice to get the 1.2 version working since it claims to add better textures and 3d effects together with bug fixes.
Last edit: Riitaoja 2016-10-15
P.S.
The settings to change the renderer from software to direct3d are hidden under the "combat variables" name when you hit ESC in the main screen.
Ok, thank you for the hints.
Same situation here: 1.0 in D3D mode is much better, 1.2 patched hangs before entering the combat.
Roger that.
I tested Heavy Gear v.1.2 on Virtual Windows machines and it worked on Windows Millenium Edtion but crashed on Windows XP the same way as it does on Win7.
So maybe getting the Direct3D mode of version 1.0 working without the end of mission crash would be an easier task.
By the way I have read that the game Interstate 76 uses the same game engine as Heavy Gear.
Uhm, debugging this crash is a real pain: I'm not a good mech writer, I can hardly get to the crash point! Do you know some quicker way to get to the crash?
In Direct3d mode it should crash in the mission if you press ESC and choose "abort mission" from the list.
Wow! That's something even a dummy pilot like me can manage..... ;)
What an exciting hunt!
First I noticed that the problem occurs only when running the game in emulation modes. Without emulation and in Win10 navigating the menues is very hard, but not impossible: look at the "unemulated.png" attach, exiting the game from there doesn't crash.
So I started with OllyDBG and soon discovered that there were problems trying to use the Palette object, likely because it was deallocated. Looking at the logs I got these:
Well, ok, you saw that before me, but such an error means very little, in fact it doesn't prevent the game to work. But the palette doesn't get the extra reference, so when you Release it you should take this into proper account. Heavy Gear trusts that the operation didn't fail and release the palette object a fixed number of times, trying to release a deleted object.
So the only possible fix is to ass an extra reference if there is a failure. Just one tiny extra line of code and .... the game WORKS!
Screenshots and dxwnd.dll in attach, enjoy, I'm going to sleep quite happily!
Last edit: gho 2016-10-16
Great work again GHO!
The game plays nicely in Direct3D mode now. No more crashing.
Very well.
This could be the battle plan from now on. Please, read it and revise if you think there's possibly more than this:
1) stretch game movies - that is avoid game crashing when GDI stretching modes are selected
2) make patched version 1.2 playable
3) test for possible resource leakage (you may hate being crashed in the middle of a long mission!)
4) try to apply 1.1 patch only (on Win10 the installer hangs on a black screen)
5) check for texture dumping & hacking, in case anyone may want to hack the game.
First update (likely Riitaoja already knew, but maybe someone else could be interested):
Patch hgp187d.exe stops in a black window if launched with a double-click of the mouse. Better run a command prompt and run it from there, a dialog box will show and will let you apply the patch.
The patched game is still playable with DxWnd.
Unbelievable! The v1.2 patch problem has nothing to do with ZBUFFERING or whatever.
The programs get caught in an endless loop of FreeLibrary() calls because it expects a 0 return code (as if it were a reference counter!), that is actually an error code. The proper return code should be a not null value, like TRUE, but this is not understood by the program?
I should check if on old OS like Win95/98 the FreeLibrary call had a different retcode meaning.
In any case, this will require a dedicated flag, since setting the FreeLibrary retcode to 0 could impact other programs.
But the game WORKS and has much better graphic effects!!!!
Last edit: gho 2016-10-17
That is very exciting news. I was sure that it was not going to be possible to get the 1.2 version working since it has not worked since the Windows 9x days. Interesting to see how the graphics improve with that version of the game in Direct3d mode!
For the v1.1 (hgp187d.exe) patch on Windows7 it installed without any special tricks. There was a windows registry update error at the end but that may have been due to not running the patcher with admin rights. In any case 1.1 seems to work but it does not do anything very noticable to the game in Direct3D mode. However it does make the 3dfx graphics look slightly better.
Man, you have no faith! Enjoy this fine beta (in attach) that makes the patched release playable. IMO it is really far better than the unpatched release! Please, note the Compat. / "fix FreeLibrary" new flag that is needed to simulate the FreeLibrary behavior of the old glorious days of Win9X!
P.s. the 1.2 patch adds support for 3DFX cards, but if you don't have one you can add a glide2x.dll file to the game folder from any glide wrapper just to avoid a irritating dialog box at game startup.
Last edit: gho 2016-10-17
What's next? Texture management patch!
Last edit: gho 2016-10-17
Much better vfx on v.1.2 compared to 1.0 and you fixed the issue with the window size too!
I think I am going to play this game through. I'm already at mission 5 of the campaign. ;-) I will let you know if I encounter any more issues.
Do not forget bilinear filtering, desktop workarea, keep aspect ratio and, at least on Win7, hide desktop background. Win10 is still giving me some troubles .... ;)
I was wondering if some sort of support for the 3dfx/glide emulation could also be integrated into dxwnd in the future. This is just an idea.
Have you ever looked at the Openglide project here:
https://sourceforge.net/projects/openglide/
There is quite an old version available from 2002 (version 0.08 Final) with source code and I tested it together with Dxwnd and to my suprise it worked. Well there were many graphical errors but at least it did not crash like it does if I use any other wrapper like nGlide or DgVoodoo together with dxwnd.
If you are interested in testing it out download the Release 0.08 Final and place the Glide2x.dll to the Heavy Gear folder. Set the graphics type to 3dfx in the combat variables of heavy gear. Do not use the "Hook Glide libs" flag of dxwnd or it will crash.
Ofcourse the Openglide wrapper is not as good as the nGlide and DgVoodoo wrappers but atleast it could provide some insight into the mysterious world of 3dfx/Glide emulation.
Last edit: Riitaoja 2016-10-18
The idea is very good and is already in my future plans, I simply didn't have enough time to "implement" it. But having a stable and working open source project could be a perfect startup.
Right now I was bumping my head on the seemingly silly problem of the movies: the game seems to use different movie rendering engines (AviPlayer, SmackW32) all deeply buried in layers of dynamically loaded dll, so that DxWnd is getting lost and can't find the hook point to intervene.
It is all a matter of geometry relocation: if you want to enjoy a centered intro movie, enable debug settings and set "FullRECT Blit". The movie will be rendered as it should be, but after that the game will crash!
Last edit: gho 2016-10-18
The intro movie and mission movies are using the Indeo video codec. I think the smackw32 codec is used just for the game menu animations.