The game uses DirectDraw.

The game has issues running since it was doing some early kind of multiprocessor/multithreading, the implementation which fails heavily on how Windows actually works.

The DxWnd thread you mentioned should have another EXE that can run the game with DDrawCompat

BEEN_Nath_58 wrote on 2025-05-11, 17:37:

The game uses DirectDraw.

The game has issues running since it was doing some early kind of multiprocessor/multithreading, the implementation which fails heavily on how Windows actually works.

The DxWnd thread you mentioned should have another EXE that can run the game with DDrawCompat

Good to see you again, yes I managed to get it working here too, I applied the Shims and did the whole procedure in PCGW with the nervoushammer exe. The result with DDrawCompat is good, however the videos don't scale, there is a constant flicker, the menu sometimes refuses to advance, but the game does not crash, there is also a stutter in the menus and on the mouse, but during the races the game runs normally.
I'm not complaining, the game is much more stable now, anyway I wanted to run it out of curiosity, the DOS version seems basically the same, at least I didn't notice any absurd differences.

Another thing, I receive messages from Dplay before I can enter the game, when I close them the game runs normally.

Use dplayx dll from syswow64 and rename it to dplay.dll

In your driver panel, add support for 320x240 (or 200?) resolution and the video should scale

I was looking at the disassembled code of Windows versions of this game once and I don't think they knew what they were doing...

UCyborg wrote on 2025-05-13, 13:06:

I was looking at the disassembled code of Windows versions of this game once and I don't think they knew what they were doing...

I can believe that.
Very early Direct X game ported from a dos game which itself started as a 3DO game!
Can imagine it's not the most refined code underneath, but its a hell of a game

They complicated things with multi-threading and didn't synchronize them right. Guess it works on Win9x on slow hardware due to timing adding up. As we know, single core CPUs can't run things in parallel and even when forced on one core on newer CPUs, I suppose how much time each thread runs is still a factor. There's a probably a lot of newer games that didn't make thing complicated this way (how much of your older games put significant load on more than one core?). I think subject of parallelization is difficult as it is and that was mid 90s. Some games would make another thread for some trivial task, though no idea how often.

Not the expert, just sometimes able to put some some smaller pieces together.

The installer was equally bad, INSTALLD.EXE. Seems to be the same issue

This game has memory management / heap bugs too. 😁 Messing with the EXE on my fresh 32-bit XP install, if I don't add EmulateHeap via Compatibility Administrator, CreateFileA fails with ERROR_PATH_NOT_FOUND when opening nfs.cfg file.

nervoushammer's EXE and a couple of workarounds provided by DxWnd also work quite well for me on Win11 23H2 and the old XP with NVIDIA drivers on Win11 being from the time of release of that OS, at least with forced windowed mode, workarounds being Win9x heap, faking RAM amount, disk space, fixing buffered I/O I, single core affinity, pretending to be Win95 (the Win95 faking probably isn't really necessary, there's one obscure call to GetVersion that perhaps wasn't even put in by developers, but by compiler alone).

Actually, the DOS version also works quite well in DOSBox (actually, 'been messing with DOSBox-X recently, specifically), even on my dinosaur CPU (AMD Phenom II X4 920 clocked at 3 GHz from stock 2,8 GHz). Perhaps it is quite well optimized, visuals do strike me as impressive for its time. Maybe I got the wrong impression that all late DOS games are super demanding, my impression being skewed by Terminator: SkyNET and Quake, both in 640x480.

One oddity on Windows version, it likes putting mouse cursor on the other screen during certain menu transitions (I know cursor can be locked to the window, though I like it being free in general).

BEEN_Nath_58 wrote on 2025-05-12, 11:30:

Use dplayx dll from syswow64 and rename it to dplay.dll

In your driver panel, add support for 320x240 (or 200?) resolution and the video should scale

I was able to test it in the last few days, it worked better with native dplay.dll.
As usual, I tested it on a Windows 8.1 and Windows 10 guest VM, in both the game crashes when starting the race when using DDrawCompat, with DXWND there seems to be a strange frameskip, using the exported preset or building my own.
Anyway, VMs are not in the scope of Wrappers, unfortunately Windows 24H2 implemented more changes that are breaking games again, GTA San Andreas and the Sid Meier's Alpha Centaur expansion, luckily both have already been fixed, but I can't help but think about the huge amount of games that don't have a community large enough to care about fixing them, Microsoft on the other hand doesn't care at all and I don't expect any kind of fix from them. I'm simply going to stop stressing about Windows 11 updates and go back to 10, at least while there is compatible hardware on the market to enjoy my games.

UCyborg wrote on 2025-05-20, 06:40:

nervoushammer's EXE and a couple of workarounds provided by DxWnd also work quite well for me on Win11 23H2 and the old XP with NVIDIA drivers on Win11 being from the time of release of that OS, at least with forced windowed mode, workarounds being Win9x heap, faking RAM amount, disk space, fixing buffered I/O I, single core affinity, pretending to be Win95 (the Win95 faking probably isn't really necessary, there's one obscure call to GetVersion that perhaps wasn't even put in by developers, but by compiler alone).

Actually, the DOS version also works quite well in DOSBox (actually, 'been messing with DOSBox-X recently, specifically), even on my dinosaur CPU (AMD Phenom II X4 920 clocked at 3 GHz from stock 2,8 GHz). Perhaps it is quite well optimized, visuals do strike me as impressive for its time. Maybe I got the wrong impression that all late DOS games are super demanding, my impression being skewed by Terminator: SkyNET and Quake, both in 640x480.

One oddity on Windows version, it likes putting mouse cursor on the other screen during certain menu transitions (I know cursor can be locked to the window, though I like it being free in general).

Some time ago I tried this game in DOSBox-X with Windows 98 and it worked fine on my i5 3570 (3.4 Ghz, 3.7 Ghz Turbo), but many years ago I tested it in DOSBox 0.74-3 and it worked like a charm on i3 2100 (3.1 Ghz).
Good old days when my second-generation i3 and Intel HD 2000 were enough to run basically all my retro games on Windows 7 64

Eventually, one has to get familiar with hacking game executables. 😜

BTW, what works better with old dplay.dll vs newer dplayx.dll? AFAIK, newer DLL is binary compatible, it extends possibilities - connection types for multiplayer. Haven't experimented with NFS yet, unless you launch multiplayer component, it shouldn't matter.

With DOOM 95 for example, dplayx.dll adds possibility to play over the usual TCP/IP, the newer DLL works there, even though it links to old one. You can host game on one computer and join from the other.

That's the screen from Win10 1809.

This one's from Win11 23H2:

Did MS screw up translations?

I have Slovenian Win11 23H2 and English Win10 1809. In cases like these, it should fall back English translations. Haven't dug into whether fallback is the problem or English translations are missing.