[Soft-Float] - Initial Interpreter Implementation of Ps2's floating point unit specification
This Pull Request implements the first take ever on real Soft-Float support in PCSX2.
This work is a combination or several efforts and researches done prior.
Credits:
-
https://www.gregorygaines.com/blog/emulating-ps2-floating-point-nums-ieee-754-diffs-part-1/
-
https://github.com/assumenothing/Tommunism.SoftFloat/tree/main
-
https://github.com/GitHubProUser67/MultiServer3/blob/main/BackendServices/CastleLibrary/EmotionEngine.Emulator/Ps2Float.cs
-
https://github.com/Goatman13/pcsx2/tree/accurate_int_add_sub
-
PCSX2 Team for their help and support in this massive journey.
This pull request should be tested with every games requiring a clamping/rounding mode/float patches (cf: GameDatabase).
Currently, this PR fixes on the interpreters:
-
https://github.com/PCSX2/pcsx2/issues/5169
-
https://github.com/PCSX2/pcsx2/issues/354
-
https://github.com/PCSX2/pcsx2/issues/11507
-
https://github.com/PCSX2/pcsx2/issues/10519
-
https://github.com/PCSX2/pcsx2/issues/8068
-
https://github.com/PCSX2/pcsx2/issues/7642
-
https://github.com/PCSX2/pcsx2/issues/5257
-
https://github.com/PCSX2/pcsx2/issues/8228
-
https://github.com/PCSX2/pcsx2/issues/8595
-
https://github.com/PCSX2/pcsx2/issues/10885
-
https://github.com/PCSX2/pcsx2/issues/11714
-
https://github.com/PCSX2/pcsx2/issues/5070
-
https://github.com/PCSX2/pcsx2/issues/4546
-
https://github.com/PCSX2/pcsx2/issues/2245
-
https://github.com/PCSX2/pcsx2/issues/11528
-
https://github.com/PCSX2/pcsx2/issues/11507
-
https://github.com/PCSX2/pcsx2/issues/4760
-
https://github.com/PCSX2/pcsx2/issues/9831
-
Gran Turismo 4 license tests
-
Mortal Combat Shaolin Monks
-
Tokyo Xtreme Racer Zero (Accurate Mul/Div for the EE FPU)
Any other games using the NegDiv hack or any other FPU rounding mode.
This sets the floor for Soft-Float in PCSX2, a long awaited contribution.
Does this work on the recompilers or just interpreter?
You should try reading the title.
You should try reading the title.
I don’t know why my brain just skimmed over that.
I ran a bunch of tests for "Test Drive Unlimited" AI during the demo scene after sitting idle on the menu. No combination of settings/interpreters seems to have any effect on behavior. There must be something else going on
I can confirm with the multiplication setting that MHG and Dos not longer have bugged bounces! (Plus the build works on linux well! [as well as running interpreter can do, of course :'D])
Shouldn't this help with #2990 as well?
Shouldn't this help with #2990 as well?
I remember seeing on the public dev channel that stuntman not longer had AI issues with this and not longer the car AI failed? it's been a while
Tourist Trophy NTSC works now too! For the first time License Tests in it work! Requires: EE MUL/DIV
Some of the tests still don't work however.
Works
Hangs
I tested the demo replays of Tokyo Xtreme Racer Zero (see issue #5597 ) and noticed that the car movement in interpreter mode is now closer to the movement in recompiler mode. However, there are still slight differences between the two, and both are far from matching the console playback.
https://github.com/user-attachments/assets/6e7a2b36-309b-4eb8-a32c-9c2b56304280
Nice work!
I tested only 2 games for now. Hype Time Quest which if i remember correctly needs accurate fpu mul, and it works fine without patch.
Second game is THPS4. While here accurate VU1 add/sub fix issue which is normally fixed by VU1 rounding in database, accurate mul/div breaks game graphics. Of course, game don't need accurate VU1 mul/div to work correctly, but something seems to be off when enabled.
Accurate vu1 add/sub/sqrt:
Accurate vu1 mul/div (same place in game):
Edit: Maybe THPS4 is just passing some big float value to GS with accurate mul/div. That may not necessarily be an issue with the float operation itself. Additionally, I tested Burnout 2 and accurate VU1 add/sub fixed issue that was previously fixed by VU1 rounding mode (white car parts).
Edit2: Freaky Flyers is fixed with accurate mul/div on VU1. Awesome! We weren't even sure if that's floating points issue until now.
The Tony Hawk case is fixed, the game uses an un-documented behaviour in it's 3D engine.
The PS2 has no denormals support .... except in the Mul unit apparently.
The behaviour is now emulated properly.
I remember seeing on the public dev channel that stuntman not longer had AI issues with this and not longer the car AI failed? it's been a while
@AmyRoxwell Can you provide a reference to this? There's no indication of it being fixed in #2990, and I assume the devs would have closed it if it were. In any event it involves pathing in Driver 3 as well.
https://github.com/user-attachments/assets/850953b3-4d16-441d-8e24-eae92b417e94
This also affects the Fatal Frame 1 issue. Meaning this + the current GameDB patch will end up being the ultimate fix
https://github.com/PCSX2/pcsx2/issues/3200 is fixed when tested with https://github.com/PCSX2/pcsx2/pull/12001/commits/b7f38061df28c3c620649de2056ecf9c615ed778 Require accurate mul/div for FPU. I didn't tested, but Krome studio games should profit from this pr too, ones that have patches in game db. Like Spyro, Star Wars, one of Transformers game.
This pr's EE interpreter fixes #11636 's gamedb issue.
I remember seeing on the public dev channel that stuntman not longer had AI issues with this and not longer the car AI failed? it's been a while
@AmyRoxwell Can you provide a reference to this? There's no indication of it being fixed in #2990, and I assume the devs would have closed it if it were. In any event it involves pathing in Driver 3 as well.
I meant like, while using this PR, not that is has been fixed. Sorry if it was misunderstood. But if it's not mention on the PR maybe the thing it needs it's not here by this initial implementation.
Driv3r seemed fine when it was tested, Stuntman NTSC is a lot better but still can "slightly" deviate.
I suspect it is once again, the interpreter rounding/clamping values somewhere.
@AmyRoxwell Ah, I understand you now. That's great news.
@GitHubProUser67 Thanks, nice to see Driv3r is looking better. Would it make sense to list these games in your OP?
Nice to hear of stuntman finally faring better nowadays.
Game Constantine, tested US version. On level 2 there is dumpster that we need to climb to progress in game. Recompiler get it fine with positive rounding for EE. This is currently not working with soft floats, no matter what.
Reproduction steps.
- Launch first level of game.
- Use this cheat to skip to level 2:
Press select, go to the Journal Screen, and enter RIGHT, LEFT, RIGHT, LEFT, RIGHT, LEFT, SQUARE, CIRCLE, CIRCLE, SQUARE, SQUARE, SQUARE, SQUARE, CIRCLE, CIRCLE. - Jump thru fence, kill rats, there will be now dumpster on the right side, one that do not work.
I managed to fix it, but the game requires accurate soft floats on the VU0 and the EE FPU, so far I tried with booth Add/Sub and Mul/Div on EE FPU/COP2 and VU0:
Edit: Positive rounding hack-fix it because it makes the float VU0 friendly. In fact the game does some weird EE FPU->VU0 communications with high floats.
Note to future tests:
The constantine case is a typical case of a hack fixing a problem that is related to what I call "float broadcasting".
A game might want to transfer a out of IEEE range float from the FPU to the VUs (and vice-versa).
When a game Database entry has a rounding mode, usually it covers a can of worms where the game requires accurate soft floats on more than one processor.
That's weird. I can't make it work even with both, accurate FPU and accurate VU0, actually that's how i tested it earlier.
You made sure to be on the last revision of the PR? I fixed some functions since.
Edit: You also need to re-load the level, the bad calculation happens at loading time.
Edit: You also need to re-load the level, the bad calculation happens at loading time.
Ok, that was it. I didn't expected it require reloading because changing rounding modes worked without that. My bad.
It's nothing ^^ , diagnosing floats is more tricky than some usual tests, because the wrong calculation can happen way before we even noticed it went wrong.
In the case of constantine, they really seems to pre-calculate a lot of stuff while loading, I guess to save on compute time while ingame.
It's nothing ^^ , diagnosing floats is more tricky than some usual tests, because the wrong calculation can happen way before we even noticed it went wrong.
In the case of constantine, they really seems to pre-calculate a lot of stuff while loading, I guess to save on compute time while ingame.
Normally I'm aware of that, but here they tricked me with working rounding modes after loading. :D
Ok, next test is Tales of Destiny Directors Cut (SLPS-25842), reason why pcsx2 have one of most ugly per game hacks in FPU recompiler. Game works now as intended in interpreter with accurate Mul/Div. Tested in place where FpuMul hack is required in recompiler. Attached card if someone need it, use continue option. Be aware that save is using fast save slot, it will be deleted from memory card after loading one time. Mcd001.zip
Actually I found in my local testing that the game "Virtual On" from the sega ages 2500 series does the same kind of stuff, requires EE Rounding to fix white shadows, on the soft float it requires accurate Mul/Div at game boot.
Dirge of Cerberus (bug is exclusive to SLPM-66271) https://forums.pcsx2.net/Thread-Bug-Report-Dirge-of-Cerberus-Final-Fantasy-VII-NTSC-J-SLPM-66271
Work with accurate VU0 mul/div. Require disabled EE recompiler but not any of accurate fpu modes. Could be that pcsx2 don't fallback to VU0 int on COP2 opcodes when EE recompiler is selected. Not sure if it is worth looking into at this point. Memcard: VMC0.zip Same like Tales of Destiny, game use fast save. After loading one time, it will disappear.
You are right, VU0 soft-float options also affects the COP2, but to enable accurate COP2 you need to disable the EE Recompiler.