FX506 wrote on 2025-11-19, 21:35:

So this is an odd question but I would be glad if someone could help me with it. […]
Show full quote

So this is an odd question but I would be glad if someone could help me with it.

I've been playing Aquanox 2 and I noticed that the graphics settings have a multithreading option that supposedly improves rendering speed, but it seems to be tied to having a Pentinum 4 with HyperThreading support. Now, as far as I am aware, there isn't any difference between a modern AMD cpu's SMT ability and Hyperthreading, altough I have also seen games where it does not play nice with the former, specifically Colin McRae Rally 04 and 2005 which have an Advanced Particle rendering that is also tied to P4 HT, but it can be forced on any cpu with a command line flag, at the cost of CPU usage maxing out for some reason on (modern, smt supporting) AMD cpus, but not on Intel ones. Sadly, Aquanox 2 doesn't have any such flags for forcing multithreading, but I'm curious if it could be done to see if there is extra some performance to be squeezed out of the game engine (it is one of those dx9 games that seems to run slightly worse on AMD gpus as opposed to Nvidia ones). As far as I know, the game specifically looks for a P4 HT, just having an Intel cpu isn't enough for the game to detect support. Does anyone know of some kind of trick to fake the CPUIDs for the game, since there are similar solutions out there for GPUs (dgvoodoo2's ability to fake gpu device id's for compatibility).

Thanks in advance.
Edit: I did read that CPUID spoofing isn't something that can be easily done without a VM (if at all), but I'm curious if someone could suggest a workaround at least.

My Phenom II Tweaker definitely works on AMD Phenoms but you can try the fake CPUID part since it relies on AMD virtualization that should be supported even on later AMD CPUs.

https://falcosoft.hu/softwares.html#phenom2_tweaker

https://falcosoft.hu/phenomtwkr_boot.zip

As long as it's only one title, patching the check in the exe seemed a lot easier to me so I had a peek at the English demo (it's all I had on hand) and it's indeed looking for cpu family 0x0f, Netburst - Got an Intel but something more recent, well flick you. Wonder whether the GOG/Steam versions retain that behavior... Anyways, to change that entire checking subroutine to always return true: Open the exe in a hex editor, and starting at offset 0x2715f0, change 55,8b,ec,6a,ff,68 to b8,01,00,00,00,c3. Let me know how that works out for you and if you notice any performance gains.

elszgensa wrote on 2025-11-20, 03:14:

As long as it's only one title, patching the check in the exe seemed a lot easier to me so I had a peek at the English demo (it's all I had on hand) and it's indeed looking for cpu family 0x0f, Netburst - Got an Intel but something more recent, well flick you. Wonder whether the GOG/Steam versions retain that behavior... Anyways, to change that entire checking subroutine to always return true: Open "AquaNox 2 Revelation Demo.exe" (3878912 bytes, md5sum: cf98f69bc8f074b084d3c24471b05946) in a hex editor, and starting at offset 0x2715f0, change 55,8b,ec,6a,ff,68 to b8,01,00,00,00,c3. Let me know how that works out for you and, if it works, if you notice any performance gains.

The fact that you can even figure this out boggles my mind.

Can you describe what software I'd need and where I can go to learn the process you used to do this? I am not a programmer, but tampering with existing programs to make them do what I want is something I've been doing forever... just through editing plain text config files, registry entries, and other things. I've never gotten to the level of opening up an executable and understanding how to modify something specific in a hex editor.

Well, the hex editor is only for when you already know what to change. To understand what's going on in the first place, you want either a disassembler (parses an exe or dll and does its best to turn it into readable assembly code; examples: Hopper (the one I used here), Ghidra, IDA, radare2) or a debugger (looks at a running program's memory and can change both code as well as live data at runtime; examples: Ollydbg, Windbg). Both options require at least basic Assembly knowledge though. You then look for anything interesting going on (like IsProcessorFeaturePresent calls to Windows, or "cpuid" instructions being executed), figure out the logic immediately surrounding those places, and usually you end up with a rather small change like e.g. change a "jump if check passed" instruction to "jump always". Map that change to a location in the exe (most tools will straight up tell you), and only then do you break out the hex editor.

elszgensa wrote on 2025-11-20, 03:34:

Well, the hex editor is only for when you already know what to change. To understand what's going on in the first place, you want either a disassembler (parses an exe or dll and does its best to turn it into readable assembly code; examples: Hopper (the one I used here), Ghidra, IDA, radare2) or a debugger (looks at a running program's memory and can change both code as well as live data at runtime; examples: Ollydbg, Windbg). Both options require at least basic Assembly knowledge though. You then look for anything interesting going on (like IsProcessorFeaturePresent calls to Windows, or "cpuid" instructions being executed), figure out the logic immediately surrounding those places, and usually you end up with a rather small change like e.g. change a "jump if check passed" instruction to "jump always". Map that change to a location in the exe (most tools will straight up tell you), and only then do you break out the hex editor.

Thanks for the explanation. I figured disassembly would be involved before any hex editing could occur, I just don't know anything about how that works.

Without taking up a bunch of your time, what would you say would be the main aspects of assembly that a person would need to understand to make use of these programs? I see Ghidra is free, so I'm willing to learn enough to dabble. 😀

(Not asking you to explain it all to me of course, just a few topics that I could read up on to see if it clicks with my brain.)

not the best time for me to put together a crash course... but here goes anyways.

some basic thing you'll definitely need are:
1. how data gets moved around into or between registers, memory locations, addresses of memory locations. you need this to keep track of what's where at any given point.
2. branching: how to compare two things (or check other basic conditions), and then jump to different places in the code depending on the outcome.
^ those two are very basic, should be covered by any assembly tutorial.
3. building on 1, how do functions get called, and how do they return a result. the specifics might change depending on the language the program was originally written in, but you want an idea of "okay so this function takes three values stored in these locations, and its result gets stored over there".

combining this should lead you to reasoning along the lines of:
- so there's a call to GetDriveTypeA, passing it a drive letter.
- the result gets stored here and compared to 5, which the documentation tells me is "DRIVE_CDROM". smells like a cd check.
- if it is not five then we jump to a block that stores 0 and returns, or otherwise, to one storing 1 and returning.
- so i can either change the jump to always go to the "return 1" path, or change the value being stored in the "0" path to also be "1" instead.
- the code now no longer cares whether that drive is a cd or something else.

HT isn't 100% SMT. I have a highly parallel commercial 3D renderer software that crashes on AMD+SMT enabled but not with Intel+HT. If I disable SMT then it doesn't crash anymore, but of course it doesn't perform as well as it could... Not sure exactly where the differences are, and a game from the P4-era would probably hardly be as CPU-intensive as an offline 3D renderer.

elszgensa wrote on 2025-11-20, 04:37:

not the best time for me to put together a crash course... but here goes anyways. […]
Show full quote

not the best time for me to put together a crash course... but here goes anyways.

some basic thing you'll definitely need are:
1. how data gets moved around into or between registers, memory locations, addresses of memory locations. you need this to keep track of what's where at any given point.
2. branching: how to compare two things (or check other basic conditions), and then jump to different places in the code depending on the outcome.
^ those two are very basic, should be covered by any assembly tutorial.
3. building on 1, how do functions get called, and how do they return a result. the specifics might change depending on the language the program was originally written in, but you want an idea of "okay so this function takes three values stored in these locations, and its result gets stored over there".

combining this should lead you to reasoning along the lines of:
- so there's a call to GetDriveTypeA, passing it a drive letter.
- the result gets stored here and compared to 5, which the documentation tells me is "DRIVE_CDROM". smells like a cd check.
- if it is not five then we jump to a block that stores 0 and returns, or otherwise, to one storing 1 and returning.
- so i can either change the jump to always go to the "return 1" path, or change the value being stored in the "0" path to also be "1" instead.
- the code now no longer cares whether that drive is a cd or something else.

That is awesome. I will definitely have to do some reading on this subject. Sounds like something I could probably do, and I tinker with enough old programs trying to make old hardware work that it could really come in handy.

Thank you for taking the time to explain that.

(And sorry for going a bit OT. 🙂)

elszgensa wrote on 2025-11-20, 03:14:

As long as it's only one title, patching the check in the exe seemed a lot easier to me so I had a peek at the English demo (it's all I had on hand) and it's indeed looking for cpu family 0x0f, Netburst - Got an Intel but something more recent, well flick you. Wonder whether the GOG/Steam versions retain that behavior... Anyways, to change that entire checking subroutine to always return true: Open the exe in a hex editor, and starting at offset 0x2715f0, change 55,8b,ec,6a,ff,68 to b8,01,00,00,00,c3. Let me know how that works out for you and if you notice any performance gains.

The values you mentioned do appear in the GOG version, but not at that exact address and there are three of them actually. Editing the 1st value corrupts the exe and the other ones don't do anything. I could maybe send you my exe, but I am not sure how well that fits with the forum's rules.

Edit: I did test the demo, and there isn't really any significant gains with it on, so it's not that important in the end. But at least there are no crashes or anomalies when HT support is enabled with hex editing. I guess the lower performance of the game with andAMD gpu is just poor driver optimization in general, and not a threading issue (Nvidia cards/drivers seem to perform better with old, single threaded games in my experience).

No difference, huh? That's too bad. I still did the full version regardless, maybe it'll help on other hardware (like, newer than Netburst but still vintage). Can't hurt to at least have the option to try, right?

I'm looking at the GOG version ("setup_aquanox_2_revelation_2.159_(21998).exe"). No clue if this matches the Steam release. The small exe is just a loader, the actual game code is in AN2.dat (3883008 bytes, md5sum c36d6b47f4033ac50c6d8ad0fea819b1). Starting at offset 0x272520, put in the same "b8 01 00 00 00 c3" sequence as before.

elszgensa wrote on 2025-11-20, 14:24:

No difference, huh? That's too bad. I still did the full version regardless, maybe it'll help on other hardware (like, newer than Netburst but still vintage). Can't hurt to at least have the option to try, right?

I'm looking at the GOG version ("setup_aquanox_2_revelation_2.159_(21998).exe"). No clue if this matches the Steam release. The small exe is just a loader, the actual game code is in AN2.dat (3883008 bytes, md5sum c36d6b47f4033ac50c6d8ad0fea819b1). Starting at offset 0x272520, put in the same "b8 01 00 00 00 c3" sequence as before.

Oh, so that's why the demo doesn't have that file! In retrospect, it also makes sense why a widescreen fov fix I found that game also involved replacing that file (I assumed that it was some kind of resource file) and not the exe. Many thanks for taking your time to help me!

Edit: as a side note, I just noticed that the game actually adds a Pentium 4 splash screen at startup if the check is hacked to always pass (or if you have an actual P4 with HT, I suppose)