Open hrydgard opened 2 years ago
-[Unknown]
I reported it before but I will post it here as well for sake of being on 1 place. Metal Slug XX got a graphical texture issue in combat school: https://github.com/hrydgard/ppsspp/issues/15755
Socom NavySeals Fireteam Bravo 3
NPJG90068_0001.zip NPJG90068_0002.zip NPJG90068_0003.zip NPJG90068_0004.zip
Prince of Persia - Rival Swords (USA) (En,Fr,Es) (v1.01) ULUS10240_0001.ppdmp.ZIP ULUS10240_0002.ppdmp.ZIP ULUS10240_0003.ppdmp.ZIP
here is one for DTM Race Driver 2 ULES00041_0001.zip ULES00041_0002.zip
These are the same clipping inversion indeed, at 147/726 and 134/673 respectively. Didn't check which direction w goes.
Socom NavySeals Fireteam Bravo 3
Looking at the first one, it looks really good up to the very end:
Compare to expected output:
You can tell it's just missing the final bloom and post-processing. This is right before 5803/5809.
But then it does a self-texture 0x04044000 -> 0x04044000, which is a bit strange. The framebuffer is 5551, but it textures from itself as CLUT8 1024x512, with a grayscale ramp and even color doubling. It does this with a src.a + ONE blend, but the alpha is fixed at FF, so it just ends up adding the ramp. There's no CLUT format mask or anything - but it does start at U=1, so I'd guess it's going after the G2B5A1 bits.
Here's the current translated result:
Naturally, it does the same basic thing on the other side as well. It comes out a bit better, which might indicate some rounding issue (although the verts are pretty even and it's throughmode.)
But... as we can see, the PSP rendering was okay and even brightened effectively. That's clearly the intended plan here.
Hardware doesn't even try: CLUT8 fb_format not matching framebuffer of format 5551 at 04044000/512. So it's actually incorrect and missing the bloom.
The palette repeats the ramp for 128 pixels, twice, which could've been accomplished more efficiently with mask 0x7F. Changing the mask to 0x1F (I guess mapping to R if it's off by one) looks decent:
This isn't correctly bloomed, though. So it must be getting the X off. For posterity, an edited framedump with flags so the bloom is not copied to memory as a texture:
#16131_NPJG90068_socom3_bloom_edit.zip
These have the same thing going on.
-[Unknown]
Prince of Persia - Rival Swords (USA) (En,Fr,Es) (v1.01) ULUS10240_0001.ppdmp.ZIP ULUS10240_0002.ppdmp.ZIP ULUS10240_0003.ppdmp.ZIP
This actually looks okay, in the frame dump? It's slow, though.
It does a self-render at 13132/13292, which uses a blend ONE + ZERO to modulate the pixels. Could allow threading on this since pixels are 1:1, would be a good optimization. Maybe could auto-disable linear or even bypass sampler for simple in-place bloom like this.
Anyway, before:
After:
Which works out fine. Next we use a red clut ramp + CLUT32 + RGB mask to adjust the red color further. And so on with green and blue. The result:
This all works fine, but four 480x272 draws with linear sampling and no threading take their toll. If I set the prim filter to "1-13131,13136-13292", the color is wrong but speed improves from ~60% -> ~70% (16% improvement.) The smoke/fire effects also take their toll, as it's a lot of linear filtering.
I actually have this game, though (forgot I got it and Silent Hill a few years ago.) Looking at the intro, I see some weird things happening around fire. The frame dumps have yellow boxes under them, and this does happen in the PSP rendering as well. But I don't think the wierd flickering boxes are right.
I captured a frame dump of the flickering specifically (also nuked the bloom texture copying to reduce the dump size): #16131_ULUS10240_persia_rival_fire1_edit.zip
But... it actually shows the weird line on the PSP?
It's hard for me to believe this actually shows in game. It comes from an odd draw, specifically at 14573/15499. The positions are a square, but the UVs are garbage - first vert has insanely high UVs, the others have zero. Even hardware rendering has these glitches, though. I hope this isn't some dcache issue. It seems like there's actually just a pointer written there, which gets interpreted as UV...
Actually not a pointer, it's written uncached by this to 0842d8cc:
sv.s S221,0(s1)
Although 09fbf6a0 looks more like a pointer than a float... it's nearly zero if it's a float. It's read from 09fbf884 (which... looks a lot like the previous "float" pointer...) That's stack, and when it's reading it sp=09fbf5f0, fp=09fbf7d0. Seems like 08B89920 writes it, but it's sw v1,0xB4(fp)
... maybe a previous run of the same func. I wonder if some HLE func it's calling should be writing some bytes to stack and overwriting it.... doesn't seem like there's HLE between the two.
It's just an lv.q + sv.s, no manipulation between. Hm, the value comes from 09FBF57C, which is also stack. That happens at 0882c3a0. But there's still no HLE after that, on that thread... strange.
-[Unknown]
~~Resistance Retribution fire and smoke incorrect UCUS98668_0001.ppdmp.ZIP UCUS98668_0002.ppdmp.ZIP UCUS98668_0003.ppdmp.ZIP~~ UCUS98668_0004.ppdmp.ZIP (ammo lines are still an issue)
~~77 - Beyond the Milky Way (Japan) (v1.01) lines are going through the screen through the characters. ULJM05877_0001.ppdmp.ZIP ULJM05877_0002.ppdmp.ZIP ULJM05877_0003.ppdmp.ZIP~~
Resistance Retribution fire and smoke incorrect UCUS98668_0001.ppdmp.ZIP UCUS98668_0002.ppdmp.ZIP UCUS98668_0003.ppdmp.ZIP UCUS98668_0004.ppdmp.ZIP
These are very interesting in hardware and in software. Here's a grid of how they look, correct on left, software in middle, and Vulkan on the right.
The most immediately apparent issue is that smoke seems to be rendering at half the width it should in many cases - software only. However, the ammo bar is also visually solid on softgpu and Vulkan. There's also some smoke in the fourth example that only shows in Vulkan. And curiously, the first example has smoke in the top right that looks larger (and honestly, better) in Vulkan than it should. Mysteriously, that smoke is not half width on softgpu.
Focusing first on the ammo bar, it's drawn at 4458/4504 which is solid. 4460/4504 is what draws the lines between. It doesn't draw because of a depth test failure.... interesting.
Prior to 4451/4504, the depth there is simply zero. The draw renders the background of the ammo box, and sets 356,254 to 62028 using transform. 4458/4504 draws the solid color, also using transform. The input value is -0.0
, which transforms to -1.0
pre-viewport. Viewport transform is z * -32767.5 + 32767.5
, which is straight-forwardly 65535.
The grid draw at 4460/4504 then uses >=
depth testing (they all do), and an inefficient lattice of triangles to draw the grid. It's again transform, but the original Z is now 4.625
and the matrices are more complex (but why?) for this grid. We transform (z (4.625) * -0.507797 + 2.348294) * 0.002 + -1.0
which by my math is about -1.00000053425
(about 9 parts of 2^24 more than 1.) This should transform identically to 65535, since the viewport is the same.
However, it doesn't, and I think it's because of the float inaccuracy, perhaps. We end up with a depth of 65534, which doesn't pass the depth test. In Vulkan, it calculates 65534.992188 in software transform. Might be solvable with some better rounding...
-[Unknown]
-[Unknown]
Gran Turismo (USA) (En,Fr,Es) the background is continually flickering on any race track i dont know if this picked up anything in the dump (the grid lines kept on flickering ) UCUS98632_0002.zip
Hey bender, thanks for all the testing! If you have time, could you attach screenshots with the dumps too?
ok
Fast and The Furious, The (USA) (v1.01) missing the green road signs from the top of the screen ULUS10198_0001.zip here is a pic from my psp
Ratchet & Clank - Size Matters (USA) (En,Fr,De,Es,It) (v1.01) when they are near a waterfall the graphics are a bit corrupt UCUS98633_0001.ppdmp.ZIP UCUS98633_0003.ppdmp.ZIP
Lara Croft Tomb Raider - Legend (USA) (v1.02) title screen and menu screen keeps flickering really badly (couldn't get a GE dump)
Syphon Filter - Dark Mirror (USA) (v1.01) fire and smoke is wrong (On side of building and from silo) UCUS98641_0001.ppdmp.ZIP UCUS98641_0002.ppdmp.ZIP UCUS98641_0003.ppdmp.ZIP UCUS98641_0004.ppdmp.ZIP UCUS98641_0005.ppdmp.ZIP UCUS98641_0006.ppdmp.ZIP UCUS98641_00011.ppdmp.ZIP UCUS98641_00012.ppdmp.ZIP
https://www.youtube.com/watch?v=irowkHNRzdA&ab_channel=shockwave981 if you look at 5:16 and 6:05 you will see it right
MotorStorm - Arctic Edge (USA) (En,Fr,De,Es,It,Nl,Pt,Ru) wrong shadows UCUS98743_0001.ppdmp.ZIP
here is a GE dump from the EU version which doesn't have the same problem UCES01250_0001.ppdmp.ZIP
Gran Turismo (USA) (En,Fr,Es) the background is continually flickering on any race track i dont know if this picked up anything in the dump (the grid lines kept on flickering ) UCUS98632_0002.zip
This sounds like the known thing in the game where it intentionally flickers unless you set it to video output mode inside the game's settings. Actual PSP refresh rates were slow enough, this just gave a blur effect that made it seem like you were really gunning it.
There's something wrong on the PSP with reading the framedump, because I get this:
That's obviously wrong, though. Software renders (the lines of the street are the same):
There are some interesting things happening in this frame dump, though.
Rasterizer::ComputeRasterizerState()
(that's a ton, maybe time to narrow dirtying? most of this is in the func cache lookups.)ComputeSamplerID()
takes ~2% time, ComputePixelFuncID()
takes ~1.3%.-[Unknown]
-[Unknown]
Fast and The Furious, The (USA) (v1.01) missing the green road signs from the top of the screen ULUS10198_0001.zip
The frame dump doesn't render with any signs up there either on a PSP:
I also don't see any sign of rendering there. This must be either something that doesn't happen every time, or that a CPU or similar bug.
Ratchet & Clank - Size Matters (USA) (En,Fr,De,Es,It) (v1.01) when they are near a waterfall the graphics are a bit corrupt UCUS98633_0001.ppdmp.ZIP UCUS98633_0003.ppdmp.ZIP
Correct rendering of first one:
The issue here is relying on the depth swizzle. At 2965/2978 it textures from 0x04710000 to 0x04154000, and then manually deswizzles at 2966/2978 to 0x04164000. If I redirect 2965 directly to 0x04164000 and skip 2966, it looks as it should:
Since this is straight texturing both times, in theory we could apply the swizzle to 2965, although ultimately I think the right way is to write depth to the correct bytes and swizzle on read (would still be 2965.) Silent Hill needs that as well.
Lara Croft Tomb Raider - Legend (USA) (v1.02) title screen and menu screen keeps flickering really badly
Syphon Filter - Dark Mirror (USA) (v1.01) fire and smoke is wrong (On side of building and from silo)
The shadows in especially frame dump 8 look terrible, even on a PSP:
The YouTube video shows much nicer looking fire, so I wonder if there's something this frame dump didn't capture?
The first fire there is drawn at 4760/5060, using various overlapping rectangles + color doubling. I don't really see anything to question the frame dump. The smoke is at 4767/5060, and it's basically the same story. Maybe something is causing it to draw more layers than it should? Maybe some depth readback that fails due to swizzle? The fire looks a bit better in Vulkan, but it's incorrect.
The last draw, 5060/5060, ends up brighter than it should be. It's the main thing that stands out in the frame dump compared to the PSP rendering. There's no lighting; it's just transformed rectangles, tex (CLUT 8888, modulate + color doubling) + alpha test (a != 0) + alpha blend (standard.) This is the same in Vulkan.
The colors rendered aren't wrong, but the edges shouldn't be as strong. Weirdly, the UVs and pos are 1:1, it does make me worry somehow color doubling is wrong...
Some of the other dumps had a brightness issue with the flames but after investigating, it was actually a playback issue - #16401. That makes the flames match what a PSP renders for these frame dumps. So must be a bug somewhere else if they're wrong...
-[Unknown]
MotorStorm - Arctic Edge (USA) (En,Fr,De,Es,It,Nl,Pt,Ru) wrong shadows UCUS98743_0001.ppdmp.ZIP
here is a GE dump from the EU version which doesn't have the same problem UCES01250_0001.ppdmp.ZIP
That's #7552. Not a software rendering issue.
-[Unknown]
Hot Brain (USA) (En,Fr,De,Es,It) save screen is corrupt ULUS10268_0001.ppdmp.ZIP ULUS10268_0002.ppdmp.ZIP
MTX Mototrax (USA) black line going through the screen on the rider creation screen ULUS10138_0001.ppdmp.ZIP ULUS10138_0002.ppdmp.ZIP
Hot Brain (USA) (En,Fr,De,Es,It) save screen is corrupt ULUS10268_0001.ppdmp.ZIP ULUS10268_0002.ppdmp.ZIP
The frame dump for this looks strange, and renders wrong on a PSP as well as on Vulkan. Does the game look right when you don't use the software renderer?
MTX Mototrax (USA) black line going through the screen on the rider creation screen ULUS10138_0001.ppdmp.ZIP ULUS10138_0002.ppdmp.ZIP
There are a few black lines here, all are incorrect, but the most obvious one actually should just be thinner:
-[Unknown]
Hot Brain (USA) (En,Fr,De,Es,It) save screen is corrupt ULUS10268_0001.ppdmp.ZIP ULUS10268_0002.ppdmp.ZIP
The frame dump for this looks strange, and renders wrong on a PSP as well as on Vulkan. Does the game look right when you don't use the software renderer?
it is corrupt in all backends this is Vulkan ULUS10268_0001.zip and OpenGL is the same
Harry Potter and the Order of the Phoenix (USA) black triangles on the rug ULUS10261_0001.zip
Need for Speed - Most Wanted 5-1-0 (USA) signs on side of the road are glitchy they are direction signs to show you which way to go it shows them correctly in the GE dumps ULUS10036_0001.ppdmp.ZIP ULUS10036_0002.ppdmp.ZIP
Need for Speed - Shift (USA) (En,Fr,Es) thick black line in menus and videos ULUS10462_0001.zip
Pursuit Force (USA) road is glitchy (partially fixed by #16470, still some bezier issue in right-side wall) UCUS98640_0001.ppdmp.ZIP UCUS98640_0002.ppdmp.ZIP UCUS98640_0003.ppdmp.ZIP
Maru Goukaku - Shikaku Dasshu! TOEIC Test Portable (Japan) (v1.01) half the picture is missing and so is the text NPJH50574_0001.zip
Software is not quite in a state where we'll create individual issues for everything, but here's a place to collect issues (always with GE dumps!).
![image](https://user-images.githubusercontent.com/130929/193156143-003abd61-2121-444a-b6bf-a65b9ddcfb95.png) Both dumps here: [Wipeout UCES00001 dumps.zip](https://github.com/hrydgard/ppsspp/files/9679496/Wipeout.UCES00001.dumps.zip)Wipeout menu text slightly glitched (additional thin vertical lines, clearly filtering outside the intended range):(#16241)
![image](https://user-images.githubusercontent.com/130929/193155967-0baff082-1445-4607-a525-f776d29b6c84.png) Both dumps here: [Wipeout UCES00001 dumps.zip](https://github.com/hrydgard/ppsspp/files/9679496/Wipeout.UCES00001.dumps.zip)Wipeout Pure ocean white instead of blue:(#16132)
Zettai Zetsumei Toshi 3 draws some triangles that it shouldn't below the character's feet (more details in https://github.com/hrydgard/ppsspp/issues/16207#issuecomment-1275553919): ![image](https://user-images.githubusercontent.com/191233/195226287-4621701c-ec4d-46cb-a209-eda9bc156345.png) [ULJS00191 GE dump.zip](https://github.com/hrydgard/ppsspp/files/9759927/ULJS00191.GE.dump.zip) Note: related problem in #15875, but with negative W after clipping Z.Misplaced triangle in Zettai Zetsumei Toshi 3(#16470)