 |
forums.ps2dev.org Homebrew PS2, PSP & PS3 Development Discussions
|
| View previous topic :: View next topic |
| Author |
Message |
gabest
Joined: 18 Jul 2009 Posts: 3
|
Posted: Mon Jul 20, 2009 5:22 pm Post subject: TEX1 |
|
|
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: |
[000] x=113.6875 y=365.3750 z=007e866b | s=-0.001451 t=0.006566 q=0.000153 | u=-9.500000 v=42.999996
[001] x=169.8125 y=356.2500 z=007e8617 | s=0.002782 t=0.003994 q=0.000143 | u=19.500000 v=27.999998
[002] x=152.1250 y=355.2500 z=007e8611 | s=0.000922 t=0.003831 q=0.000142 | u=6.500000 v=26.999998
[003] x=313.5625 y=278.7500 z=007e88cf | s=-0.001246 t=0.025268 q=0.000227 | u=-5.500000 v=111.499992
[004] x=308.7500 y=278.0625 z=007e880c | s=-0.001624 t=0.019282 q=0.000203 | u=-8.000000 v=94.999992
[005] x=152.5625 y=328.6250 z=007e8852 | s=-0.017235 t=0.021359 q=0.000211 | u=-81.500000 v=100.999992
... snip ...
[090] x=819.9375 y=283.1250 z=007e8ad1 | s=0.012274 t=0.040889 q=0.000289 | u=42.531677 v=141.683350
[091] x=412.4375 y=268.5000 z=007e8881 | s=-0.019106 t=0.022797 q=0.000217 | u=-87.999992 v=104.999992
[092] 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 (LOD=12.782790) Qmax=0.001909 (LOD=9.033107)
|
Last edited by gabest on Mon Jul 20, 2009 8:04 pm; edited 2 times in total |
|
| Back to top |
|
 |
emoon

Joined: 18 Jan 2004 Posts: 91 Location: Stockholm, Sweden
|
|
| Back to top |
|
 |
gabest
Joined: 18 Jul 2009 Posts: 3
|
Posted: Mon Jul 20, 2009 7:12 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
 |
gabest
Joined: 18 Jul 2009 Posts: 3
|
Posted: Mon Jul 27, 2009 12:53 am Post subject: |
|
|
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) |
|
| Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|