The old 3dfx SDK doesn't support MinGW. Get the latest from http://glide.sourceforge.net - the glide3 source tar ball. If you encounter problems, read the compiler output and ponder on it a couple of days. It's usually some simple error. Good luck.

Thanks I downloaded it. But I always get this error drivers/glide/fxwgl.c:919: conflicting types for `wglGetLayerPaletteEntries'c:/MinGW/include/wingdi.h:2805: previous declaration of `wglGetLayerPaletteEntries'mingw32-make: *** [drivers/glide/fxwgl.o] Error 1Do you know what i have wrong?In includes i have this headers:3dfx.hfxdll.hfxglob.hfxos.hg3ext.hglide.hglidesys.hglideutl.hlist.txtsst1vid.hsst2comp.hsst2fxt1.htexus.htexusint.h

Any progress on the MESA 5.1 drivers for the v5 5500's? If you can, please keep us posted, as we are hungry for development news no mater how small.

Hehehe! Almost ready... almost there! There are lots of extensions implemented; there are few which still could be implemented... yet there are many which cannot be properly -- or at all -- implemented in HW Actually, the current Mesa 5.1 driver hits the edge of the VSA-100 capabilities. But don't worry, it will work on earlier Voodoos, as well Really, is not much to tell about it! We made so many changes... well, I forgo... If you need info on a particular aspect, drop a line and I'll try to answer (if memory serves).

Which functions are supported in HW now that were not previously in the 761 ICD? And which functions do you plan on implementing in the future (Hardware or software) that won't be in the initial release? Any suprises on the difference between the 761 ICD and the new MESA 5.1?

Yes ...just an example to make clear: while i'm testing a release of new libraries with Voodoo5 5500, Windows XP, UT@32bit rendering i get more frames for second (about 120 like avg value at 1280x1024) than with GLide, embedded UT dll, at 16bit of course (95fps at 1280x1024).

Now, if the application doesn't use TC wisely, the speed/quality might become speed+quality/lowerspeed tradeoff. Because the actual process of encoding the texture doesn't come cheap! For small textures, the process of encoding/uploading usually exceeds the time of uploading plain image.

Among the well-known compression formats, FXT1 is the best. It can encode 32-bit RGBA with a 8:1 compression ratio. DXT1 encodes 24-bit RGB with 6:1, and DXT3/5 encode 32-bit with 4:1. They say DXTn has better visual quality. Eh... perhaps DXT3/5... I dunno!

So, to take advantage of texture compression, an application usually needs to feed the videocard with already compressed textures! If the application fails to do so, well! it relies on the drivers to compress the textures for it. The burden of real-time compression will most surely be noticed. How ever, feeding already compressed images imposes loss/little compatibility!

A work around this would be to use texture precaching. This means the app sends plain images to the driver and instructs it to compress the textures. Then, the app should query the driver (OpenGL -- whatever) for the compressed texture -- which can be used later.

Some of the above extensions don't even require HW support, because they rely entirely on the GL implementation (GL_ARB_transpose_matrix). Some are just too easy to trick in software to let them slip away. Some do not meet the full spec. That's because the Voodoo hardware has some limitations. For example, texture border... since only on few cases we can SAY it meets the spec, it isn't implemented. OTOH, exotic extensions, like glTbufferMask3DFX is just not worth the effort.

What can be done:GL_EXT_fog_coord - HWGL_HP_occlusion_test - HWGL_EXT_blend_color - HWGL_ARB_occlusion_query - not full specGL_SGIS_generate_mipmap - resample images in SW before sending to cardGL_ARB_depth_texture - not sure about that; perhaps via TextureBuffer?GL_EXT_polygon_offset - already done; can be fastened via grDepthBiasLevel?GL_3DFX_multisample - probably only on Napalm... and probably a few more! I forgot :D

In case you wonder about the 1.2 version above... that's because Mesa doesn't let a particular driver to bump the version at will. One can advertise a certain version only when it meets the required extensions for that version. Voodoo simply cannot implement the required set to become 1.3 compliant. Ohwell, I could fake all those in SW, provided WE WANT TO... and, of course, we'll find the time...

PS: specific texture compression is still on debate, because of possible legal issues. Does anyone knows whether nVidia (or any other company) holds any claim/patent on FXT1?

wow, thats a very good result! i cant wait to see this new ICD released.btw: have you tested it also with Morrowind? i thought there were lots of problems with that game and voodoo cards because it required opengl 1.2...

also, will we see a similar improvement in the direct3d part of the amigamerlin drivers?

wow, thats a very good result! i cant wait to see this new ICD released.

Don't get too excited about it! The s3tc might not get into the final -- AGAIN -- because of legal issues!

Let's make things clear: no texture compression algorithm will go into Mesa at this stage! The real-time compression/decompression will be done -- at best -- through a very special Glide3 library, with embedded Texus2. Bwahahahahaha! This way, you'll have to use our Glide3 at SourceForge.net! And (hopefully) help us to develop it further!

quote:btw: have you tested it also with Morrowind?

Nope! I am not a gamer! I only test games on an as-required-by-friends basis!

quote:also, will we see a similar improvement in the direct3d part of the amigamerlin drivers?