I`m only curious. Could it be possible to write GLIDE driver for UT2k3 engine?  :) Because GLIDE now supports texture compresion and the other stuff and i think is very similiar to OGL (features).

Sorry vykupitel, I already raised this topic some time ago on the forums... :(

Can't remember the thread it was on? ???

Needless to say it won't be possible! :'(

Falcon - if you can find the original thread, point vykupitel in that direction... :P

I think it should be possible, but only the developers  could do it
they released a software renderer, and I believe glide would be easier ;)

I couldn't find the mentioned Thread anymore :P

...but I think the Software Renderer was not by Epic, but by 3rd Party (?)

u're right http://www.homelanfed.com/index.php?id=14341

a glide renderer would be fine.. but I just wish there were a 2x64MB Voodoo5 to keep up with the textures  ;D

Hm, since we have a few very capable people working on 3dfx Drivers and Sources now, there's a (wicked) Idea I had :

If those Games, e.g. UT2003 are limited by a Voodoo4/5's Texture Memory (or even the horrible quality on Voodoo3 due the no-DXTC-workaround)...

Why not modify the existing Renderer to accept FXT1-Textures, and have a little Tool re-compress all Texture Files from DXT to FXT1.

I read in the Forum, that something like this is already possible from within a Driver, just not feasible due to performance issues.
Well, with all Texture Files converted to FXT1 in advance, that issue surely would be non-existent, and would probably allow much better Texture handling (I believe FXT1 can be better compressed at similar quality, if my memories serve me right)

Still there is a big problem with Voodoo 3's: we need 2x1024x768x16/8=3 Mb of texture memory used from the startup, only by the frame buffer.

In real figures, you would normally be able to use about 11 Mb of texture memory on a 16 Mb board. The rest 5 megs is the framebuffer, and the geometry/effects space allocated.

A FXT1 compression format gives a tipycal 1:10 compression. Which means that if UT2003 would need 64MB of textures, the used texture space could be around 8Mb(given the fact that some textures compress better, others not), so the idea of using FXT1 texturing is a fesable idea!

But, before any of these dreams could reach the reality, WE MUST FIND A WAY on making the Voodoo3 at least fully Dx8 compatible (even with emulated functions). For example, the Fr019 (Poem to a horse), fails to start on a V3 3000 on Dx8.1 on a Win98SE with latest Amigamerlin. Dx9 installed, brings no better compatibility. In fact, every Fr0?? i saw running, one way or another had texture compatibility problems, and sometimes Z-buffer occlusion. Some texture effects don't appear at all!

So, first we should focus on getting some full DX 8 and OpenGL support (at least 1.1, even if 1.2 is seriously needed). Otherwise, we will never move further to implementing specifically designed tools to convert textres to FXT1, and make the game able to run!

wrote on 09.12.03 at 22:38:51:

I believe FXT1 can be better compressed at similar quality, if my memories serve me right

yaw, right...DXTC compresses to 8bit, FXT1 to 4bit --> lower bandwith use, more bus throughput  ;)

wrote on 14.12.03 at 08:26:25:

perhaps the problem is simply that the V3 supports only the textures 256*256 or only the 16 bits in D3D...

I am not so sure about this: the demo is loading until a certain point, then it suddenly gets out, before the progress bar is at 75%, so no D3D commands are actually issued in there to actually render.

More, "the product" farbrausch demo is working very well, although there are some Z-buffering and missing effects. Why? Drivers are the main problem. I am still not sure if the newest Amigamerlin are able to solve 90% of the problems in Dx8 (Amigamerlin on Windows XP).

So, the Voodoo's problem remained frankly, still the same: drivers, not the card itself is fully the reason of failure. However, I sincerely admire the few ones that have the will and the time to stay and fix the drivers problems. I believe that the main problem at the moment is that noone has fully the plans, and technological papers even for the Voodoo2. In that case, understanding how it trully works is hard, making a thing to actually work: nearly a wonder...

FXT1 has a fixed rate of 32bits -> 4 bits (8:1).
DXT1 has a similar encoding scheme, but it thrashes ALPHA, hence 24bits -> 4 bits (6:1).
DXT3/5 has a lower, fixed compression of 4:1.

But besides the "slowiness" of real-time DXTC->FXT1 converting, there is ANOTHER problem: no matter what they say to you, ANY compression algorithm looses quality! It's a natural law, you cannot gain something without losing another thing. You gain space and loose quality! That is! Engineers busted their heads to reduce impact, mostly based on human-eye heuristics (just like jaypeg/emmpeg does).

So, the textures are DXT1, with a slighter poorer quality than the original. These textures we decompress, and recompress again -- loosing AGAIN quality.

I haven't tested so far, and cannot tell how nice/ugly would a game appear using this technique. Take it as a
"food-for-thought"...

As for the 256x256 limitation, it can be easily worked around. With one condition: not all the MIPS can show at the same time. If that is the case, then more advanced techniques must be employed...