Persona 3 FES graphical issue

[GoogleCodeExporter]

Here is two screenshoots made from US version of Persona 3 FES on Windows
machine. It's ZeroGS 0.97.1 (with latest SPUGGZ sound), but in GSDX there
is no difference. First one made in rev 362, second one -- is 396 main
version. I use VM version (for TLB picture the same)

I hope, you could see a little erroneous in playground version. I'v checked
older releases and found, that such behavior first met in 106 revision, and
revision 104 has no this. I could not check revision 105, but 105 is TLB
fix. So I think that it is revision 106, that made P3FES look a little worse.
And rev 106 touch only FPU.c

O'k. I don't check CHECK_FPUCLAMPHACK, so functions void ClampValues(regd)
and void ClampValues2(regd) for me doing the same thing (fpuFloat(regd);).
So only difference I see is in line 1480 was added ClampValues(regd);  --
it's line 1449 in latest revisions.

Other diffs is: 48-53, define that was never used and not in latest rev.
814-849, 870 -- a little cleaning in IF operators (and FPULAMPHACK stuff
which is not in latest rev.) 
861, 920, 986, 998 -- ClampValues2 instead ClampValues
913 -- sysprintf

So I propose to comment check line 1449 and see. But right now I have no
working buildsystem, so I could not try myself.

Original issue reported on code.google.com by Zeydl...@gmail.com on 27 Nov 2008 at 11:56

Attachments:

• snap018.jpg
• snap019.jpg

[GoogleCodeExporter]

Errata. I found, that I was checked CHECK_FPUCLAMPHACK values at old revisions 
-- and
if I am unchecked it version 104 have the same trouble than 106. Even more, I 
found
the reason of that's unwanted behavior -- it's on line 943 in rev 106:

    ClampValues(recCommutativeOp(info, EEREC_D, 1)); 

was not changed to ClampValues2 when 106 applied. Right now this is line 1478. 
If I
change this to ClampValues2 (so it call the same function as in 104), picture 
return
to rev 104 variant. And but there is another way to rule this fucntion -- by 
Disable
extra FPU flags variable. In ver 106 turning ON this flag lead to normal 
picture, but
in ver 343 you should turn OFF this flag. It's little weird and, as I think, 
show
that something is not good in this case.

Original comment by Zeydl...@gmail.com on 28 Nov 2008 at 12:52

[GoogleCodeExporter]

so are you able to get a working picture by messing around with the "Disable 
Extra 
FPU flags variable"?

for now messing around with the hack option is the best way to solve this 
problem.

the real way to solve it, requires exception handling for SSE instructions; but 
this 
isn't implemented yet.

Original comment by cottonvibes on 2 Dec 2008 at 9:54

[GoogleCodeExporter]

Agreed.

Original comment by Zeydl...@gmail.com on 2 Dec 2008 at 10:19

[GoogleCodeExporter]

Setting this to low priority.  It can be circumvented with some speedhack use 
(albeit
inconvenient) for the time being.  It's something we'd like to address in the 
future
but there are still too many other problems with emu stability that need to get
looked at first.

Original comment by Jake.Stine on 7 Dec 2008 at 4:19

• Changed state: Accepted
• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

can you see if the problem is fixed in revision r439, using extra FPU overflow
checking (setting the grey-checkbox for the 2nd speedhack)

Original comment by cottonvibes on 16 Dec 2008 at 8:34

[GoogleCodeExporter]

Yes, if this check box is off or greyed -- this issue resolved.

Original comment by Zeydl...@gmail.com on 16 Dec 2008 at 8:48

[GoogleCodeExporter]

thank you for testing, thats good news then.

Original comment by cottonvibes on 16 Dec 2008 at 7:20

[GoogleCodeExporter]

Original comment by cottonvibes on 19 Dec 2008 at 7:41

• Changed state: Fixed