Sega Rally [ULES00910] - Missing dirt impact over the car

[ppmeis]

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:

[unknownbrackets]

Might have to do with texture levels. Do the mipmap levels look different other than smaller?

-[Unknown]

[ppmeis]

@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

[ppmeis]

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.

[ppmeis]

Tested with latest build. Same status.

[unknownbrackets]

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]

[daniel229]

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

[unknownbrackets]

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]

[daniel229]

Read framebuffers to memory does not solve the problem in the latest build.
But changing rendering mode in game help the problem.

[daniel229]

Even force return in the top of ReadFramebufferToMemory it still get the mud when changing rendering mode.

[unknownbrackets]

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]

[daniel229]

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

[unknownbrackets]

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]

[daniel229]

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.

[unknownbrackets]

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]

[daniel229]

Still works after changing rendering mode.

[ppmeis]

Tested with latest build. Same status.

[ppmeis]

Tested with latest build. Same status. If you swich between NBR and BR dirt appears over all car, not only wheels:

[ppmeis]

Tested with latest build. Same status.

[ppmeis]

Tested again. Same issues.

[ppmeis]

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 ;).

[unknownbrackets]

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]

[ppmeis]

@unknownbrackets here is the "Step Into" at the point the texture changes:

The texture tab:

[unknownbrackets]

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]

[ppmeis]

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:

[unknownbrackets]

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]

[ppmeis]

@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.

[ppmeis]

Tested with latest build. Same status.

[ppmeis]

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:

[ppmeis]

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):

[ppmeis]

Tested with latest build. Same issues.

[unknownbrackets]

I think the latest information means that the dirt is being drawn by the CPU over a FBO texture. It might help to have a GE frame dump to confirm.

-[Unknown]

[ppmeis]

@unknownbrackets here is the GE Frame Dumps (first is with missing textures, second the same but after goes fullscreen):

ULES00910_0001.zip
ULES00910_0002.zip

[unknownbrackets]

It seems like draw 1522/4013 uses texture 0x08bff920 to draw the dirt. It uses regular alpha blending and a >= depth test.

It is using slope/bias but there are no mipmap levels so it shouldn't matter. I can imagine issues if lazy texture caching or vertex caching are enabled, but given that it's a RAM address, this shouldn't happen with those both off...

It also clears depth at the start. So it's interesting that resizing the screen fixes it - that clears caches, and most notably the FBOs.

-[Unknown]

[ppmeis]

Tested with latest Windows build. Same status.

[nassau-tk]

This game has a other issue on Win10 of OpenGL. #13416

But,I find strange point happening on Win10(Vulkan) and Android(OpenGL).
PPSSPP v1.10.3-700~709
SEGA RALLY REVO (ULJM05302)

If you select these car then appear the dirt(Level2) on body suddenly at LAP2 automaticaly.
Other cars are not appear the dirt on body.
Dumpfile here. (LAP2 Dirt Level2)
ULJM05302_0001.zip
and
Dumpfile here. (LAP1 Dirt Level1. It's not appear in game.But, Dump file drawing corectly.)
ULJM05302_0002.zip

I wonder...

[Real PSP Dirt Level-1]

[Real PSP Dirt Level-2]

[Panderner]

The car body changes when i use save states, minimizing or changing graphic options.

Here's a screenshot when the car body is clean but wheels are dirty:

But when i use save states, minimize the PPSSPP and return or changing graphic options during in second lap the car body are dirty:

and then Restart the Race. The car body is dirty but the wheels are clean.

and then use save states, minimize or changing graphic option again the car is clean in first lap.

[hrydgard]

Yeah, this seems to be a case where the game first renders decals using the GPU so the car texture ends up in a framebuffer, then pokes dirt into it with CPU probably, and we never notice because we don't try to hash the memory behind framebuffers (and that's generally a waste, though not in this game)...

[unknownbrackets]

This game uses 0x040d4000 to apply some reflections of the sky/trees on the vehicle (afaict), but the dirt comes from a RAM texture (0x08b93170 in the frame dump.)

It draws the dirt using a >= depth test, clipped depth range, fog ( #b69a6e), standard blend (pointless since alpha is full on just the vertex, not sure why I said pointless), and lighting. Here you can see some of the dirt (circa 741/1166):

It's confusing, because based on the results it definitely sounds like it's a missing CPU write to a framebuffer. Dirt on the tires similarly comes from RAM at 1016/1166. This is a bit after that at 1042/1166 when it does the side:

I wonder if this could be a texture cache issue? Looking at the texture (now with transparency) from the other dump at 1747/4013:

Opaque, this looks like the texture from the first GE debugger screenshot in my comment. Here's the newer frame dump at 700/1166:

The texture is actually CLUT8. Here's the more dirt texture with its CLUT:

And the less dirt one from the newer frame dump:

So I think the actual issue here could be that the CLUT isn't being detected as different, though that's also surprising because we use XXH3 on that. It's not framebuffers being cleared then, but textures being cleared that helps this. Note that the CLUT is 8888, and the colors are actually the same - only alpha differs. Not sure if the indexed texture data differs, but probably doesn't.

-[Unknown]

[ppmeis]

Tested in latest build. Same status. Here is a screenshot with three car models in same screen, two of them with correct textures and one with missed textures: