ppsspp
ppsspp copied to clipboard
hrydgard
Sega Rally [ULES00910] - Missing dirt impact over the car
During playing Sega Rally, I notice one effect is missing. Player's car is clean during all the circuit, so dirt impact effect is totally missing:
Real PSP
GE Debugger tabs:
Might have to do with texture levels. Do the mipmap levels look different other than smaller?
-[Unknown]
@unknownbrackets The other same effect for the CPU cars is smaller and it appears in the screen. It has the same look at this one but is 128x128 instead of 256x256. But now I notice that the effect only is missing in that car model :S.
Also, when I switch between Buffer Rendered to CPU/GPU and back to buffer rendered, The effect appears! :S
Tested in OpenGL and Direct3D9
Tested with latest build. Same issue. Also I figured out when you are playing other cars don't have dirt impact, it only appears when I switch buffer render.
So, it's probably a copy that we're missing...
When it draws the dirt (above screenshots), can you press "step prim" to see it highlight where it's drawing? It changes more settings after that, so I want to know what settings it's actually drawing with.
0x09* can't be something that needs copying back to memory. Are there any textures it uses that start with 0x04*? Otherwise, it's probably copying from somewhere else it's rendering to.
-[Unknown]
The mud draws to the wheel,but not draw to the car body,they use the same texture 0x09a7a100.Don't know if the reflection effect of the car,it can't draw to.
GE debugger
more tabs https://gist.github.com/daniel229/23fcebf4d9b1c5c67010
Well, the texture looks fine... it does use a depth test, though. But it can't really be depth related if "read framebuffers" solves the problem.
There must be some framebuffer it's rendering to (even if it's not during the race) that causes it.
In GPU/GLES/Framebuffer.cpp, you can find this:
void FramebufferManager::ReadFramebufferToMemory
And on the next line log which framebuffers it reads (during "read framebuffers to memory" mode):
NOTICE_LOG(HLE, "Downloading: %08x", vfb->fb_address);
Then, we can try forcing off some of those framebuffers. That is:
if (vfb->fb_address != 0x00044000 && vfb->fb_address != 0x00000000) {
return;
}
NOTICE_LOG(HLE, "Downloading: %08x", vfb->fb_address);
Until we've narrowed it down to the one that makes it work. Then we have to figure out where it's rendering there and how we can detect that it needs to be copied out of GL.
-[Unknown]
Read framebuffers to memory does not solve the problem in the latest build. But changing rendering mode in game help the problem.
Even force return in the top of ReadFramebufferToMemory it still get the mud when changing rendering mode.
I see, then most likely we are keeping a stale framebuffer alive when the memory behind it has been written to separately. We might still be able to trigger an upload which might fix this.
What FBOs does it say are deleted and created when you change rendering mode? If one is deleted and never created, then it's probably that one.
-[Unknown]
seems each one is created
16:54:996 idle0 I[SCEGE]: GLES\Framebuffer.cpp:1872 Destroying FBO for 00000000 : 480 x 272 x 1
16:54:997 idle0 I[SCEGE]: GLES\Framebuffer.cpp:1872 Destroying FBO for 00044000 : 480 x 272 x 1
16:54:997 idle0 I[SCEGE]: GLES\Framebuffer.cpp:1872 Destroying FBO for 000cc000 : 480 x 272 x 2
16:54:998 idle0 I[SCEGE]: GLES\Framebuffer.cpp:1872 Destroying FBO for 000d4000 : 128 x 272 x 3
16:55:015 idle0 I[G3D]: GLES\TextureCache.cpp:146 Texture cached cleared from 128 textures
16:55:032 user_main I[SCEGE]: Common\FramebufferCommon.cpp:331 Creating FBO for 00044000 : 480 x 272 x 1
16:55:037 user_main I[SCEGE]: Common\FramebufferCommon.cpp:331 Creating FBO for 000cc000 : 480 x 272 x 0
16:55:037 user_main W[SCEGE]: Common\FramebufferCommon.cpp:373 FBO reusing depthbuffer, 000cc000/00088000 and 00044000/00088000
16:55:039 user_main N[HLE]: GLES\Framebuffer.cpp:1210 Downloading: 00044000
16:55:049 user_main I[SCEGE]: Common\FramebufferCommon.cpp:331 Creating FBO for 000d4000 : 128 x 272 x 3
16:55:051 user_main N[HLE]: GLES\Framebuffer.cpp:1210 Downloading: 00044000
16:55:057 user_main I[G3D]: GLES\ShaderManager.cpp:140 Linked shader: vs 118 fs 38
16:55:059 user_main I[G3D]: GLES\ShaderManager.cpp:140 Linked shader: vs 120 fs 38
16:55:063 idle0 N[HLE]: GLES\Framebuffer.cpp:1210 Downloading: 00044000
16:55:063 idle0 N[HLE]: GLES\Framebuffer.cpp:1210 Downloading: 000cc000
16:55:065 idle0 N[HLE]: GLES\Framebuffer.cpp:1210 Downloading: 000d4000
16:55:067 user_main I[SCEGE]: Common\FramebufferCommon.cpp:331 Creating FBO for 00000000 : 480 x 272 x 1
Hmm. I forgot that we upload framebuffers on create.
In GPU/Common/FramebufferCommon.cpp:
if (useBufferedRendering_ && !updateVRAM_ && !g_Config.bDisableSlowFramebufEffects) {
gpu->PerformMemoryUpload(fb_address_mem, byteSize);
NotifyStencilUpload(fb_address_mem, byteSize, true);
// TODO: Is it worth trying to upload the depth buffer?
}
Try putting an if around this and skipping some of the buffers (0x000d4000 seems like a good one to try first.) That will make it create as black instead of uploading the RAM to GL.
-[Unknown]
if (useBufferedRendering_ && !updateVRAM_ && !g_Config.bDisableSlowFramebufEffects && vfb->fb_address != 0x000d4000) { I try the address one by one,still get the mud after changing rendering mode.
Then maybe it isn't that after all... or maybe clearing to zero is still working.
In GPU/GLES/Framebuffer.cpp, there's this part:
if (resized_) {
DestroyAllFBOs();
glstate.viewport.set(0, 0, PSP_CoreParameter().pixelWidth, PSP_CoreParameter().pixelHeight);
int zoom = g_Config.iInternalResolution;
if (zoom == 0) // auto mode
zoom = (PSP_CoreParameter().pixelWidth + 479) / 480;
PSP_CoreParameter().renderWidth = 480 * zoom;
PSP_CoreParameter().renderHeight = 272 * zoom;
resized_ = false;
}
If you change it to:
if (resized_) {
resized_ = false;
}
Then it won't delete FBOs anymore. This should double check that recreating the FBOs is what's solving it. If it still works with this, then it might have more to do with the texture cache or something.
-[Unknown]
Tested with latest build. Same status. If you swich between NBR and BR dirt appears over all car, not only wheels:
Tested with latest build. Same status. I think I can add good GE info this time:
Jump to texture:
Next step prim:
In a first place, the texture is good, but in next step prim, and I don't know why, it goes transparent when it shouldn't, comparing when the texture is applied in other cars.
@unknownbrackets hope this would help in this strange issue ;).
I think I need to see more tabs for the second screenshot - mainly the texture tab. Definitely interesting though - maybe somethign is wrong with the clut?
If you go to the first screenshot, and click "Step Into" over and over (might be ~20 or so times total) what step is highlighted when the texture goes wrong?
-[Unknown]
@unknownbrackets here is the "Step Into" at the point the texture changes:
The texture tab:
Well, that was a clut load.... hm. Maybe the clut is being written too early/late.
What happens if, when the "Clut load: 000001" line is highlighted, you right click on "TexFlush" below it and select "Jump to this address"? This will just skip the clut load entirely. Then hit "Step Frame" (you might have to hit it twice to see the scene, if you hit it more times it will go back to how it looked before since you only skip the clut load for that one frame.)
If that makes it work, it could definitely be some sort of dcache issue or too-early issue.
-[Unknown]
Another anoying thing, When I load the state, all effects are fine o.0'
Otherwise, it's a BINGO for you if I do all you said:
If you pause, go to settings, don't change anything, and then resume the game, does it also make it draw the dirt?
If so, it might just be pulling the texture or clut incorrectly from a framebuffer.
Is this also fine in the software renderer? (most likely you can use a savestate from right before you actually start the race.)
-[Unknown]
@unknownbrackets it doesn't draw the dirt texture.
Using software rendering all dirt textures are shown fine, even I notice there is two kind of dirt textures, low dirt during first lap and high dirt in second lap:
So according to this, emulator are missing also low dirt texture even in wheels.
Tested with latest build. Issue still present, but now other opponent cars show dirt textures. Also, when I switch between fullscreen and windowed, dirt texture appears on player's car:
Default Settings (after change to windowed):
Same in Vulkan:
Tested on latest build, same issue. But I notice other cars only update textures when reapear in screen (when I overtake a car and then the car reapears):
