[Lewpy]

Originally posted by kazzuya
Cool we got Lewpy and Pete involved 8)

What can I say, we lurk in mysterious places

Just for fun, some time ago I tried a new approach for a DX8 plugin. Since my TNT2 doesn't support palettized texture, my main issue was to reliably deal with dynamic palettes. My approach was then a raw power one: generate 16 bit texture pages with one rectangular sub-texture for each polygon.
Basically for every polygon I'd allocate some space in VRAM with the required texture and then render all those polygons later.
Unfortunately texture uploading isn't very fast at least when using DX8 lockrect without any kind of double buffered DMA trick.

Thankfully, I've never had to attack this problem head-on, since Glide has solid support for paletted textures. The only bummer is it doesn't support 4bit paletted textures, but that can be simply worked around.

The advantage of that were:
1) Only need one NxM texture. For example a 512x512 texture can handle up to 256 polygons if the PSX textures are about 32x32 ( (512/32) * (512/32) = 16 * 16 = 256 ).

Is the advantage of this simply because it is one texture? ie. one is easier to track than many, and it is quicker to upload than many small textures?

2) Brute force palette to 16bit conversion for every polygon guarantees success with dynamic palette (fog or just a billion 16 color palettes like in Tekken 3).

Oh, don't we just love Tekken3 and it's animated 4-bit palette tricks

3) Because every polygon's texture generated is converted from PSX RAM into a secondary destination one can afford the luxury or padding the texture margins with a little more work therefore eliminating the issues with bilinear grabbing the texels of nearby textures.

Yes, a nice advantage.

Too bad the framerate was sad..
So.. don't try that at home !

You don't mention anything about inter-frame caching: are you saying you were generating this large texture and uploading per FRAME? OUCH! That reminds me of my early support for texture windows: watch Ridge Racer 4 crawl I would have thought, at least, you would need to cache the small texture between frames, and re-use if possible. Even if you have to generate a new "big" texture. If you are really clever, you could just copy on the new textures over the patches of old textures in the "big" texture, and then upload, thus not having to generate the whole "big" texture per frame ... if that makes sense
I think I could adapt my texture caching code to handle controlling converted paletted textures: I would need to add a variable to the cached area, dictating the size and location of the palette (on top of x, y, s, & t). Texture type (4/8/16bit, currently tracked) would merge in to size of palette: don't need both. The garbage collection routine would have to be modified not only to check for VRAM modification to the texture area, but also to the palette location. That's not too bad a change, just a little bit more checking.
It took me a long time to get my "dynamic texture caching" to work correctly, and without crashing Lots of fun with pointers, pointers to pointers, pointers to pointers who used to be pointers and are now not

Anyway, I am sure Pete can be very insightful about this caching problem, as he has to deal with it