VOGONS

Common searches


First post, by Anamon

User metadata
Rank Newbie
Rank
Newbie

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?

Reply 1 of 9, by Jorpho

User metadata
Rank l33t++
Rank
l33t++

Powersave mode sometimes involves underclocking the CPU. Perhaps your CPU is too fast for the game? I would suggest WinThrottle, but that hasn't been tested in Windows 7. Another possibility is that you might need to set the game to run on a single core, i.e. changing its affinity. (There are many guides on how to do this.)

Changing VRAM sounds like a job for 3D Analyzer.

Reply 2 of 9, by Anamon

User metadata
Rank Newbie
Rank
Newbie

Thanks for the reply!

I'm not sure anymore whether it's just about the speed. On my desktop, I changed process affinity to one CPU and used Battle Encoder Shirase to selectively slow down just the game's process. It does run and load much more slowly, but after entering the game it only takes about 2 seconds longer before it crashes the same way as before. I'll try and see what other settings the power save mode might change.

I couldn't find an option to hide VRAM from the application in 3D Analyzer, unfortunately. dgVoodoo2 seems to have that option, but choosing a 64MB or 16MB card to be emulated doesn't have an effect, the game still complains "Not enough texture memory on your accelerator."

Reply 3 of 9, by Jorpho

User metadata
Rank l33t++
Rank
l33t++
Anamon wrote:

Battle Encoder Shirase to selectively slow down just the game's process.

An interesting-looking utility, but it seems to me that just controls how much of the CPU a process can use and will not actually slow down the CPU.

Perhaps CPU Killer is worth a shot? Alas, it is not freeware.
http://www.cpukiller.com/whatsnew.html

Reply 4 of 9, by Anamon

User metadata
Rank Newbie
Rank
Newbie

I gave the trial version of Cpukiller3 a go, unfortunately the result is the same as with BES.
Their approaches are different, but I assume their effect is similar – Cpukiller keeps the cores busy so that the target process gets scheduled less frequently, while BES pauses the process periodically to similar effect. (I like the BES approach because it works without slowing down the rest of the system.)

As for actual downclocking the CPU, I don't know if there is an alternative in Windows aside from Windows power settings. I tried setting my max. CPU performance to 5%, but it doesn't seem to have an effect on my desktop CPU. Probably that is the main thing that makes the game work on my laptop.

Reply 5 of 9, by ZellSF

User metadata
Rank l33t
Rank
l33t

About faking VRAM...

As mention, dgVoodoo2 can do it. DxWnd can do it (limit available resources). WineD3D can do it (VideoMemorySize registry entry).

On CPU limiting: it's worth trying DxWnd's options for that.

Reply 6 of 9, by Anamon

User metadata
Rank Newbie
Rank
Newbie

I almost forgot about DxWnd, thanks for reminding me! That thing has grown in features… it'll take a while to go through that documentation.

So, this game really is one non-deterministic botch-up. DxWnd does not help in getting it to accept the video card, but for a moment I thought that just having it hooked with default settings made the software-rendered version run better. It now runs for 10-30 seconds before crashing, as opposed to crashing after the first few frames. However, it turns out that this is now also true without DxWnd (or any other tool). The only things I changed since my attempts yesterday is a system reboot. The game's stability seems to be a mood of the day thing… not sure how to go about figuring out what is triggering or delaying the crashes.

I couldn't figure out how to set memory size for WineD3D for Windows – I used the straight build from "Adolfintel.com" which doesn't create any config files or set up any registry keys.

Reply 7 of 9, by teleguy

User metadata
Rank Member
Rank
Member
Anamon wrote:

I couldn't figure out how to set memory size for WineD3D for Windows – I used the straight build from "Adolfintel.com" which doesn't create any config files or set up any registry keys.

Use this:

Filename
wined3dcfg.zip
File size
25.36 KiB
Downloads
140 downloads
File license
Fair use/fair dealing exception

You can also create the registry keys manually.

https://wiki.winehq.org/Useful_Registry_Keys

Reply 8 of 9, by Anamon

User metadata
Rank Newbie
Rank
Newbie

Thanks!

Unfortunately that didn't fix it, and I now believe that the error message of too little texture memory is false. I noticed that if I choose a lower resolution, the error message changes to one saying that the installed version of DirectX is incompatible. Further, I found a demo version of the game using an earlier build of the engine, and there the error is the incompatible DirectX version regardless of the resolution selected. (The archived game website says that the newer builds fixed compatibility with 3D accelerators.) So the fact that I can't get the D3D version to run on some systems might be a deeper incompatibility.

However, I'm now actually able to play the game in both 3D-accelerated and software modes, on different systems. I already mentioned that the Direct3D version works on my Windows 7 laptop as long as it is in power save mode. I haven't yet checked which setting in particular makes the difference (and which version of DirectX I have installed there), but will update the thread when I do. I also got the Windows XP netbook I remembered the game running on some years back. It's an Asus eeePC with an Intel 945 graphics chipset. I must have remembered wrong that it was the software version that ran on that computer, because it crashes just like on all the others – it's the Direct3D version, too, that works fine using this video card.
The Direct3D version also starts and doesn't crash in VMs with Windows XP on my main computer, both in VMware and Windows XP Mode, but most of the visual elements are missing, so it's unplayable without further fixes.

So to summarise:

  • The Direct3D version works fine on the two systems with slightly older or weaker video chipsets, but cannot seem to be convinced to start on my more up-to-date systems. There seems to be a deeply-rooted incompatibiltiy with newer video cards or drivers somewhere.
  • The software-rendered version crashes immediately after entering the game, with random memory violations and floating point errors, on all systems. Slowing down the CPU or power save mode seemed to be able to delay the crashes for a few seconds, but even that is inconsistent. Power save mode still delays the crash a bit longer on my laptop, but the CPU killer solutions don't currently have any effect at all anymore.

    Curiously, though, I just randomly gave the Windows 98 VM another go at running the game in software mode – and it ran fine! I had no idea why, because I didn't change anything about the VM configuration. However, as I feared, as quickly as it can fix itself it can break again, so the next day it went back to the crashing. I then had the idea to turn off hardware virtualisation, because the floating point errors and power save mode situation reeked of some processor-level instruction set incompatibility. The hardware virtualisation setting was on Automatic before. The day it ran fine, VMware for some reason must have disabled it on its own. So my most likely explanation at this point is that the software rendering code has some incompatibiltiy with newer CPUs that leads to the instability.

Edit: To anyone who wants to get the software version of this game to run in VMware, you'll have to go to your VM's hardware settings, and in the Processors section activate the checkbox Disable acceleration for binary translation. You can turn this on and off even while the VM is running. Only windowed mode will work, I haven't yet figured out how to get fullscreen to work. The game complains that the video mode isn't supported; forcing 16-bit mode didn't help.

Edit 2: If I didn't get it to run on the Win98 VM, I'd have been just about ready to give up on this mess of a game at this point. Now the Direct3D version won't run on my laptop anymore. Power save mode on or off makes no difference, it will not run regardless. It's the same now as the D3D version in virtual Windows XP (rendering one broken frame before crashing). I've played it on this system for about an hour, and absolutely nothing changed, and now I can't convince it to run anymore no matter what I try. If anyone ever figures out what star constellation this game depends on to run, let me know! 😵

Reply 9 of 9, by cameron

User metadata
Rank Newbie
Rank
Newbie

hi anamon, i know i'm super late, but i have an answer for your woes that may work for you.

dgvoodoo is a program that i've been experimenting with a lot to resolve issues with older games. i decided to use it for hard truck: road to victory and did some serious testing with certain options to see where they lead me.

using the 3dfx voodoo wrapper that comes with the program allows me to load up the game and access the main base area, but i couldn't load any other maps; the game gave me memory related errors like the ones you're getting. i had a hunch to look at the truck.ini that sits in the main directory, and one variable in there caught my eye and had me thinking - eff. eff, by default, is defined with a value of 1023. this was a shot in the dark, but i edited the memory value that sets in the 3dfx options for dgvoodoo to match eff's value. lo and behold, i can successfully load other maps, though the game tends to crash with the hardware renderer randomly still; i think that's because softlab-nsk didn't really perfect it.

another important step is to change the compatibility mode of htruck.exe to windows nt 4.0, and to never play with 7 other truck ai's; the game seems to crap itself if there's two of the same trucks on the same map and doesn't know how to handle it