Hi...
As everybody knows, the Banshees have only 1 TMU, and then, the multitexturing is not supported for these cards.
But reading some 3Dfx documentation, I found that it is theorically possible  , using two-pass drawings...
Well, my problem is that I never can't find an glide3x really implemented with this feature, and I want to know if somebody have info/files/etc. about this.
Thanks.

Thx, but as far as I know, 3D-Analizer works over D3D, not over Glide...

You're totally right, this feature is already implemented in OpenGl since 761 version, but it's still not implemeted in Glide (I test Ksmoocky and Colourless Glides). 

Really, I don't know what to do...

Sorry if I'm persistent and thanks again...

DenisF: you're right... every from the dark side...

Patience: well, I just put in contact with different programmers around the world, but nothing yet.
One of them is really capable to do something with this problem (is a great D3D, OpenGL coder, and he is working in a great really functional glide3x wrapper), but without more info it will be a little difficult...
The problem is, no dlls founded, no info founded... nothing...
Can somebody give a little hand...

Thx.

Maybe you're right, but ti implement hack solutions can't really solve the problem. In fact, the apps works and fien, but without multitexturing effects (then, somtemies some transparencies looks wrong, some animated effects looks like an static image, sometimes the textures looks w/o detail, etc.) :\
Looks a these shots... (maybe can explain better what I can say when I speak about 3dfx docs.)

glide3pgm.pdf shots

In fact there is no true multitexturing problem. All the glide games that I tested, except for NFS3 which has a strang work-around for Banshee which reduces graphics quality, otherwise the original is crash-sure.
Multitexturing problem arises seriously only in DirectX 8, 8.1 and OpenGL 1.2+ environments, where there is assured that if the board supports MultiTexturing (which sometimes the driver succeded into lie, perfect Dx7) it should support Bump Mapping. And here the problems tend to go black. All of the modern games, without a hardware disabled dll (3D Analyzer) tend to experience severe crashing chances when believing they can bump map, but they can't allocate a surface for such an operation.
Mostly you are likely to encounter this issue in more and more games, just because everything tend to be done in heavy workload for video cards. Gta3 is a example of problem arising from no true multitexturing in multipass activated: all cars are white, except for taxi's which have a yellow stripe visible (it's the second texture).
However, even in multi-pass texturing, the board is still very fast (compared to the overall workload she has to perform), and is still able of showing a good quality.
So, the main big problem with Banshee multitexturing is that programs don't stop doing bump-map's and shadows, and this causes for more stress (best case), or crash (worst case). Programs don't tend to try to see if there are bump maps or other things available, they just check for multi-texture.
Even the bump-map could be done in Dx8 games (MaxPayne), if there would be a way to fully force the effects to wait do be drawn in a multipass texturing on the TMU.
Solution to all these problems:
1 force a way to show all the efects (might be good just too take pictures, not for playing)
2 force a very big lie, which sincerely I think it's the best approach to most of the eye-candy which are barely expandable (would someone die if there would be no Pixel Shading, or Vertex Shading? I believe not).


The second solution is what I am looking for. But beside 3D Analyze (which is still the best I could find until now), there must be a better option. However, as newer DX9 Apps will be released, I hope they will keep the good work. What is trully important is that the newest CPU's (Athlon mainly) can take a huge workload, so keeping a Banshee in the computer seems a very good idea.

Exactly what games are you talking about?
Remember, one of the big problem with how it looks in games is mostly related to the maximum texture size of 256x256. And this leads to washed-up textures and some of them looking better than others.
For example Quake3. This game is using a large amount of texture memory, which leads to some textures on the wall to look extremely well, in contrast with some of the floor tiles or the places where animation is already done (hole in floor where a blue light appears to shift from left to right).
I conducted a major set of experiments with the problem on texture memory usage, and speed. The biggest test was with NFS5 running in glide (for an unknown odd reason all of the voodoo cards, except for Rush and Voodoo1 are using normally the d3d. And their crappy explanation like it looks better on d3d for voodoo cards, good joke), and there the texture memory usage was begining to show up.
I changed the texture memory allocation from 4Mb to 12 Mb. At 4Mb, good speed and no visual problems. As doing test after test and hitting the 12Mb, problems start to show up. Even if speed was not lower with more than 15% compared to 4Mb texture memory, some polygons wouldn't have a texture on them, and most noticeable, all the effects like alpha-blending where looking horrible.
So 11Mb was the maximum quality that can be achieved on the Banshee (Voodoo3 falls in the same cathegory with the texture memory limits, for those with 16Mb). Also, of interest is that I tested more versions of glide, and discovered that a specific version was showing the best quality possible, and all seemed very clear and crisp.
The test showed up that for a game in 2000, even in glide, 16Mb texture memory is a problem. And all the boards, including the Vooodoo4 and Voodoo5 are limited to the problem with displaying on screen only things that are on the local video memory.
So, I would like you and others to understand that most of the problems with games after 1999 is texture memory. And no voodoo card can do AGP texturing. The solution to most of the problems with voodoo's would be to design a sort of swapping driver that can be totally transparent to programs, and fool them that they have 32Mb of texture whereas it's 16Mb Video Ram and 16Mb system Ram, and allow for maximum speed for textures to be transferred. I know this is not impossible, I heard of a special mini Opengl builded for Quake1GL that could make the game to play at more than 18 frames/second on a Voodoo graphics (voodoo1) with just 2Mb of VideoRam. And this is amazing.
Also, another problem would be to implement on the little driver that would interface to both Directx and OpenGl, a method on how to fast compress textures on System Ram when they are loaded, and then let the video board carry on with calculations and show them as they are, compressed. Even more I would go to the chance that the driver should be able to track all the textures the video card is receiving and store them in a file on disk. Then a program should be able to compress the textures in there if necessary, or mostly important to let them all come into the system memory and be rightly available for the video card to pick them up, avoiding the problems related to where they should be, and how they are accessed. The program should be able to transform each texture stored in the file on disk, to standard formats like 256x256 or less or more, as it is possible. The video card when getting rid of these calculation (which takes the most time) would be able to work very close to how it worked in it's good years.

Problems arises when the Banshee has to do major efects like bump-maps and light-maps. Even then, the most unpleasant problem remains the multiple cycle that the TMU must do, so it's slowing down.

Andrei.

Well, to tell you the truth, I was a little bit dissapointed when I tried the new Koolsmoky Glide. In almost all the aspects, except for the texturing and efects speed, this new glide was dissapointing. It shows clearly that it has been builded for the 32Mb video boards, so speed is not more than usual.
But yes, I know that every time you design a Glide, you are facing a lot of problems. And this is mostly related to how each and every aspect combines to give you the awesome quality that the 3dfx is capable of.
What I really wonder is how the 3DNow! is improving the speed and the visual quality. Why did I say that? Because I maked a little test (unwanted) by using a video capturing device (using software compression by an Ideo video compressor), and a recompression task (transforming an Indeo 5.0 into a Divx movie with Mp3 audio compression), I realised that when the capture ended, I losed only 8 frames in 5 minutes, at 25fps! And this while the recompression has done with normal speed for the task.
At this moment I realised that using both 3DNow! and the CPU processing power, awsome things can be done with 3DNow!. And what is even more impressive is that working on the 3DNow! unit can be done greatly independent from the rest of the CPU. So, by well thinking how to use in parralel the CPU and the 3Dnow! unit, I believe that incredible results in terms of performance can be achieved. I hope you succeed in achieving a good result. And I don't quite agree with you. Banshee is still a capable card. What is her only problem is multitexturing. I have tried some Voodoo3 drivers but I could only use the glide and OpenGL part of them. The files 3dfxv3.dll, 3dfxv3.vxd, and 3dfxv3.drv couldn't work together (I believe these are the names of the files, but I'm not sure), so I couldn't use a newer D3d support. All glides, including the one for V5 worked perfectly. The only problem: speed.
However, even if the Banshee and v3 are not capabel of 512x512 textures, I tested the Creative MiniGl in Quake3. And beside the performance hit, which I believe it's acceptable, the image quality was incredibly good. This way I haved a rough view of what a V4-V5 would do on my computer. So, again I would put a question: is there any chance of you or others to develop glide+opengl interface that could handle large textures for v3 and Banshee? Even if only for testing image quality, it still have lot of sense for me to use it.
As soon as you will release the first new glide dll, I would be very interested to test it... Good luck, and keep up the good work!

Andrei.