Turning "Texture coord speed hack" on by default

[hrydgard]

To get the full benefit of software skinning in some games like Tekken 6, the "Texture coord speed hack" needs to be on. And since sw skinning is on by default now, I would like to switch this to on too.

Previously it was reported that 3rd Birthday has problems with it, is this still the case?

Please mention and preferably add screenshots of any issues you see when turning on "Texture coord speedhack".

[hrydgard]

Right, Gran Turismo's menus have weird background scaling issues.

[vsub]

I wasn't around when this hack was added so I have no idea what it actually does. I made a long list of games that are affected or not by Software Skinning http://forums.ppsspp.org/showthread.php?tid=5236&pid=57489#pid57489 and I can try those games with that hack also enabled but I don't know what to expect from that hack.

Some games hate Software skinning a lot.

[hrydgard]

The hack improves some games that benefit from software skinning further by reducing the number of draw calls a bit more. Difference probably isn't huge though.

I know that SW skinning hurts a few games, but on average it's a clear win on most GPUs. So I'll leave it on by default but configurable.

I have a plan for combined hardware skinning later with some more complicated vertex shaders, will probably be even faster than software skinning but will not work on the weakest GPUs at all.

[dbz400]

Seems to be still broken in latest build in 3rd birthday with speedhack on.

[dbz400]

And this is one with speedhack on but with software skinning off .Much better but the character still renders wrong.

[dbz400]

Then speedhack on but with software skinning off and HW T&L off , all render okay

[dbz400]

Checked with latest build .Still same issue .Looks like software skinning still somehow not compatiable with the texture coord speed hack when both on.

[dbz400]

3rd birthdays : looks good now with both HW on/software skinning on and texture coord speedhack on .

[dbz400]

I think we can simply hide the software skinning/texture coord speedhack/vertexdecoder JIT option in UI and leave it only in ini-setting

[dbz400]

Ooops seems to be still some issues on the scaling with this on .Castlevania The Dracula X Chronicles

[hrydgard]

Thanks for reporting, almost there :)

[hrydgard]

One remaining issue: When texcoord speedhack is enabled, ships in Wipeout randomly lose their texture sometimes.

[dbz400]

Humm found little bit issue in Wipeout when HW T&L and texture coord both on

[dbz400]

Just found a bit big rendering issue when this option ON .The Jeannac Arc

[dbz400]

It is caused by submitBeizer

if (g_Config.bPrescaleUV) {
    // We scaled during Normalize already so let's turn it off when drawing.
    prevUVScale = gstate_c.uv;
    gstate_c.uv.uScale = 1.0f;
    gstate_c.uv.vScale = 1.0f;
    gstate_c.uv.uOff = 0;
    gstate_c.uv.vOff = 0;
}

[hrydgard]

Yeah there's some bezier bug, it also breaks Puzzle Bobble graphically. Gonna have a look as soon as I have time.

[unknownbrackets]

Oooh, [ Debug ], that looks interesting.

Anyway, the video is even more screwed up, heh.

It uses: Texture mapping mode: gen tex coords, proj: pos U scale 0.936523 V scale 0.530273 U offset 0.000977 V offset 0.000977

While playing the video. None of the above settings ever change.

-[Unknown]

[dbz400]

The wipeout texture issue when texture coord on is caused by vertex cache .Can we do this ? just like we do for software skinning.

    // Also avoid caching when prescale UV.
    if (g_Config.bPrescaleUV)
        useCache = false;

[unknownbrackets]

I think that would be a pretty significant performance hit in many games. Software skinning does it as a tradeoff, it's faster to do that in software.

-[Unknown]

[dbz400]

Regarding prescale and bezier , should prescale run after submitprim() ?

  SubmitPrim(decoded2, quadIndices_, GE_PRIM_TRIANGLES, count, vertTypeWithIndex16, 0);

if (g_Config.bPrescaleUV) {
    // We scaled during Normalize already so let's turn it off when drawing.
    prevUVScale = gstate_c.uv;
    gstate_c.uv.uScale = 1.0f;
    gstate_c.uv.vScale = 1.0f;
    gstate_c.uv.uOff = 0;
    gstate_c.uv.vOff = 0;
}

[unknownbrackets]

I suppose the read UVs are prescaled, but the generated ones aren't, for beziers?

I can't seem to figure out what's wrong outside beziers...

-[Unknown]

[hrydgard]

Ah yes, that sounds right.

[unknownbrackets]

Prescale UV against bezier/splines was easily fixed, but took a bit of confusion to realize that it's not working correctly for render-to-texture (specifically when the texture is not the size expected.)

-[Unknown]