Duplicate: Phantasy Star Universe (NTSC-U) - Chapter 7 Boss stuckness

[Ryudo]

This is an old bug report of mine that was never fixed. There's a workaround for it luckily, but still think this is worthy of posting.


Game Title: Phantasy Star Universe
Region: NTSC-U
Region ID: SLUS 21194
Game CRC: 29B44F89
_________________________________________

Bugs & Notes:
Enemies stop moving. This is a major issue in Chapter 7 particularly, where you have to fight a boss that's initially invisible. Because of this bug he will stay invisible and you'll be unable to progress. Make sure you have or create a regular Memory Card Save before reaching this point, or you will have to start over the game, because Save States save this bug. So if you saved state during the boss fight without having a normal Save you're screwed.

Possible work-around / Temporary fix:
Needs EE Round Mode set to Positive. But as previously mentioned; You will need to do a clean boot of the game and load via a normal Memory Card Save.

Video / Screenshot Example (If available):


PCSX2 Info & Plugins:
Version: GIT 1.3.1-10
Plugins:

• GSdx AVX2
  
  • Renderer: D3D11 HW @ 2560x1440
    
  • Enable FXAA: On
    
  • Texture Filtering: Half-checked
  
  
• LilyPad 0.11.0
  
• SPU2-X
  
  • Module: XAudio2
    
  • Latency: 150ms
    
  • Sync Mode: TimeStretch
  
  
• cdvdGigaherz 0.9.0

Speedhacks:

• EE Cyclerate: 1
  
• VU Cycle Stealing: 0
  
• mVU Flag Hack & MTVU: Enabled

Emulog (If required):

Code:

N/A

[Bositman]

Good report although this isn't a bug per se, we know that many games need different round modes to work and can't 'unify' that anyway (AFAIK) that's why we have these options. But it's still good info to know

[Blyss Sarania]

Couldn't it become an automatic gamefix though?

[Bositman]

Sure if we can confirm the EE round mode set to positive doesn't affect the game otherwise

[Blyss Sarania]

Yeah of course.

Off topic, but that reminds me of http://forums.pcsx2.net/Thread-About-the...eindex-dbf which could be fixed the same way, and I can confirm that the negative EE rounding causes no problems otherwise.

Again sorry for the off topic, but it's relevant to that at least.

[Ryudo]

Sure if we can confirm the EE round mode set to positive doesn't affect the game otherwise

I can probably start at Chapter 1 again for a bit to see if it affects things in the game. It'd likely be later this weekend before I can give you the full result though, because I'm somewhat busy this week so I don't have a lot of time to play the game from start to finish.

And yup I know it isn't exactly a 'bug' per se, but since it's a potential game run killer, forcing you having to restart the entire game if you don't have a proper Save (especially the people that use Save States) it was probably worth mentioning. And I was hoping that maybe there could be somewhat of a permanent fix made for it. (Like an Automatic Gamefix as mentioned).

But yeah, I'll get to testing this later for sure.

[rama]

Ryudo: It's good enough if you continue (maybe finish?) the game with EE rounding set to positive from now on.
What really counts when testing these things is the time spent playing the game.
If you start from chapter one again, it's pretty likely you'll get bored in chapter 2 and drop it

[karasuhebi]

Good report although this isn't a bug per se, we know that many games need different round modes to work and can't 'unify' that anyway (AFAIK) that's why we have these options. But it's still good info to know

It's still showcases a bug in the emulated EE's floating point precision, which I believe is useful to keep track of. Specially the moment in the game where it happens. That way if someone decides to do a new EE recompiler (or fix the current one), we have a list of known games (and specific scenes in those games) where we can check to see if the floating point math is being emulated with enough precision.

Same goes for games that require VU clamping and round mode changes.

[Blyss Sarania]

It's still showcases a bug in the emulated EE's floating point precision, which I believe is useful to keep track of. Specially the moment in the game where it happens. That way if someone decides to do a new EE recompiler (or fix the current one), we have a list of known games (and specific scenes in those games) where we can check to see if the floating point math is being emulated with enough precision.

Same goes for games that require VU clamping and round mode changes.

It may not be a "bug." The PS2 handles floating point numbers very differently than a PC(such as NaN and infinity being actual, representable values), and it's basically impossible to emulate that exactly. That's why we have the rounding and clamping modes in the first place.

[karasuhebi]

So what happens when a game comes along that requires a certain clamping or round mode to fix an error in a scene and then a certain OTHER clamping or round mode to fix another scene? How is an automatic game fix going to handle that?

Are you saying that there will never be a point where PCSX2 is 100% accurate without looking for these problematic formulas in the game code and making fixes for them by using x86 implementations?