Software renderer issues #16131
Comments
|
|
I reported it before but I will post it here as well for sake of being on 1 place. |
Can't round to the pixel when calculating the S/T deltas. This fixes issues in Wipeout (hrydgard#16131) and Call of Duty bloom.
Can't round to the pixel when calculating the S/T deltas. This fixes issues in Wipeout (hrydgard#16131) and Call of Duty bloom.
|
|
Socom NavySeals Fireteam Bravo 3 NPJG90068_0001.zip |
|
Prince of Persia - Rival Swords (USA) (En,Fr,Es) (v1.01) |
These are the same clipping inversion indeed, at 147/726 and 134/673 respectively. Didn't check which direction w goes.
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] |
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): 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: 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 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] |
|
|
|
|
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 The grid draw at 4460/4504 then uses 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...
|
|
|
|
|
Gran Turismo (USA) (En,Fr,Es) |
|
|
|
Hey bender, thanks for all the testing! If you have time, could you attach screenshots with the dumps too? |
|
ok |
|
Buzz! Quiz World (Europe) (En,Pl) |
|
Rain Wonder Trip (Japan) (En,Ja,Ko) (v1.03) |
|
Tony Hawk's Underground 2 Remix (USA) (v1.01) |
|
|
Shadow of Destiny ULUS10459 |
|
Split-Second (USA) (En,Fr,Es) |
When I run this on a PSP, there's no green text. But, something weird is captured in this frame dump. At two points in the frame, it switches to a framebuffer at 0x04198000 (at 3/78 and 76/78) and draws some text. Some of the vertex positions sorta look like hot garbage, but there are good ones in there and the colors and etc. seem sensible. Both times it draws this green text there: At 78/78 it sets the font texture (not 0x04198000, but the same texture it used to draw that) again and draws... 0 triangles. It never seems to even try to draw the "QUIZ CHALLENGE" text. And the PSP execution doesn't either. Does this work in hardware renderers? I suspect it's not softgpu specific, whatever the bug is...
Indeed should have no line: This is using more 0.5 positions and UVs, although interestingly it's doing i.e. X1=138, X2=238.5 and U1=0, U2=100.5. It uses triangles in a bit of and odd way (probably trying to restart the strip) that we don't detect as rectangles, so this is probably like the Driver 76 case, and might work already under the rectangle path. Unfortunately, whatever is screwed up in the Rain Wonder Trip second example (subtitle problem) is hardcoded within the frame dump. It's taking an image (possibly previously rendered) that's already got that gray corruption and rendering it to the screen, so it's already wrong. Does it work right in the hardware renderers?
Wow, it looks like a modern game on release day. But hmm, it does look as bad to me: Which more or less matches the PSP rendering: Maybe a setting? I don't see anything suspicious, though... does it happen when you play back the framedumps? -[Unknown] |
Hm... indeed, not seeing in the frame dump. I wonder if something is going wrong with some cache. I think there might've been a demo for this game, maybe I can dig it up. Any tips on reproducing it? This sorta looks like that Need for Speed issue to me. Somehow some state seems to be going out of sync... -[Unknown] |
|
Tony Hawk's Underground 2 Remix (USA) (v1.01) |
|
Unfortunately, whatever is screwed up in the Rain Wonder Trip second example (subtitle problem) is hardcoded within the frame dump. It's taking an image (possibly previously rendered) that's already got that gray corruption and rendering it to the screen, so it's already wrong. Does it work right in the hardware renderers? no it doesn't work in the hardware renderers aswell just checked it on my psp |
|
|
split second demo |
|
Race Driver 2006 (USA) (v1.01) |
|
@unknownbrackets and here is the Syphon Filter - Dark Mirror (USA) demo aswell |
|
Super Stardust Portable (USA) (En,Fr,De,Es,It,Nl,Pt,Ru) (PSP) (PSN) |
|
Cars - Race-O-Rama (USA) (En,Fr,De,Es,It) |
|
Cars (USA) (v1.02) |
|
-MX vs. ATV Reflex (USA) (En,Fr) (v1.02) and MX vs. ATV Untamed (USA)
|
|
There's most likely something going wrong when it actually creates this texture, or loads it, or something. Could even be PGF.
Interesting, that seems to come from this texture: I'm not sure why the 22 is broken that way. This other image has a better one, but I think it's the front or something: 0x041d0000 (the texture with the broken 22) is not rendered within the frame, and is CLUT8 so seems unlikely to be rendered at all. The PSP rendering matches the software rendering pretty well too. It's either that way in the game, or a bug somewhere not caught in the framedump.
Thanks. The fire looks pretty good in one area until it does the ugly smoke: Then the smoke at 4810: The next glow at 4915 does improve it: It then seems to blur/bloom that a bit. So returning to the original smoke... it's at 0x040eb180 (outside depth buffer), and looks reasonable (low alpha): No texgen, CLUT4, swizzled so not rendered. Is using color doubling as noted before. Interestingly, it is using RECTANGLES in transform mode. All but the first rectangle have partial alpha. Even without color doubling it looks awful. If I only draw the first of 25 rectangles (with full alpha), it doesn't even show because that one's offscreen. It's weird that all of the others are in the exact same spot. If I only draw 2 rectanlges of 25, it looks better (end result): What I think is happening is that it's building a map of where to show smoke, and somehow all the remaining slots get duplicated for this one. Will need more debugging, might be a CPU bug or something else... demo helps.
Thanks, I read this after digging up some other framedumps of this and editing them. Something funny is happening here for sure, but it's related to morphweights or morph variants, so not a softgpu issue. Definitely an interesting issue.
This looks like some sort of culling issue, with some depth getting written early or not getting cleared properly. It looks fine in hardware, right? Frame dump doesn't work there either?
What if you save state and then come back - is it not messed up again? If yes, that sounds like a very interesting state bug. How easy to reproduce? Maybe I can find a cheap used copy.
|
|
God Eater Burst lack of bloom effects #17033 |
|
ATV Offroad Fury Blazin Screenrecording_20230312_074901_org.ppsspp.ppsspp.mp4 |
|
Fuuun Shinsengumi Bakumatsuden Portable
I think the image behind the character is missing. |
texture that doesn't appear in the image above |
Turns out this is actually close to (but not exactly) right. Should still be looked into (I wonder which part we're getting inaccurately), but hardware is the one that is blooming more than it should.
Unfortunately, it looks like this frame dump didn't capture the problem - it looks pretty close between PPSSPP and a PSP. I don't see any floor panel flickering here. That said, I think this game uses mip map levels for the floor and it seems possible it's related to that.
It does look like the background is missing - both in software and hardware. I can get software to render correct if I disable the minz/maxz settings at 601/654. It then looks like this:
Which seems pretty close to the PSP rendering: The verts use Z=1000 (float, transform) from a viewport 30000 -20000 scale, turns into 9999 (270F). However, minz is 2710. Thsi seems likely to be a matrix/vertex accuracy issue. The specific formula for Z is: proj_z = 1000 * -1 * -0.0020020008087158203125 - 1.001983642578125 = ~1.00001716614 Probably this should just barely round up, which would draw. Most likely PPSSPP is calculating a slightly lower value or else not rounding properly. -[Unknown] |
|
Text is not rendering in save/load dialog in SoftGPU on Linux. Screenshot: When I compile master on my 32-bit Linux, it does not work in SW, but works normally in OpenGL. Logging shows that g_draw != nullptr
textDrawerInited == true
textDrawer == nullptrin Core/Util/PPGeDraw.cpp: Might investigate myself, but you can probably figure it faster. Edit: sorry for the lack of GE dump. |
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!).
Wipeout menu text slightly glitched (additional thin vertical lines, clearly filtering outside the intended range):(#16241)Both dumps here:
Wipeout UCES00001 dumps.zip
Wipeout Pure ocean white instead of blue:(#16132)Both dumps here:
Wipeout UCES00001 dumps.zip
Misplaced triangle in Zettai Zetsumei Toshi 3(#16470)Zettai Zetsumei Toshi 3 draws some triangles that it shouldn't below the character's feet (more details in #16207 (comment)):
ULJS00191 GE dump.zip
Note: related problem in #15875, but with negative W after clipping Z.
The text was updated successfully, but these errors were encountered: