First post, by Anamon
Hi all
I'm currently trying to get to run this Russian truck racing/simulation game, Hard Truck: Road to Victory. It's been released in 1998, was initially designed for DirectX 5, and despite some reports from around the web of people getting it to run on Win7 x64 systems, has been a terrible chore so far.
From testing on a variety of systems and virtual machines, most of the times the result is exactly the same: the Direct3D-accelerated version either complains about a DirectX version mismatch, or claims that there is not enough VRAM available. The software-rendered version crashes upon entering the game, sometimes with a generic memory access violation, but most often with error messages along the lines of:
Internal error, please contact htruck@softlab-nsk.com
(
Fatal error Tue Aug 16 00:32:09 2016
f2pi(): param too large -nan.
_Car_V:get_WheelsForces)
which would suggest that there is some floating point overflow happening somewhere (the "f2pi(): param too large -nan." bit seems to be the same always, while the part below (the calling function?) changes occasionally). I have tested on my main desktop computer (Win7 x64, i7, GTX 970), several virtual machines (VMware Player, VirtualBox, XP Mode) running different guest OS (95, 98, XP), and D3D wrappers (WineD3D, DXGL, dgVoodoo2). The software version always crashed immediately, the Direct3D mode wouldn't be accepted with the stated messages.
So far so unsuccessful. However, while waiting for a friend in Starbucks, I tinkered some more with my laptop (Lenovo T420s, Win7 x64, i7, Intel HD 3000 + NVIDIA NVS 4200M), and suddenly, as long as I forced the system to run the game on the NVIDIA GPU, I could actually get the game to accept setting the Direct3D version, which seemed to play fine! Later at home, though, on the same system, it suddenly wouldn't anymore, draw one buggy frame and then crash like on all the other systems.
I have now found out what was the difference between trying the game in Starbacks vs. at home: I had disabled power save mode in energy settings in the meanwhile, and set the system back to high performance. It turns out that the game, in its D3D version, works only if the laptop is in energy save profile. Even the software version runs a bit better – no more access violations, and the game can actually be played for a few seconds before crashing in the f2pi() call.
Have any of you ever had anything similar, a game running or not running depending on energy settings? If I could find the underlying cause of this, it might help figuring out how to get it to run on other systems.
Note 1: For what it's worth, I remember that many years back, already having trouble trying the play the same game, I finally resorted to playing it on an Asus eeePC netbook running WinXP (I believe I played the software version back then). It seems back then that was the only system I owned that could run the game. So I suspect that it might be down to a race condition, and that it is in fact slower, or slowed-down, systems that are less prone to the crashes. I don't currently have access to that netbook, so I couldn't tell you any more details about its configuration, or try if it still works with the game.
Note 2: That the game accepted the Direct3D setting on my laptop, but claimed my desktop computer had too little VRAM, makes me believe that maybe the 4GB VRAM on my desktop card led to an overflow in the detected memory value. Is there a way to fake a smaller VRAM for legacy applications?