Harharhar... that must be the reason why we use it in our OD funcs, eh?Pete's softGPU is derived from Duddie's original softGPU, and that had some "dubious" techniques for triangle rendering
hehe oh man lol......I don't know how to program a plugin......Well U can see my website....I have got some great words for you in it......!So as I am done with my website.....U can come with your plugin so I can put some more excitment in my website.........eheh........j/k.........!Originally posted by Lewpy
How about after you've done yours?
What can I say, we lurk in mysterious placesOriginally posted by kazzuya
Cool we got Lewpy and Pete involved 8)
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.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.
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?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 ).
Oh, don't we just love Tekken3 and it's animated 4-bit palette tricks2) 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).
Yes, a nice advantage.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.
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 senseToo bad the framerate was sad..
So.. don't try that at home !
Harhar... that's nearly my dynamic caching strategy... just not per polygon, but for every used small texture rect (or maybe that's what you are meaning with 'polygon')... but I don't use one big texture, but sort the texture rects again in N 256x256 textures (N depends on the cards vram), since that's the size that should work on all consumer gfx cards.My approach was then a raw power one: generate 16 bit texture pages with one rectangular sub-texture for each polygon.