Open daniel229 opened 9 years ago
Gedebugger
https://cloud.githubusercontent.com/assets/3481559/5690501/dddb7f5c-98c8-11e4-8393-cd46924430f5.png
https://cloud.githubusercontent.com/assets/3481559/5690498/ddd84d1e-98c8-11e4-9198-a4bdb7120539.png
https://cloud.githubusercontent.com/assets/3481559/5690499/dddad1e2-98c8-11e4-9fb2-e8edc9d3b727.png
https://cloud.githubusercontent.com/assets/3481559/5690503/dddc64a8-98c8-11e4-8cec-c7395cef03cf.png
https://cloud.githubusercontent.com/assets/3481559/5690500/dddb80ba-98c8-11e4-89b8-340456f38384.png
https://cloud.githubusercontent.com/assets/3481559/5690502/dddbf798-98c8-11e4-9846-d308359e5a39.png
https://cloud.githubusercontent.com/assets/3481559/5690504/ddff6610-98c8-11e4-8b50-89b2e1c1880f.png
https://cloud.githubusercontent.com/assets/3481559/5690506/de019fc0-98c8-11e4-8178-e2ac122c9e5a.png
https://cloud.githubusercontent.com/assets/3481559/5690505/de019110-98c8-11e4-98d1-e183281a5995.png
Hmm, those light types... is it not displaying them correctly? I guess it's using point and spot. The UVs seem odd, I wonder if it's not handling UV scale properly in the preview / vertices tab.
Hmm.
-[Unknown]
Spot is rare, we might have bugs in it..
Does the software renderer look correct at all?
-[Unknown]
the light seems stronger in software renderer.
Hm, the shader generation code is very similar between GL and DX but the results come out different. Could it be that it sends an INF or NaN in some lighting parameter, and the two shader compilers generate code that's different enough that those affect the outcome? Hm.
You can also see in the screenshots that the light glows appear through objects and walls in this game. It's really annoyng.
@DonelBueno , yeah, it's a typical result of the game reading the z-buffer to figure out whether to draw a light glow or not, which is hard to do correctly and quickly on desktop GL, and impossible on many OpenGL ES 2.0 implementations unfortunately - while trivial in the software renderer.
What about OpenGL ES 3.0 and DirectX?
Well, reading back the zbuffer is very expensive on most PC and mobile GPUs that can actually do it, currently, although on beefy PCs we could afford it, it's just a bit tricky to implement, the way PPSSPP works right now. Vulkan / D3D12 might let us do things fast-and-loose like console games can, but we will see.
Fast and loose hurray. Let's hope.
I don't think GLES 3.0 can do it either, without extensions (glReadPIxels can't, in GLES3, afaik anyway.) We might be able to bind the depth as a texture and "copy" it to a color texture either via shader or what have you? I expect this would be slow...
-[Unknown]
Well the tricky part architecture-wise right now is actually detecting that the game is accessing the zbuffer with the cpu. As VRAM is mapped like every other memory and we don't generally check addresses before r/w, we would have to resort to tricks like mapping the memory as inaccessable and trap accesses, which would trigger copying down data from the gpu. Well, of course, unless the game is nice enough to do a block copy from VRAM to RAM first where we could trivially detect the case of copying from a zbuffer, but no idea if games like this do that or not.
I know of at least two games that actually texture (with an incompatible format or with depal) from depth. Talk about new complexities in depal.
Yeah, peeking into depth might even be more common than color. But, that's not a problem we don't already have with color.
-[Unknown]
Are there any other games affected by the lack of being able to read back the z-buffer?
-[Unknown]
A GE frame dump would help to confirm things here, although it seems pretty clear.
See here for instructions - it's not hard and works on Android too: https://github.com/hrydgard/ppsspp/wiki/How-to-create-a-frame-dump
You can zip that and then drag and drop it into a reply here.
-[Unknown]
There's also an issue on training 5 water
VK & OGL
PSP
@Gamemulatorer That bottom screenshot is not taken from the real hardware.
@Panderner how did you know? 😐🤔
@Panderner how did you know? 😐🤔
Here's a video taken from real hardware: https://youtu.be/h2Jg1BEIg7M?t=14
@Panderner how did you know? 😐🤔
Here's a video taken from real hardware: https://youtu.be/h2Jg1BEIg7M?t=14
That video wasn't training 5 water. Here's the source of my ss above https://m.youtube.com/watch?v=hTaZ2frao34&feature=youtu.be
@Panderner how did you know? 😐🤔
Here's a video taken from real hardware: https://youtu.be/h2Jg1BEIg7M?t=14
That video wasn't training 5 water. Here's the source of my ss above https://m.youtube.com/watch?v=hTaZ2frao34&feature=youtu.be
@Gamemulatorer this is not a right footage of this video it's recorded using the emulator.
From that dump, this is actual rendering:
Here's software, which looks pretty close except for the line on the left of the UI:
And here's Vulkan, which looks a bit brighter (could be 32-bit vs 16-bit color):
In each case the light looks about the same.
Should we mark this issue as fixed? It could've been fixed by several other lighting fixes, such as the one that fixed Virtua Tennis.
Edit: Oh wait, this was depth related? I guess this latest screenshot is separate?
-[Unknown]
openGL Hardware Transform on
Hardware Transform off
DX Hardware Transform on
Hardware Transform off
PSP
So,the openGL with Hardware Transform off is the most like the one in PSP.