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  :D, 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.

Hi :)

Well, the only attempt to tackle this Problem was done during the 3D Analyzer development last year.

The focus was actually on 4 Layer Multitexturing (Multipass for Voodoo3/4/5), but it might still work for a Banshee as well.

Unfortunately, we didn't test it on a Banshee back then, but you might check it out :

www.tommti-systems.de

Download 3D Analyzer and see if it works. Note though, that 4 Single Pass Texture Layers were accepted, yet only 2 being rendered. And I have no Idea if all that is still valid, since I haven't been involved since almost 1 year now...

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

Oops, yes, that's correct  ::)

It would require additional work then, but you'd have to contact Thomas for that.
He always seemed to focus on Direct3D (which seemed to be his best knowledge area)...

But technically, is should be possible to do it for OpenGL or Glide as well.

The GxpOGL (OpenGL Interceptor) .dll of Colourless ( http://www.users.on.net/triforce/glidexp/ ) might be a possibility as well, but so far is has been developed only for a few, specific OpenGL Workarounds...

Since he's working now with Koolsmoky on a unified, new Glide (possibly DirectX/OpenGL core as well), those 2 are likely very busy and hard to reach...
But it might be worth a shot as well :)

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

*Offtopic*
Did anybody ever notice those super cool names that 3dfx used for their cards? (Voodoo/Rush/Banshee/Avanger/Rampage etc')
Who did ever come up with the idea of using such names on the cards?

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.

Hm, what exactly are you looking for ?

As far as I know, no dedicated Core Files were ever compiled to tackle this Problem (?)

I believe the majority of Problems arise right at the start, then Games/Applications do a DX or OpenGL Capability check, and find "Multitexturing=Not capable"...

The present Drivers already 'should' be able to use multiple Texture Layers, and draw them in multiple passes.

(running UT in Glide, for example, allowed me with the Banshee to select "Detail Textures", which normally run in a single Multitexturing Pass I would guess. So the only Problem remaining, would be that the Driver correctly reports no Multitexturing caps, although the Driver 'could' do it using multiple passes. That alone I think fails some modern Games' minimum requirements.)

I guess that would require a Driver hack (make it report Multitexturing caps in DX and OGL), or a virtual HAL to intercept specific calls (like 3D Analyzer does).

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

http://www.iespana.es/bansheexp/single_TMU_1.jpg
http://www.iespana.es/bansheexp/single_TMU_2.jpg
http://www.iespana.es/bansheexp/single_TMU_3.jpg
http://www.iespana.es/bansheexp/single_TMU_4.jpg
http://www.iespana.es/bansheexp/single_TMU_5a.jpg
http://www.iespana.es/bansheexp/single_TMU_5b.jpg

Hm, the document explains why some Multitexturing Applications still work fine on a Banshe, despite the Single TMU.

So now I see your point :

Seems like the Banshee does slow, multiple passes, where a TexCombine could do the job at almost double the Speed, and minimal loss in visual quality...
(I hope this was what you wanted to point out)

Since this is Glide specific Koolsmoky or Colourless definitely are the best Person to talk to. If anyone knows how to get this implemented, they are !

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.

Well, what can I say?...
about Dx and OpenGL you're totally right (hack solutions are a good way to pass the Banshee limitations but, in fact, these are not real solutions...)
Now, I'm focused to solve (find alternative/possible solutions) to the glide3x problem...
There's to many apps, that doesn't look correct in the Banshees for this problem, but are perfectly playables...
But there's other apps (emus/games/etc) where the problem generates too many errors ... :-/
The Dx and OpenGL problems seems to be very complex to be fixed and the glide3x problem maybe not...
In other words, I'm trying to make the things step by step... ;)

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.

OK, I see your point...
Well, maybe you don't know but I'm betatesr of a project called Glide64 (a glide3x plugin for N64 emulators), and with it I have these kind of problems... (it uses the glide3x interface to the maximum)...
I know Dx and OpenGL limitations (Banshee is an old card), but, for now, I'm only trying to find a solution for this specific glide3x mutitexturing problem.
It can't affect Dx (other thing is opengl: 3dfxogl.dll uses glide3x).
It no depends of the size of the video RAM, or any other parameter, only of the glide3x.dll programming.

P.S.:GLQuake exits and is a good piece of soft, even for Banshees.

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.

People say : V3 drivers don't work with Banshee, but with a simple hack they do work ! You must search for HEX 1A120500 in files 3dfx16v3.drv and 3dfxv3.vxd and replace it with HEX 1A120300. And it works ! Any V3 drivers work with my Banshee. The file 3dfx32v3.dll isn't patched, therefore D3D doesn't work properly (2 TMUs vs 1 TMU).

Well about multitexturing : use the 1.03.04 drivers, because the 1.04.00 Banshee drivers are broken.
A strange thing about 1.04.00 Banshee drivers : Multitexturing doesn't work in 3DMark2000 (but works with 3DMark2001 ?!). I used 1.04.00 V3 drivers, renamed 3dfx32v3dll as 3dfx32vb.dll and replaced the original file in safe mode. What happens ? Multitexturing works ! Emboss Bump mapping 3-pass and 2-pass do work !

Another strange discovery : hex edit file 3dfx16v3.drv and replace all text occurrences "3dfx16v3.drv", "3dfx32v3.dll" and "3dfxv3.vxd" with respective "3dfx16vb.drv", "3dfx32vb.dll" and "3dfxvb.vxd". Finally rename the file 3dfx16v3.drv as 3dfx16vb.drv. Now you can replace the original file with the hacked file. What's new ? Check 3dfx Tools : the video gamma control is no longer greyed out.

I think that Banshee is a Voodoo3 0.35µ. Perhaps the second TMU was disabled, I don't know. But I am sure that 3dfx could have build a unified driver for Banshee/Voodoo3. Why are Glide/OpenGL files unified ?

I have a dream like Martin Luther King : could someone compile for Banshee Win9x driver 4.12.01.0675 from released 3dfx source code ?

wrote on 11.07.03 at 01:02:53:

People say : V3 drivers don't work with Banshee, but with a simple hack they do work ! You must search for HEX 1A120500 in files 3dfx16v3.drv and 3dfxv3.vxd and replace it with HEX 1A120300. And it works ! Any V3 drivers work with my Banshee. The file 3dfx32v3.dll isn't patched, therefore D3D doesn't work properly (2 TMUs vs 1 TMU). Well about multitexturing : use the 1.03.04 drivers, because the 1.04.00 Banshee drivers are broken. A strange thing about 1.04.00 Banshee drivers : Multitexturing doesn't work in 3DMark2000 (but works with 3DMark2001 ?!). I used 1.04.00 V3 drivers, renamed 3dfx32v3dll as 3dfx32vb.dll and replaced the original file in safe mode. What happens ? Multitexturing works ! Emboss Bump mapping 3-pass and 2-pass do work ! Another strange discovery : hex edit file 3dfx16v3.drv and replace all text occurrences "3dfx16v3.drv", "3dfx32v3.dll" and "3dfxv3.vxd" with respective "3dfx16vb.drv", "3dfx32vb.dll" and "3dfxvb.vxd". Finally rename the file 3dfx16v3.drv as 3dfx16vb.drv. Now you can replace the original file with the hacked file. What's new ? Check 3dfx Tools : the video gamma control is no longer greyed out. I think that Banshee is a Voodoo3 0.35µ. Perhaps the second TMU was disabled, I don't know. But I am sure that 3dfx could have build a unified driver for Banshee/Voodoo3. Why are Glide/OpenGL files unified ? I have a dream like Martin Luther King : could someone compile for Banshee Win9x driver 4.12.01.0675 from released 3dfx source code ?

That is certainly a great deal of information, and very usefull! I knew that there are things in which using a magic wound (Hex edit), you discover that the thing actually runs! The hard part is all the time, where to edit, and how. Some of this things work by luck, others no.
I will check this figure, since I own a Banshee. I wonder how much might affect this some of the games and tests already done? Maybe NFSHP2 could work, maybe Unreal Tournament 2003, maybe 3dmark2003.... But all have to be tested.
Also, I don't know what impact might be, and if a game like "Blood Rayne" could work on this card. On a ProSavage DDR, it halts before it starts. Usimg 3dAnalyze, the problem seem to be Hardware TnL. Also inside the game, some of the textures fail to appear (seems that the game wants either a 3 textures/pass, which Geforce2 and 4Mx handles, or a special type of bumpmapping: dot3 or environment). However, looking more closer, the bumpmapping seem to appear, and it's emboss. So, might be 3textures/pass necessary.
Why this thing? Banshee might at it's best support 2 textures/pass (which I doubt), but I don't know how it would handle the multipass texturing, and more, the problems regarding heavy bumpmapping, multitextures and lights. Not to mention, the limit of 16Mb Video Ram, and the imposibility of using texture compression.
This might seriously hurt performance (6-10fps expected in 800x600 resolution on an AthlonXP 1700+).
I heard that the voodoo's (before 4th generation) have a YAB narrow channel texture compression. But I never saw a game or anything to activate or use this thing. More, I don't know if there is anything in the drivers itself. S3 or DXT compression, might be a nice help for the Voodoo Banshee/Voodoo3, but the real problem would be: who will handle this? CPU or Voodoo, but most important, how it will, and how fast...
I saw inside the glide3x file, sections which might reffer to testing purposes: show polygons, fps, but I don't know how to activate them.

Well I wanna give some explanations about HEX 1A120300 : PCI VendorID is 121A for 3dfx and PCI DeviceID is 0003 for Banshee, 0005 for Avenger (aka Voodoo3).

Here more complete instructions

How to modify V3 files
----------------------
3dfxdrv.ini :
replace DEV_0005 with DEV_0003

voodoo3.inf :
under [Mfg] add %DeviceDesc%=Driver.Install,PCI\VEN_121A&DEV_0003
you may delete all other strings

3dfx16v3.drv and 3dfxv3.vxd :
you need a hex editor, replace HEX 1A120500 with HEX 1A120300

3dfx32v3.dll :
you need a hex editor, replace HEX 5FFA1E00 with HEX 4F1A0000

locate after that string HEX 0300 (Maximum Textures Blending Stages), replace HEX 0300 with HEX 0200

locate after that string HEX 0200 (Textures In Single Pass), replace HEX 0200 with HEX 0100 *ONLY* for V3 drivers released before V5 drivers which autodetect that

locate after that string HEX 02000800 (Maximum Texture Coordinates), replace HEX 02000800 with HEX 01000800

Now you can install V3 Driver Set, but the modification is a work in progress. It works, but although DX capabilities are correctly reported, the driver is still using 2 TMUs in D3D...

Very nice, I will try it soon. This deal of information is great! It is one of the very few circumstances in which you can find so much things, and so well explained.
If you are an experienced user of Hex edit and other figures on computer technology, as it seems, it is very good, and you might be one of the few to release new drivers and solve problems with video cards, in the way that few can actually do.
As I've seen, in most of the test that regard the newer games, the big problem with Voodoo's is the limit of the polygons output. Tests with GTA3 and GTA3 Vice City, proved that with or without textures is a matter of 2-3 fps on average faster. But when looking at the way in which the game is designed (geometrically), you can see tons of triangles, polygons, lines. All of these must be drawn by the videocard even if they can be seen or not. For instance, the tunnel under the other part of the city in Vice City is viewable (in wireframe mode, so it is computed), but you can't see it normally from the air, when playing the game normally. More, the water is always drawn under the street!!! and the waves are also drawn!
So, generally, most of the happy users of 3dfx, must be given a help, by using an algorithm oposed to true-form, one that drastically reduces the polygon number in games. And I've seen a program that has a function like this, and handles quite well, unfortunately you can't use models from 3DSmax, to see other type of 3d models.
Designing such a fast algorithm, combined with the SSE, 3DNow! instructions, might give a 3dfx Voodoo cards a giant step into the future, and a more than fair approach to their true value.
The first to include such functions in a d3d or an opengl part of the drivers, would surely be more than praised for what he has done...

Yep, Hex-Editing will always be like punching new holes in the dark...

...unless you exactly know what to look for (e.g. a clear, unencrypted number like a Vendor ID)

The guys who made 3DMark2000 did help me. 3DMark2000 gives us many infos on 3dfx32vb.dll, especially on DirectX Flags i.e. Texture operations 0x00001A4F (HEX 4F1A0000 in 3dfx32vb.dll). After Fill-Rate Benchmark click on "Show Details".

By the way, I am the one who send you (FalconFly.de) the Creative MiniGL patch.
HEX value is in fact 3D0211000074
----------------------------------------------------
3D02110000              cmp eax, 00001102
74xx                    je xxxxxxxx
----------------------------------------------------
Program reads SubVendorID and compares the returned value with the expected value. There are 6 occurrences. You can simplify by only seeking for HEX 0211.

Trust me, 3Dfx Banshee isn't dead !

Regards

The best thing to do is to download the 3dfx source code available here
http://www.personal.psu.edu/users/g/e/gec125/3dfx_source_code.rar
If you are a good programmer, please build the W9x driver 4.12.01.0675 for Banshee and Voodoo3/4/5. Thanks !

Regards

;D
PHOENIX!!!!... you're a genious man, thx for all the info....
I'll try to make an experimental beta driver set now with all this info.
But I have a question for you: it's possible to enable multitexturing in glide too?, how?

Additional info: in this last month finally I can obtain a compiled version for Banshee users of the libs mesa 5.0.1. Currently all the OpenGL features are present in this new opengl dll, but most of them are not supported well by the drivers yet... I think that all can be implemented in soft mode to compensate these limitations (for now)...

Yes and no. I explain. In the registry add in Glide section this string
FX_GLIDE_NUM_TMU=2
Now multitexturing is active, but there are problems : some screen areas are black. But V3 OpenGL file from Return to Castle Wolfenstein works great with my Banshee...

You can try FX_GLIDE_DEVICEID=3 (Banshee) 5 (Avenger)
FX_GLIDE_DEVICEID=5 and FX_GLIDE_NUM_TMU=1 : it works, but no multitexturing... This is the proof that Banshee is a Voodoo3 1 TMU.

Or is it only a fake ? Velocity 100/200 cards report 1 TMU, but in fact they sport 2 TMUs. Is it the same for Banshee ? I do think so. The answer is somewhere in the VGA BIOS inits...
About this : in the BIOS SETUP of your Mainboard you can enable/disable L2 cache ! Any benchmark/diagnostic program will report no L2 cache, although L2 cache is physically present and only disabled.

Regards

Well, since under Linux, the Banshee Driver is the same as the Voodoo3 Driver, that would support this statement.

I still believe some internal differences exist, considering the long timespan inbetween the release of the 2 cards.
(that would explain the inability to simply use an unmodified Voodoo3 Windows Driver on the Banshee)

But whatever these differences are, they were treated accordingly under Linux, so it can be done.

@ Patience
You are right !

Do you think that a registry string in D3D section exists ?
i.e. SSTH3_NUM_TMU=1  ???

By the way : have you ever noticed that Velocity 100/200 has got a 32K VGA BIOS like Banshee, whereas Voodoo3 has got a 64K VGA BIOS ? Not only that : the PCB layout from Velocity 100/200 is similar to Banshee. Perhaps the VGA BIOS from Velocity would work with Banshee boards after some changes like Core/RAM speed...

It might be any chance to use Voodoo4,5 drivers on a Banshee? Most of the newer games are having serious problems with the Voodoo3, so upgrading from a Banshee to a Voodoo3 driver would only solve a little part of these problems.
For instance, GTA3 and Vice City, both have serious problems with the Banshee/Voodoo3 cards in terms of compatibility. The well-known problem with the game that stucks after a random period of time, helped heavily, is certain to occur if you are watching a huge are (you are on top of a building, and you see lot of things around), not to mention the slow speed of rendering (mostly caused by the geometrical overusage of the game).
A clear solution would be to use Voodoo4/5 drivers on the Banshee. Also, this would permit the card to run 3dMark2003 and Unreal 2003, with good chances to run even Blood Rayne...

You can use a modifed VSA-100 driver like 1.04.01-beta, but the new features won't work for Banshee/Voodoo3 ! Banshee and Avenger are SST1 chips, Voodoo4/5 are SST2 chips.

A solution would be to compile w9x driver 4.12.01.0675 (latest release was 4.12.01.0666) for Banshee, Voodoo3 and Voodoo4/5. After that you must learn hardware tricks & tips. Do you remember Commodore Amiga ? The Demomakers could make dreams come true !
Hardware TnL isn't a utopy ! 3dfx chips were not designed to support this feature, but... who knows ?

Hope !!!

Regards