Resolved: [Bug Report] Allow 8-bit Texture

[Squall Leonhart]

lol... this just reminded me of

Code:

case GR_TEXFMT_ARGB_1555:
                if (ati_sucks > 0) return -1; // ATI sucks as usual (fixes slowdown on ATI)
                factor = 2;
                *gltexfmt = GL_RGB5_A1;
                *glpixfmt = GL_BGRA;
                *glpackfmt = GL_UNSIGNED_SHORT_1_5_5_5_REV;
                break;

[miseru99]

Well I tried both of those now and:

Code:

ps_cb.HalfTexel = GSVector4(-0.55f, 0.55f).xxyy() / WH.zwzw();

breaks the game awfully, BUT this:

Code:

ps_cb.HalfTexel = GSVector4(-0.45f, 0.45f).xxyy() / WH.zwzw();

works just fine O.o, tried both OS and DBZBT3 and seems just fine like with earlier fix

[KrossX]

Can you do a screenshot comparison?
Also, how about (127.0f/256.0f) instead of 0.45 ?

[miseru99]

Well how it looks now on amd cards was already shown, soo just those 3 different values:

DBZBT3:
0.45f - completely fixed
   


127/256f - looks pretty much same as previous
   


0.55f - completely broken
   


Odin Sphere:
Same results as above, at least with those values, couse I tried with

Code:

ps_cb.HalfTexel = GSVector4(-0.5f + 0.05f/WH.x, 0.5f -0.05f/WH.y).xxyy() / WH.zwzw();

and while suprisingly DBZBT3 was fixed by it(really thin hair lol and I'm not joking, looked exactly same with such small change as with 0.45f and 127/256f O.o), OS didn't differ from current svn with it, soo I guess it's a bit more sensitive.

anyway:
0.45f - completely fixed
   


127/256f - same as previous
   


0.55f - completely broken
   

[KrossX]

Nice, I was expecting some difference between 0.45 and 127/256. I would still prefer (127.0f/256.0f) since it differs less from the 0.5f.

[recoder]

Guess its fixed by now. Any Chances seeing it in the Actual PCSX2 SVN.

[salamandar]

i don't have that bug in x9 mode hw and its run more fast in 8 bit texture
i gess its just in the x10 and x11

[recoder]

Yes Quite True. It just happens in Dx 10/11 Mode.

[rama]

The actual value should be whatever makes the ati driver (or card hardware, dunno) round to the value we wanted.
Can you guys check in other steps as well please?
Values to check would be like 255/512, 511/1024, etc.

The smallest deviation from 0.5 is what we may have to add as a workaround.
Still hope pseudonym finds a real fix first though

[pseudonym]

I've worked something out for this. It seems to be a bug with point sampling (or rather I think it's a hackfix in the drivers or the cards for some issue they faced) on ATI cards.

It looks from my testing like they're adding 127/128 of a texel to all sampling coordinates, but I can't be sure this is actually the case. I do have a workaround (which doesn't involve subtracting 127/128 of a texel, that'd screw non-ATI users, nor does it involve messing with HalfTexel) and it'll probably be on svn later tonight.

This is the same issue I found with sampling palettes themselves (entries 254 and 255 got bad values or something) earlier. It also affects any unfiltered textures regardless of the 8 bit textures option.