[BUG]: Driv3r - Bizarre AI (?) problem: impossible to pass "Lead On Baccus" mission (the 2nd mission)

[terremoth]

Describe the Bug

When you start the 2nd mission, "Lead On Baccus" on Undercover Mode (story mode), you have to follow a police car you are helping. But this friendly police car always go stupidly to a wall or to the sea and crashes and the mission fails. This doesn't happens in the game itself on PS2 hardware. Seems like a bug so I decided to report. There is NO WAY to pass this mission, I tried countless times.

My Nvidia graphics driver updated with the latest version (560.81) at this moment and the energy settings are set to maximum performance.

Let me know if I can help with more information. I would be glad to help!

---

Also another bug spoiler: you will probably notice others very minors graphical issues on rendering distance and buildings textures that doesn't matter now for this issue and do not interfere with the game, but I will eventually report another time if not solved until there. Thanks a lot. You guys are awesome!

Reproduction Steps

• start the game
• choose undercover mode (the story mode)
• pass the 1st mission
• the 2nd mission now will fail when try to follow the friendly police car at some random moment.

you will probably take 15 min of your time to achieve this point.

Expected Behavior

The police friendly car should go correctly to the destiny where you and the other cops will chase "Baccus", the enemy.

PCSX2 Revision

v2.1.92

Operating System

Windows 11

If Linux - Specify Distro

No response

CPU

i5-11400H

GPU

GTX 1650

GS Settings

No response

Emulation Settings

3x upscaling (1080) only

GS Window Screenshots

No response

Logs & Dumps

No response

[CookiePLMonster]

Almost definitely the same class of issues as the ones in Stuntman.

[terremoth]

Oh, I was suspicious that this was a problem with floating points 😮

[seta-san]

This is one of the oldest known issues. It’s a floating point problem. This might be categorized in the never will be fixed pile.

[ghost]

This is one of the oldest known issues. It’s a floating point problem. This might be categorized in the never will be fixed pile.

It will be fixed, but given this needs address-based soft floats it will take a while.

[ghost]

I've tested this on another emulator. The issue is solely with COP2's ADD/SUB.

[F0bes]

I've tested this on another emulator. The issue is solely with COP2's ADD/SUB.

Do you have a source for this?

[ghost]

I've tested this on another emulator. The issue is solely with COP2's ADD/SUB.

Do you have a source for this?

On Sony's PS4 emulator, the issue is completely fixed if you enable the COP2's accurate ADD/SUB option. Every other option I've tried had zero effect.

[ghost]

I ran some tests to compare the two emus on an arbitrary instruction:
Driv3r
SLUS-20587
002A83E4 4BC300E8 vadd.xyz vf03, vf00, vf03
`Instruction: vadd.xyz vf03, vf00, vf03

VF03 W Z Y X
Before :3F800000 BFA2E9C0 408E1E8B 44A1D3FC
After (PCSX2) :3F800000 BFA2E9C0 408E1E8B 44A1D3FC
After (PS4 with disabled accurate add/sub) :3F800000 BFA2E9C0 408E1E8B 44A1D3FC
After (PS4 with enabled accurate add/sub) :3F800000 42FB8722 41B5DACD 44B12BCF

VF00 W Z Y X
Before (PS4 with enabled accurate add/sub) :3F800000 BFA2E9C0 408E1E8B 44A1D3FC
Before (PS4 with disabled accurate add/sub):3F800000 00000000 00000000 00000000
Before (PCSX2) :3F800000 00000000 00000000 00000000
After (PCSX2) :3F800000 00000000 00000000 00000000
After (PS4 with disabled accurate add/sub) :3F800000 00000000 00000000 00000000
After (PS4 with enabled accurate add/sub) :3F800000 42FE12C9 4192532B 42F57D30`

A few notes:

• Values are being set into the VF00 register from outside the EE (typically during lqc2 and vadd etc instructions). However, I can't check if these are facts because the PC register checker irregularly updates.
• VF00's values are being cleared quickly to return back to 1,0,0,0 which makes them hard to detect
• There seems to be a correspondence between VF00's register values and another random register's (Not necessarily VF01's Z, I'm only using it as an example):
  VF01 Z VF00 Z
  C1B402E1 - > C1D3D87E
  407EACEE - > 42FE12C9
  C0B29F52 - > C112947E
  C1B402E1 - > C1B8CA16
  4156F892 - > 41C5AB0C

[terremoth]

🤯😱 meh, awesome

correct me if I am wrong, but now the "hard" part will be discover how to make PCSX2 results exactly the same as the PS4 emulator (or at least, get as close as possible)?

[Goatman13]

VF00 W Z Y X
Before (PS4 with enabled accurate add/sub) :3F800000 BFA2E9C0 408E1E8B 44A1D3FC
Before (PS4 with disabled accurate add/sub):3F800000 00000000 00000000 00000000
Before (PCSX2) :3F800000 00000000 00000000 00000000
After (PCSX2) :3F800000 00000000 00000000 00000000
After (PS4 with disabled accurate add/sub) :3F800000 00000000 00000000 00000000
After (PS4 with enabled accurate add/sub) :3F800000 42FE12C9 4192532B 42F57D30`

vf00 is hardwired to 1.0, 0.0, 0.0, 0.0 on real hardware and there is no way to change its value. Any emulator that allows vf00 change will be really broken.

[seta-san]

vf00 is hardwired to 1.0, 0.0, 0.0, 0.0 on real hardware and there is no way to change its value. Any emulator that allows vf00 change will be really broken.

Undocumented behavior?

[ghost]

@Goatman13 Which means it's either hacking the emulation or behaving in a way we're oblivious to.
If you stick to your guns, then I wish you great luck uncovering why vadd.xyz vf03, vf00, vf03 exists in the game's code, and why it's not changing anything on PCSX2.

[F0bes]

A game can do that to update flags.

[F0bes]

Just hardware tested this and your results don't correlate (as expected) to actual hardware.
The read delay is just the number of NOPS before the SQC2. I wanted to ensure that there was no odd pipelining behaviour.

Start:
    VF00 -> 3F800000 00000000 00000000 00000000
    VF03 -> 3F800000 BFA2E9C0 408E1E8B 44A1D3FC
VADD.xyz $VF03, $VF00, $VF03:
    VF00 -> 3F800000 00000000 00000000 00000000
    VF03 -> 3F800000 BFA2E9C0 408E1E8B 44A1D3FC
Loading the values of VF03 into VF00 and reading (0 cycle read delay)
VADD.xyz $VF00, $VF00, $VF03:
    VF00 -> 3F800000 00000000 00000000 00000000
    VF03 -> 3F800000 BFA2E9C0 408E1E8B 44A1D3FC
Loading the values of VF03 into VF00 and reading (1 cycle read delay)
VADD.xyz $VF00, $VF00, $VF03:
    VF00 -> 3F800000 00000000 00000000 00000000
    VF03 -> 3F800000 BFA2E9C0 408E1E8B 44A1D3FC
Loading the values of VF03 into VF00 and reading (2 cycle read delay)
VADD.xyz $VF00, $VF00, $VF03:
    VF00 -> 3F800000 00000000 00000000 00000000
    VF03 -> 3F800000 BFA2E9C0 408E1E8B 44A1D3FC
Loading the values of VF03 into VF00 and reading (3 cycle read delay)
VADD.xyz $VF00, $VF00, $VF03:
    VF00 -> 3F800000 00000000 00000000 00000000
    VF03 -> 3F800000 BFA2E9C0 408E1E8B 44A1D3FC
Loading the values of VF03 into VF00 and reading (4 cycle read delay)
VADD.xyz $VF00, $VF00, $VF03:
    VF00 -> 3F800000 00000000 00000000 00000000
    VF03 -> 3F800000 BFA2E9C0 408E1E8B 44A1D3FC
Loading the values of VF03 into VF00 and reading (5 cycle read delay)
VADD.xyz $VF00, $VF00, $VF03:
    VF00 -> 3F800000 00000000 00000000 00000000
    VF03 -> 3F800000 BFA2E9C0 408E1E8B 44A1D3FC
Loading the values of VF03 into VF00 and reading (6 cycle read delay)
VADD.xyz $VF00, $VF00, $VF03:
    VF00 -> 3F800000 00000000 00000000 00000000
    VF03 -> 3F800000 BFA2E9C0 408E1E8B 44A1D3FC

VF00 is hardwired to 3F800000 00000000 00000000 00000000 on hardware

[refractionpcsx2]

Correct, VF00 is fixed, it can't be modified, it's there to be a sanity 1.0, 0, 0, 0 that can be relied upon.

Many games use VF00 as a destination for an operation as this will compute the MAC/Status flag but not actually write a result.

[ghost]

Then that emulator must be performing some hacky wacky ambiguous magic, and the mystery continues.

[refractionpcsx2]

The PS4 emulator has limited Soft Float support, which is likely what's fixing it for the game.

[Goatman13]

I implemented accurate add/sub for fpu/vu interpreter here: https://github.com/Goatman13/pcsx2/actions/runs/11350207820
You need to enable "VU Add Hack" in Game Fixes menu to make add/sub accurate. Since pcsx2 uses the same setting for EE and COP2, to make it work on COP2 ("V" opcodes), EE recompiler need to be disabled. This is painfully slow on my PC, so nothing like Driv3r or Stuntman were tested.

For fpu all add/sub opcodes are implemented, for vu only non mul opcodes for now. I tested Tri Ace games and few random games, and nothing is broken, which is good sign.

For VU0/VU1 micro mode respective recompilers need to be disabled in menu, and of course VU Add Hack must be enabled too.

[F0bes]

I'm concerned as to where this code actually came from. This has been discussed before, the Sony PS4 emulator is completely off limits.
Is your branch a derivative work of the PS4 emulator, or did you hardware test this?

[Goatman13]

It is just ported pcsx2 fpu accurate add/sub, from assembly (exactly from iFPU.cpp) to C and then to VU int in that form. Nothing more than pcsx2 codebase was used for that. But if there is still any concern about any part of that code, just remove link or message at all. I didn't wanted to cause any trouble with that link.
This is not hardware tested since there are no plans to pr this code. I made it just to figure out if VU is really using the same quirks as fpu, because it looks like it is.

[F0bes]

Okay, I see now.

[ghost]

@Goatman13 It reaches farther: Edit: I haven't disabled VU0/VU1 recompilers. I've only read Goatman's complete message now. I've only enabled VU add hack and disabled EE recompiler.

However, it still crashes it. I haven't tried enabling EE cache or any other rounding modes. This is the farthest I've ever reached on PCSX2. GJ!