ppsspp
ppsspp copied to clipboard
hrydgard
Water reflections in Flatout head on
What happens?
What hardware, operating system, and PPSSPP version? On desktop, GPU matters for graphical issues.
Tested on android OpenGL with HW transformation-ON. Dont know if this issue have vulkan or dx
Could you try exporting a GE debugger dump on PC?
To do this, open the game and select Debug -> GE debugger..., then when it's displaying the scene, press Record in the top right. After a second or so, it'll finish and save a trace of the drawing activity.
After that, check the memstick/PSP/SYSTEM/DUMP folder and it'll have created a file named something like "ULES12345_0000.ppdmp". You can zip that and then drag and drop it into a reply here.
-[Unknown]
A frame dump would be useful as unknown says above, full instructions: https://github.com/hrydgard/ppsspp/wiki/How-to-create-a-frame-dump (then just zip up and drag into your github post)
Additionally, a screenshot with the software renderer enabled could be enlightening, or from hardware.
I've found some pixelated footage on youtube bcs i don't have psp anymore. With some imagination you may see, the water should be transparent
That frame dump does show transparent water (from a PSP):
Doesn't look like water I'd want to drive through, haha, but let's see.
-[Unknown]
Draws the ground and sky, then gets to a shadow of the vehicle at 745/1768 (which looks fine, at least in software.) At this point, depth is mostly near 1, but around 0.75 in the near direction, and stencil is zero.
Next it draws the vehicle and some objects and trees, up until 1137/1768. Depth has the vehicle closer, but still pretty standard. Stencil still zero.
This water is drawn using a positions only vertex type, texturing + alpha blend + depth test. The alpha blend is standard, src.a + (1 - src.a) and depth test is < (i.e. water closer than ground, makes sense.) Texture uses modulate and linear/mipmap linear between 4 levels (standard halving, similar colors and alpha.) Alpha is generally between 60-80. Dither off, fog off, no RGBA write mask. Texture is 8888 (CLUT8) and target is 5551.
Lighting is off, but in case it matters the update flag is set to ambient/diffuse. Material ambient is fbcdcd, and alpha is ff. The ambient color (used for lighting) is 464141, but its alpha is also ff.
After this draw, software already looks like this (personally I think it looks less ugly, but alas it's wrong apparently):
Hardware is even darker for some reason, at:
Later, at 1522/1768 it draws an interesting texture from the rendered scene:
For some reason at ~1624/1768, the colors look really weird in hardware but fine in software. This is where it applies that, changed to a bloom texture. This brightens the final water a bit more.
Filtering to 1-1138 gives the water pre-bloom. Maybe there's copying affecting the PSP playback. Here's it filtered similarly:
So even before the bloom, it looks much less harsh. Ground looks about right just before that draw, too.
The previous draw (1136/1768) includes color, ee776655, which wouldn't help even if it were somehow reused instead of material color/alpha.
It does use texture matrix generation (based on positions), and has UV scale/offset set (which I don't think apply in that mode.) Uses a -8 mip bias, but doesn't seem like it'd matter. The water texture is in RAM and not rendered.
I wonder how it's supposed to be more transparent...
-[Unknown]
As a quick test, I tried enabling depth write on this draw. Here's what software drew:
Hardware is similar, although it has more and darker patches of water that way.
Now for another test: disabling depth clamp/clipping in software for just that one draw:
This looks almost exactly right. Hardware still gets the water bluer, but it looks much better:
Digging deeper, if I turn off near clipping bad things happen. But if I target it just to that draw:
So clipping is causing problems here... and yes. It's another triangle inversion. Each time it clipped (in this case), one or more original vertices had a negative w, and the resulting vertices are ending up with always positive w. This is happening to hardware rendering as well, in a visible way. I think it's harsher because of 8888 vs 5551.
That means this is similar to the issue noted in #16207 and #15875, linking #16131 as well. But this one is visibly wrong in hardware rendering as well (not surprising.) Clipping against w >= 0 would not help here.
-[Unknown]
Fixing this in hardware renderers will be annoying. Should be pretty doable with a geometry shader, as long as we clip (or do some of the same math, at least) manually... we can't really decide to discard the points from the vertex shader, not accurately, anyway.
Now that I understand how all of this works, it's obvious that the vertex range primitive discard just always happens, and clipping only "skips" it by happening beforehand. But APIs don't want to clip beforehand...
-[Unknown]