Truth about texture windows

[E}I{]

I, going to explain how exactly Texture Windows are working in PSX hardware,
because all info published on this subject before was incomplete or incorrect.
These results were deducted from PSX GPU behavior with several "buggy" games.

First, here's format of TW control word passed in 0xE2 command
|1F-18|17-14|13-0F|0E-0A|09-05|04-00|
|$E2 | XXX |TWY |TWX |TWH |TWW |

as we can see, there is four 5-bit values

pair (TWX,TWW) describes X coords of texturewindow in texturepage
pair (TWX,TWW) describes Y coords of texturewindow in texturepage

as X/Y parts are working independently, i'll only describe
how X works.

TWW is texture window width mask

11111 in binary form means 8 pixels, 11110 - 16, 11100 - 32, etc.

TWX is texture window position mask
x_of_left_tw_corner = TWX*8

Correction rules(not absolutely sure if they are actually used by PSX)
both of them were discovered by Lewpy with little help from my side

"1 propagation":
if game use "not allowed" mask in TWW parameter all bits above lowest 1
are set to 1
01001 -> 11111
10100 -> 11100 etc.

ariphmetic equation(not optimal) for this operation is:

TWW = (TWW|(TWW<<1)|(TWW<<2)|(TWW<<3)|(TWW<<4)) & 0x1F;

"position alignment":

According to this rule, start position must be always multiple of width

TWX &= TWW;

Usage.
X-texture coord (8 bits) transformed in following way:
3 bits [2-0] left as-is.
5 bits [7-3] first AND-ed with 5-bit NOT TWW value
(so only lower bits will left as they were),
then OR-ed with 5 bit TWX value.
(so higher bits will be set to tw position)
but OR TWW, then AND NOT TWX will work too

this looks like:

x_new = x_old & ~(TWW*8) | TWX*8;
or
x_new = (x_old | (TWW*8)) & ~(TWX*8);

of course, "* 8" can (and will be) replaced by "<<3"

hopw this will be useful for GPU coders. Waiting for corrections/suggestions.

just a question, what are the "buggy" games?

[Lewpy]

The ones I can think of are :-

Final Fantasy 7
Ridge Racer Type 4
Tales of Destiny 2

FF7 has a lot of odd texture window values, RRT4 had some. I think ToD2 had one particular texture window which was odd.
By "odd", I mean they didn't fit the publicly-known rules of texture windows. We now know how to handle them, so they look fine now.

[E}I{]

Yeah. FF7 had 1 tw with wrong placement(bottom of textbox ??).
ToD2 had one or 2 wrong placements as well (3D floor wrap/2D background wrap) in several battle scenes.
RRT4 is only 1 game I tried with wrong sizes in several textures.
Lewpy, you have TW list from my page?
Btw,Lewpy, you tried to think what will happen w/o "bit propagation rule" in RRT4?

[E}I{]

Here's what (IMO) can happen with TWs if "bit propagation rule" is not working:

[Lewpy]

E}I{: I don't understand what you are trying to show The TWin you detail should be 16x32, I think ... ???

[E}I{]

I going to show that there is a case when several texture windows for several areas of texture page can be created and used. In example i posted there is different 16x32 texture window used for each of 8 128x64 areas. As you can see, in RRT4 case if all texcoords are inside of one such area you can think that there is only one 16x32 tw, but in reality there are many 2^(a+b) of them., where a and b are numbers of higher zeros in TWW and TWH. This is derived from AND NOT OR equation i posted before with only alignment rule applied.
parameters 0_C_C_C will create not 160x160 tw at 0,96
and not 32x32 at 96,0 but
four 32x32 texture windows at 0,96 ; 128,96 ; 0,224 ; 128,224. Each one will wrap 32x32 square to corresponding 128x128 part of texture page.

[Lewpy]

So you are trying to say that instead of a single 16x32 texture window, there is multiple 16x32 texture windows (regularly spaced in the texture page) and that the texture co-ords span across all of these texture windows? This would make a 32x128 texture window, but broken in to 8 chunks?
This doesn't sound very likely to me, because it is of no practical purpose. You would need to prove that on a real PSX, I think.

[E}I{]

Well, it looks VERY hardware-like. x-TW can be implemented as 5 two input multiplexors, where A bits are taken from tx coordinate, B bits- from TWX, and 5 1-bit address values are from TW. In cheap hardware like PSX GPU you can always assume that if something can be done with only handful of basic AND-NOT elements, then it is probably done this way.
I'll explain again how it will work. If n-th bit of TWW is "0", then corresponding tx_new bit is taken from tx_old, if "1" - bit is taken from TWX. This is simplest rule possible and it is also works for all known cases so far.

[Lewpy]

I can see what you are saying, but to prove how the PSX really does it would require a test program that tries to set weird data values for the texture window setting, and then see what is actually used by the GPU

[OmniDistortion]

Ow I hope that you get some good results... :embl:
Where can I pick up on the technicality of your vocab? I got lost around the first post here and feel like I shouldnt even join this convo...

Okay ignore this post if you have to cause I feel like I am butting in...

[Lewpy]

This is an open discussion, so anyone can join in

If you want to get down and dirty with the PSX, then a good place to start is here.
We were discussing Texture Windows, which are described in the GPU.TXT file.
Enjoy

[E}I{]

which are _incorrectly_ described in GPU.TXT. And there are also other bugs in this doc