TEX1

gabest · Post by **gabest** » Mon Jul 20, 2009 5:22 pm

I'm looking for a someone who could help me clarify how the TEX1 register really controls texture filtering. Preferably with test elfs :P I'm too unexperienced to create any and don't have the needed equipment other than rewritable discs... :( So, it would be a great help for me.

The problem is that there are cases when gsuser and reality do not match. For example in culdcept (3d background of the "battle scene") the followings are set:

LCM = 0 (=> LOD = K + (log2(1/|Q|) << L))
MXL = 0
MMAG = 1
MMIN = 0
L = 0
K = 0
Q of the vertices around 0.0001.

As I calculate LOD > 0.0f => MMIN => point filtering, ... while it can be clearly seen using bilinear, hmm.

I assume << L just means * (1 << L), this is also not very well defined by gsuser. How could a float be shifted logically?

Anyway, given these values I can't find a way to get LOD <= 0.0f. Maybe there are special cases, L = 0 could make the result of shifting to zero, but without testing that's only my speculation.

K is also interesting, defined as 1:7:4 (signed integer and 4 bit for the decimals, is that right?). In this example the correct interpretation does not affect anything, as it is 0, but may other times.

Edit:

Here is the vertex data of one triangle batch of that scene I was talking about:

Before & after: http://guliverkli.sf.net/culdcept.jpg (see the yellow pixelated terran, that should be smooth, if LOD was <= 0)

Code: Select all

&#91;000&#93; x=113.6875 y=365.3750 z=007e866b | s=-0.001451 t=0.006566 q=0.000153 | u=-9.500000 v=42.999996
&#91;001&#93; x=169.8125 y=356.2500 z=007e8617 | s=0.002782 t=0.003994 q=0.000143 | u=19.500000 v=27.999998
&#91;002&#93; x=152.1250 y=355.2500 z=007e8611 | s=0.000922 t=0.003831 q=0.000142 | u=6.500000 v=26.999998
&#91;003&#93; x=313.5625 y=278.7500 z=007e88cf | s=-0.001246 t=0.025268 q=0.000227 | u=-5.500000 v=111.499992
&#91;004&#93; x=308.7500 y=278.0625 z=007e880c | s=-0.001624 t=0.019282 q=0.000203 | u=-8.000000 v=94.999992
&#91;005&#93; x=152.5625 y=328.6250 z=007e8852 | s=-0.017235 t=0.021359 q=0.000211 | u=-81.500000 v=100.999992
... snip ...
&#91;090&#93; x=819.9375 y=283.1250 z=007e8ad1 | s=0.012274 t=0.040889 q=0.000289 | u=42.531677 v=141.683350
&#91;091&#93; x=412.4375 y=268.5000 z=007e8881 | s=-0.019106 t=0.022797 q=0.000217 | u=-87.999992 v=104.999992
&#91;092&#93; x=819.9375 y=267.3125 z=007e8851 | s=0.022367 t=0.021326 q=0.000211 | u=105.840271 v=100.914368

Qmin=0.000142 &#40;LOD=12.782790&#41; Qmax=0.001909 &#40;LOD=9.033107&#41;

Post by **emoon** » Mon Jul 20, 2009 6:00 pm

Check this post from Sparky over at the ps2l forums:

http://playstation2-linux.com/forum/mes ... g_id=47709

gabest · Post by **gabest** » Mon Jul 20, 2009 7:12 pm

That certainly gives a good idea on how K/L/Q can be calculated, but my problem is after that, when rendering. The reason why the GS still chooses MMAG instead of MMIN with those values.

gabest · Post by **gabest** » Mon Jul 27, 2009 12:53 am

Ok, tested it myself... it was MXL = 0, when this is zero MMIN is ignored and only MMAG is used.

(btw, the GIF_SET_TEX1 macro has a bug, strips the msb of TEX1.K, masks one bit less)