Thanks for the tip IntMD, I just tested it with this setup:
- Windows XP (POSready)
- eduke32-IF-win32-r8044-20190821
- fury.grp + fury.grpinfo + fury.def
- Stellaris_EU4_XP_2.7.1 and your instructions above.

OpenGL Polymost has visual glitches, OpenGL Polymer is too slow, but software mode looks and plays flawless so far. 😀

DosFreak wrote:

If OpenGL works in older versions and not newer versions try going through each build to identify where it broke and then report it mabye it will get fixed.

This one broke OpenGL for me, lots of changes there:
https://dukeworld.com/eduke32/synthesis/20190 … 2/ChangeLog.txt
Desktop + Windows XP + Radeon 6670 - Setup screen works, but OpenGL window fails to initialize and closes. Previous eDuke versions run fine with OpenGL.
Laptop + Windows XP + Intel HD 3000 - Game starts and menu looks fine, but 3D game has serious glitches and slowdowns. Previous eDuke versions run fine with OpenGL.

Hello,

IntMD let me know about your efforts here.

I just bought Ion Fury, and checked it out on my XP x64 workstation. According to Dependency Walker, the only function call that's missing is indeed GetTickCount64(). The PE header already has the proper values for MajorSubsystemVersion and MinorSubsystemVersion as confirmed by CFF Explorer; It's NT 5.2.

I used the x64 port of Oleg Ovcharenko's Stellaris fix that I made with his help, and patched fury_nodrm.exe to redirect the missing call to GetTickCount().

After that, the 64-bit version starts up on my XP x64 machine. I just can't run real tests yet, because I'm working on the machine remotely via RDP+SSH, so there is no 3D. I will test it as soon as I get back home. Will be interesting to see how the engine performs on my machine and if there are any visual glitches with the renderer.

Specs of the test machine:

• CPU: Intel Xeon X5690 hexcore, 3.46GHz
• MCH: Intel X58
• RAM: 48GiB DDR-III
• GPU: nVidia GeForce GTX Titan Black
• OS: Windows XP Professional x64 Edition SP2 (w. Server 2003 patches)

Edit: And here we go...

(Click to enlarge)

This is with OpenGL, and after running around and shooting a bit, I couldn't see any visual glitches at all. But then again, this is the eDuke32 engine the game was shipped with, so I guess that plays a role. In recent years, having bet on XP x64 instead of 32-bit XP really started to pay off. 😉

Bottom line: On XP x64, all you need is to redicrect GetTickCount64() to GetTickCount(), that's all. If there are any other XP x64 users around here who are interested in playing Ion Fury on that platform, I can post a link about how to fix the stock version in this manner (without engine replacement) later.

GrandAdmiralThrawn wrote:

Bottom line: On XP x64, all you need is to redicrect GetTickCount64() to GetTickCount(), that's all. If there are any other XP x64 users around here who are interested in playing Ion Fury on that platform, I can post a link about how to fix the stock version in this manner (without engine replacement) later.

Thanks for adding your observations. Although I don't use XP x64 at the moment it would be nice to have a detailed 'Howto' in this place.

As for my Windows XP x86 OpenGL issues with all the post-march 2019 eDuke releases; I intend to at least file a bug report at duke4.net forums, but manual approval of new accounts is seemingly a lengthy process...

gerwin wrote:

As for my Windows XP x86 OpenGL issues with all the post-march 2019 eDuke releases; I intend to at least file a bug report at duke4.net forums, but manual approval of new accounts is seemingly a lengthy process...

Yeah, I remember, that it took some time, when I registered over there few months ago.

I've written a small article describing the process today. I hope you're ok with external links: [Ion Fury @ XP x64]. Beware, my server can be very slow at times, it's a quad Pentium Pro machine. No ads and no spyware on my site though, I promise.

XP x64 is extremely niche however, so I believe that most people would rather profit from a working 32-bit version... much more portable than my fix, which works on.. uh.. XP x64 and Server 2003 x64. 😉

Can you please provide MD5 of Ion Fury's executable? I would almost bet, that this guide would work on GOG version, since file is called fury_nodrm.exe, and there's no Galaxy.dll anywhere.

Interesting. A lot of "non-Galaxy" versions from GOG still come with said DLL, requiring hacking it to make it work.

MD5 checksum of unmodified fury_nodrm.exe from the 3DRealms store:

1a579d0a0c4e3c7eda4209a18e42462ec *fury_nodrm.exe

The MD5 it's same for GOG version.

Regarding DLL, I would specify it: there isn't any in game folder.

Usually, if it's there, it's right beside the game EXE. For the 3DRealms version, the game consists of just files, no subfolders. The files in the game folder (without the XP fix): fury.def, fury.grp, fury.grpinfo, fury_nodrm.bin, fury_nodrm.exe, gamecontrollerdb.txt, legal.txt. After launch it will also create a fury.log. And that's all.

If the GOG version has the same files, I guess we can assume that the distributions are identical, given that the checksum of fury_nodrm.exe matches.

To verify that, I would need to pirate a stock version of Ion Fury from GOG... not sure if legal, given that I've bought the game from 3DRealms...

Edit: I tried it, having fetched the original GOG installer for the game in the hope that it doesn't count as piracy in my case. 😉 There are a few extra (metadata) files, but no GOG Galaxy DLL, as you said. It appears they didn't link it against that library at all. Also, the GOG offline installers would usually throw the following non-critical error on XP after having completed the installation:

Typical GOG installer error on XP

But this time, there was no such thing. It seems GOG did something to their software to fully restore XP compatibility, maybe?

Anyway, my fix works for the GOG version, that much I can confirm now. I will update my article.

Thanks!

Edit 2: Could it be that the Steam version is the same? I've seen DRM-free games on Steam before, like Ren'Py visual novels or the game "FTL: Faster than Light". Can somebody confirm whether the Steam version comes without DRM? To confirm it, just close Steam, copy the whole game to a different folder, and double-click the game EXE from there. It shouldn't launch Steam, but just the game itself. Also, there shouldn't be any steam_api.dll next to the EXE. If that works, then Ion Fury would indeed be free of DRM and all 3rd party DLLs across all distribution platforms.

dont know why but this game has crazy requirments. even quake 4 didnt have requirements that high. and the visual quality of this game doesnt justify its requirements. its a fantastic game but give the feeling it belongs to my win98se retro pc. some hardcore people are talking about full ms-dos port. i will be happy even with a 32bit exe compatible with versions as old as windows95.

Realistically both MS DOS and win95 compatible versions are nearly impossible.
Also what would be the point, if this game requires at least 1ghz+ Pentium 3 to even crawl. I think one of the devs mentioned that you need Pentium 4 3gnz+ to run it adequately in 800x600.

gerwin wrote:

I intend to at least file a bug report at duke4.net forums, but manual approval of new accounts is seemingly a lengthy process...

My first unverified account was deleted/expired or something. Did a second attempt last thursday, nothing ...

I wonder why the engine is so CPU-hungry though. I mean, this is the Build Engine with eDuke32... So why...

Or is eDuke32 itself this slow these days? Because of that new renderer? Been a while since I've been playing Duke Nuk'em 3D with it, which is why I'm asking.

the game uses a modified eduke32 to run. propably eduke32 is the reason for the high demands. the visuals dont justify the high requirements.
i play duke nukem atomic edition with eduke32 64bit and the cpu-ram-gpu usage is the same as ion fury. eduke is the reason for those insane requirements

Sure it would be nice if it run on 32-bit / XP / 1-core CPUs. But asking the developers to dedicate time to that is unreasonable. The reason Quake 4 had lower system requirements was because it was released in 2005 where being asked to support 32-bit / XP / 1-core CPUs was reasonable.

I'm waiting on eDuke32 to support texture filtering again (it's supposed to be reworked) before playing this.

I just retried it on 32-bit XP, since XP x64 worked so wonderfully. However, I cannot get it to work with 32-bit eDuke32 like DosFreak managed to do. I tried the eduke32_win32_20190820-8043.7z that DosFreak used, and also the latest version of the eDuke32 engine, that's eduke32_win32_20190908-8090.7z at the time of testing.

This is the error I get with both versions tried, not telling me much I fear (Oh, and I don't have any version of Visual Studio installed on that machine):

I tried to push it through a Dependency Walker profiling run, which yields an OOM error. The machine has 2GiB of physical RAM plus 4GiB of swap, more than a single 32-bit user space address window, which is configured as 2GiB for this system, no /3gb /userva=xxxx switches in boot.ini:

Not sure what to make of this. It doesn't matter whether I try OpenGL or software or Polymer OpenGL, it's always the same crash. The latest version of eDuke32 should've been compiled with support for Ion Fury though, no?

Any ideas?

Edit: I tried the same 32-bit versions on XP x64, and there they work. In the context of that OS, the user space window for 32-bit applications should be 4GiB large, as long as they're compiled with the large address awareness flag, as far as I know.

Could this really be an out-of-memory issue? Even with 2GiB of RAM plus 4GiB of swap on that 32-bit machine?

Edit 2: I tried on another XP 32-bit machine with 4GiB of physical RAM. Crashes again. This machine has Visual Studio 6.0 installed, so it prompts me for invoking its debugger. I've been running the release version though. Not sure if running the debug version and trying to actually debug it will yield anything useful.

What else could I try? I don't get why the 32-bit versions works flawlessly on my XP x64 OS, but not on native 32-bit XP...

Unless something has changed very recently then Eduke32 has to be compiled specifically for Ion Fury:

This version has been:
Ion Fury - A new Build Engine game

Can't get that build to work either. When run as-is, it says it's being aborted by Ctrl+C, which seems really bad. Instead, it should complain about GetTickCount64() not being available. So I patched that out (wrapping GetTickCount64() around GetTickCount() using Oleg's Stellaris patch), and after that I get a failed call to the NtCreateFile API. which should never, ever, ever happen.

I will re-try that version on my other 32-bit XP machine tomorrow.

What I do not get is this: You're saying that eDuke32 needs to be compiled specifically for Ion Fury. Ok. But the latest eDuke32 32-bit build works just fine for me, as long as it's being run on a 64-bit OS (XP x64). But it fails horribly on XP 32-bit, just as the build you mentioned did, albeit in different ways.

Can somebody reproduce this (either my result, or DosFreak's result)?! I really want to get this to work on 32-bit XP. If all else fails, I'll just set up a completely clean, new XP 32-bit VM. Not so easy for the physical XP 32-bit machine of course...

GrandAdmiralThrawn wrote:

Can somebody reproduce this (either my result, or DosFreak's result)?! I really want to get this to work on 32-bit XP. If all else fails, I'll just set up a completely clean, new XP 32-bit VM. Not so easy for the physical XP 32-bit machine of course...

I can run eduke32-IF-win32-r8044-20190821 with Ion Fury on both a Laptop and a Desktop system with Win XP SP3 (POSready), but only in software mode. Details in my post from 25-08-2019.

Alright, thank you. I got it to work with eduke32-IF-win32-r8075-20190906.7z (your version seems to have been replaced by this newer one).

In the meantime I have started compiling eDuke32 myself, and I can now produce XP-compatible builds with (I think) no SSE/SSE2 code mixed in. No more GetTickCount64() calls. The problem is just that I'm using Microsoft Visual Studio, and I can't for the love of god figure out where to set the "FURY=1" flag... This seems to be GNU make specific?!

My builds can already run Duke Nuk'em 3D, so all I would need is a way to build this thing for Ion Fury with Visual Studio..