MesaFX

[koolsmoky]

Is the SDK right version or I have something wrong? I started compilation with command "mingw32-make.exe -f Makefile.mgw libgl"

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.

KoolSmoky

[vykupitel]

Originally posted by koolsmoky

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 `wglGetLayerPaletteEntri
es'
mingw32-make: *** [drivers/glide/fxwgl.o] Error 1
Do you know what i have wrong?In includes i have this headers:3dfx.h
fxdll.h
fxglob.h
fxos.h
g3ext.h
glide.h
glidesys.h
glideutl.h
list.txt
sst1vid.h
sst2comp.h
sst2fxt1.h
texus.h
texusint.h

and in lib:
libglide3x.a

AthlonXP 2100+@2700+, 256MB PC266@333 RAM,MSI MS-746F Ultra,
Voodoo5 MAC PCI + Voodoo5 6000 rev. 3700 A

[bloodworm]

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.

[Amigamerlin]

I think Daniel And Koolsmoky can answers better then me .


Amigamerlin
3DFXZONE MODERATOR
Powerd By Voodoo5 6000

[dborca]

Originally posted by bloodworm

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).

Regards,
Borca Daniel

[bloodworm]

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?

[qrazi]

so it will add a lot of compatibility to opengl applications, will it also improve performance?

[Glide]

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).

Bye bye

[dborca]

This is meant to answer a question of some of my friends, and is not intended as an answer for the above questions.

Texture compression ususally means speed/quality tradeoff. Compressed textures usually have slighter poor quality. But the memory storage decreases (both video and host). And, of course, the bandwith...

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.


Regards,
Borca Daniel

[dborca]

Originally posted by bloodworm

Which functions are supported in HW now that were not previously in the 761 ICD?

Man, the 761 ICD was by no means a complete OpenGL implementation! Well, ours have this "sickness" as well, but we at least, strive for compatibility!

Any suprises on the difference between the 761 ICD and the new MESA 5.1?

Yes, speed, graphics quality, better OpenGL compliance.

Here is the more or less complete status of the Mesa 5.1 (I'm sure Koolsmoky will kill me for this ).

GL_VERSION: 1.2 Mesa 5.1
GL_RENDERER: Mesa Glide v0.51 Voodoo5 5500 (tm) 2312kB FB, 28MB TM, 2 TMU, SLI
GL_VENDOR: Brian Paul
GL_EXTENSIONS: GL_ARB_multitexture GL_ARB_point_parameters GL_ARB_texture_compression GL_ARB_texture_env_add GL_ARB_texture_mirrored_repeat GL_ARB_transpose_matrix GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_func_separate GL_EXT_blend_subtract GL_EXT_clip_volume_hint GL_EXT_compiled_vertex_array GL_EXT_copy_texture GL_EXT_draw_range_elements GL_EXT_packed_pixels GL_EXT_paletted_texture GL_EXT_point_parameters GL_EXT_polygon_offset GL_EXT_rescale_normal GL_EXT_separate_specular_color GL_EXT_shared_texture_palette GL_EXT_stencil_wrap GL_EXT_subtexture GL_EXT_texture GL_EXT_texture3D GL_EXT_texture_compression_s3tc GL_EXT_texture_edge_clamp GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_lod_bias GL_EXT_texture_object GL_EXT_vertex_array GL_3DFX_texture_compression_FXT1 GL_APPLE_packed_pixels GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_INGR_blend_func_separate GL_MESA_window_pos GL_NV_light_max_exponent GL_NV_texgen_reflection GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod

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 - HW
GL_HP_occlusion_test - HW
GL_EXT_blend_color - HW
GL_ARB_occlusion_query - not full spec
GL_SGIS_generate_mipmap - resample images in SW before sending to card
GL_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

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?

Regards,
Borca Daniel

[raffa]

hi there!

very good and interesting news here

i compiled the latest mesa5.1 source with msvc .net (student license)
went fine, got a few warnings but no errors.

but what to do next? just copy the dlls to the app does not work, but should i assume?
so i just want to know how to use this...^

update: with some games it works but ultra slow (like 0.5 fps)

[vykupitel]

I think that FXT1 is opensource, isn`t it?

AthlonXP 2100+@2700+, 256MB PC266@333 RAM,MSI MS-746F Ultra,
Voodoo5 6000 rev. 3700 A1

[dborca]

Originally posted by raffa

with some games it works but ultra slow (like 0.5 fps)

You must have been doing something wrong I was just able to play Call of Duty last night

Regards,
Borca Daniel

[qrazi]

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?

[dborca]

Originally posted by qrazi

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!

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!

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

I really don't know, as I'm not doing DirectX! I'm too damn gcc biased to do it!

Regards,
Borca Daniel