frogger: helmet chaos "shadow misplaced" with framebuffer rendering

[fastrizwaan]

here's actual sony psp game the frog's shadow is on the same tile http://www.youtube.com/watch?v=se-P-FSYIj0&feature=youtu.be&t=1m52s

ppsspp v0.9.5-16-g1347c3b in PPSSPPSDL (linux) and android http://youtu.be/kZGxJVBAbv4?t=47s

the shadow is on the 3rd tile below.

[unknownbrackets]

Hmm, could be a lot of different things. Looks like #4325.

-[Unknown]

[fastrizwaan]

God of War: Chains of Olympus and Ghost of Sparta both has tiny misplaced shadow problem like this:

[dbz400]

Not too sure if it is Android issue or SDL only ?I test it in windows platform

[unknownbrackets]

Does this still happen in Frogger? If yes:

• Does it happen with Hardware Transform disabled?
• Does it happen with the "software renderer" (it will be extremely slow, but this will at least help us find the issue.)

If this is only on Linux, I wonder if it's some glitch with the jit. Does anyone have the game on Windows to double check? Or, can you run it under WINE? There are some calling convention differences that affect the jit. They should be the same under WINE.

-[Unknown]

[fastrizwaan]

software is showing the shadows

[fastrizwaan]

frogger also shows shadow properly in software rendering mode

[unknownbrackets]

But, I presume, it still happens with OpenGL, regardless of hardware transform setting?

-[Unknown]

[fastrizwaan]

the shadow is misplaced with hardware transform [on] or [off]

[unknownbrackets]

Does this still happen? What about with jit disabled?

-[Unknown]

[fastrizwaan]

yes, Jit disabled in developer tools

[dbz400]

softgpu loosk correct with the shadow rendering

[unknownbrackets]

If you step through the GE debugger, does it also draw a red thing where it eventually draws the shadow, or in the correct place?

I wonder if the problem is in vertex parsing, or in some kind of transform, or where... If I understand right, the Frogger issue reproduces on Windows?

-[Unknown]

[hrydgard]

Could just as well be bad texture coordinates, if it draws the texture by drawing the surrounding terrain again with a texture coordinate transform and UV clamping with the frog shadow as the texture.

[unknownbrackets]

Does prescale or skinning affect it, then? Or low quality beziers even? It would help to know if it's using a regular prim and see the GE Debugger tabs when it draws the shadow.

-[Unknown]

[dbz400]

I will try the prescale/skinning option again tonight and also get the GE debuggers tabs detail as well .

[dbz400]

Tried prescal/skinning , didn't help .

Looks like it is in wrong place when it draws the shadow initally

[unknownbrackets]

That red thing and texture are a plant, not the shadow...

But, I notice it is using splines.

-[Unknown]

[dbz400]

This one should be the shadow.

[hrydgard]

Yeah, if it's drawing it that way we have a case of wrong texture coordinates indeed. Texture tab?

Or hm, that big red square isn't even centered around the frog, that might be wrong too...

[dbz400]

Here it is the texture tab

[dbz400]

Seems to be using this ?

                case GE_PROJMAP_POSITION:  // Use model space XYZ as source
                    temp_tc = "vec4(position.xyz, 1.0)";
                    break;

[dbz400]

If i do some modification though it is wrong

                case GE_PROJMAP_POSITION:  // Use model space XYZ as source
                    temp_tc = "vec4(position.xyz, 1.0) / 10.0";
                    break;

The shadow comes closer itself.

[hrydgard]

Very interesting. I think that texgen mode is pretty rare.

I would have expect that modification to also shrink the shadow but obviously it didn't....

[hrydgard]

What happens if you replace "position" with "worldpos" ?

[dbz400]

The shadow will disappear if replace "position" with "worldpos"

                case GE_PROJMAP_POSITION:  // Use model space XYZ as source
                    temp_tc = "vec4(worldpos.xyz, 1.0)";
                    break;

[hrydgard]

Alright, it's not that then.

[dbz400]

softgpu renders the shadow correct

case GE_TEXMAP_TEXTURE_MATRIX:
    {
        // projection mapping, TODO: Move this code to TransformUnit!
        Vec3<float> source;
        switch (gstate.getUVProjMode()) {
        case GE_PROJMAP_POSITION:
            source = ((v0.modelpos * w0 + v1.modelpos * w1 + v2.modelpos * w2) / (w0+w1+w2));
            break;

[unknownbrackets]

If you multiply that by 10, does it end up in the same wrong place? Is any of this affected by render resolution?

If I'm reading right, the vertex type is positions only, so it can't be some morph/skin/whatever thing. Does the GE debugger show the same area for the softgpu when drawing it? Or is the area it shows offset at all (I realize it's a larger area than the shadow)?

-[Unknown]

[dbz400]

You are right . Multiply that by 10 end up in the same wrong place

[dbz400]

I'm wondering would it be case of pos = 0 ?

bool hasPosition = (vertType & GE_VTYPE_POS_MASK) != 0 && useHWTransform;

temp_tc = hasPosition ? "vec4(position.xyz, 1.0)" : "vec4(0.0);

[unknownbrackets]

BattleGrounds 3 has an issue that looks the same as the Frogger issue: http://forums.ppsspp.org/showthread.php?tid=11243

It uses GE_TEXMAP_TEXTURE_MATRIX / GE_PROJMAP_POSITION as well, and the shadows of tanks are misplaced. The source of the shadow is a render-to-texture. Strangely, its vertex type includes U/V while doing this, and also positions.

The texture size matches the framebuffer size, afaict, so that seems fine. Also, it happens in software and hardware transform. The texgen matrix looks like this:

Texgen 0    1.109924    -0.063847   0.097523    0.183044
Texgen 1    -0.440887   0.673431    -0.366386   -1.096008
Texgen 2    -0.732773   -433.757813 168.062500  -238.691406

Which I'm assuming is right. Not multiplying by the texgen matrix or multiplying additionally by the view matrix doesn't help.

-[Unknown]

[unknownbrackets]

This also affects Dragon Ball Z and Kingdom Hearts (but only in certain areas, it seems like.)

What's very interesting is that in Kingdom Hearts, sometimes the shadows seem fine. At least when there's only one character with shadows or something. Other shadows seem to work improperly and scale wrong. Hmm.

-[Unknown]

[unknownbrackets]

So, I tried logging in software transform:

NOTICE_LOG(HLE, "Projection mapping pos=%f,%f +tgen=%f,%f, mul=%f,%f", pos[0], pos[1], uv[0], uv[1], uv[0] * widthFactor, uv[1] * heightFactor);

The values don't look reasonable. From Dragon Ball Z, I got:

• Neither pos nor after tgen matrix was anywhere near 0-1 range.
• The texture was 64x64, but the framebuffer was 480x272. Still, after multiply it was not within the 0-1 range at all.
• I also tried using out instead of pos, which wasn't better.
• It's specifying to clamp s and t, which obviously is not happening currently.

Anyway, in Battlegrounds 3D, the texture and framebuffer is the right size, and it seems to be positioned correctly...

FWIW, softgpu's shadows seem to work properly in Dragon Ball Z as well.

I don't understand projection mapping at all.

-[Unknown]

[unknownbrackets]

So, just to note, this seems to be caused at least primarily by framebuffers with flipped V. There may still be other issues, but that appears to help at least a few games when hacked with "read framebuffers to memory" as a test.

-[Unknown]

[unknownbrackets]

Ah, Dragon Ball Z also uses RGB masking to make its shadows work, which is why they don't really work correctly all the time.... hmm.

-[Unknown]

[unknownbrackets]

Does Frogger look any better with the latest git build?

-[Unknown]

[fastrizwaan]

yes, in Frogger with ppsspp-v0.9.8_1097, the shadow is looking perfect.

[fastrizwaan]

Also in god of war ghost of sparta and chains of olympus, the shadows are looking good.

[unknownbrackets]

Okay, there's a separate issue in God of War and could do some optimization on this sort of thing, but this bug is taken care of, so closing.

-[Unknown]