Mr Phillips on 3Dfx drivers

[NH]: Please introduce yourself and tell the people the basics about what you do.
[3DHQ]: I’m Devin Phillips, and I basically run the visible side of 3dhq. While I personally am responsible for, basically, finalizing anything you see coming from 3dhq, as is the case with almost anything, it’s the stuff that goes on with those involved behind the scenes that really makes or breaks an organization. 3dhq was built around the original intention of continuing driver support for 3dfx Voodoo products, most specifically Voodoo3 through Voodoo5, with the occasional release for some earlier or tangent Voodoo product. The only coding I do is the scripting for the 3dhq installer, the vast majority of our coding is done by a small group of talented and determined people who do their work out of kindness for the 3dfx user base.

Originally ”3dfx Underground,” 3dhq, when it adopted its new identity, broadened its goals to include more of the PC news, gaming, and hardware/software community. While our site has been fatiguingly slow in being updated, it’s more than anything because we’re trying to do so many things all at once. Combined with the fact that all of us are volunteers, other factors come first, and with the new year things have been busy elsewhere. I could go on explaining like this, but I’m sure you get the idea.

[NH]: When did you first start working on the 3DHQ drivers and when do you think you will stop updating them?
[3DHQ]: We first started updating drivers a long time ago, as 3dfx Underground. It was late in the year 2001 we realized we had gained the ability to update drivers, and early to middle 2002 when we made our first beta release.

I don’t know when we’ll stop updating them, but I believe it’s safe to say our goals include finally completing the original task we began, which was releasing a completed OpenGL 1.2 ICD. In actuality, by the time all its bugs get fixed and it gets working, it will probably be a 1.3 ICD (of course, no promises). Also we’d like to get complete DX8.1 compatibility completed as well, and hopefully carve quite a bit into DX9 or DX9.1 compatibility into the D3D portion of our drivers before we stop updating them.

After a while, updates won’t make sense. Though theoretically drivers could be updated forever to be compliant with the latest standards, there will come a point at which the fastest Voodoo cards just don’t have the power to run games that use the newest standards, even with fully working drivers. The games would run without bugs, but at extremely low speeds that make gameplay impossible or painful to the eyes. When this time comes, we’ll have to make a decision to stop updating drivers, but until then, we’re still going to do what we can for the 3dfx user base.

[NH]: Do any of you at 3DHQ do any coding of the driver dlls themselves or how would you explain to our readers what it is more exactly that you do?
[3DHQ]: We do code driver DLL’s, as well as related files, including all those files that control the Glide2, Glide3, OpenGL, and D3D API’s. We long ago optimized our INF settings, thanks no doubt to the myriad of people who before us were releasing their own optimized kits that only included INF modification. From their successes and failures and ideas we were able to, along with our own resources, optimize our INF settings to achieve optimal settings. Our hardware control program, 3dhq Tools, takes the place of 3dfx Tools as the interface to hardware settings. It directly controls the hardware, allowing for on-the-fly overclocking and changing of settings that otherwise would require rebooting.

[NH]: Since the source code to the D3D part of the drivers never was released how do you go on about ”updating” the D3D part?.
[3DHQ]: The source code was never officially released, but we have and use it for all the APIs’ drivers. Though we had our own Glide source originally, ported from the official Glide source release, we couldn’t update D3D drivers until we obtained the full source code for the drivers. For interest and verification, I’ve included a screen shot of some inconsequential but verifying 3dfx D3D driver source code.

[NH]: Could you explain the process of making a new driver package to our readers? What parts do you update, how much time goes into tweaking and how many bug testers do you have etc.
[3DHQ]: The process of making a new driver package is difficult the first few times, then becomes easier once some of the core components are built in the first few releases. The DLL’s and other driver files are updated independent of each by programmers, and when finalized betas are completed they are sent to the testing group for run-throughs of various testing strategies, that include benchmarks, massive lists of games, and other programs. If enough progress has been made to warrant a new driver kit to be released, the programmers send to me a polished-up version of their driver files (information such as version numbers, etc., added), and I simply put those files into a simple directory structure I have set up permanently. The newer files replace those from the last release. If the control program (3dhq Tools) has been changed at all, I also put the new Tools installer in its place in the directory structure. The readme and license files are then updated within the directory structure to reflect changes to the drivers themselves.

At first, the next steps were difficult because they hadn’t been done before. Now, they are quite simple. Since I’ve already got a working script that generates the installer from the directory structure of drivers, I simply run the script, and get the packaged installer ready in a folder.

I then send the driver package back to all the programmers as well as all the beta testers for final checks, just to make sure everything is running correctly. We have a pool of about 20-30 beta testers, but not all are always used for every file or package.

When the kits are found to work, they are renamed and uploaded to the web site for distribution.

[NH]: Since some moths back it seems as if the Voodoo cards has had a hard time keeping up. Many new games simply refuse to work and many needs hacks to even run etc. When do you expect that you guys simply have to give up?
[3DHQ]: The Voodoo hardware itself is still capable of running today’s games (though not as fast as the newer cards from other companies), if it has completely working drivers. However, as I said before, the time will come when this isn’t applicable. If games refuse to run, it’s usually because they require a standard that the currently available drivers from 3dhq don’t yet have (full DirectX 8.1 compatibility, OpenGL 1.3, etc.). This can be fixed eventually by driver updates. It will be time to quit when even with fully compatible drivers, games that require updates to standards cannot be run effectively or enjoyably with drivers that are compatible with those updated standards.

[NH]: Do you have the possibility do add basic DX9 compability to your drivers such as DDI 9 and such? And in general how much effort is put into the 2D/GUI-acceleration of the drivers?
[3DHQ]: Yes, we do have the capability to update to DX9 support. However it will take quite some time. As for 2D/GUI acceleration, we do update this occasionally but it’s certainly not our main focus. Most acceleration features are already supported in existing drivers.

[NH]: If we talk current games, how much more performance do you think that you can get out of the good old Voodoos? And how much room is there for quality enhancements?
[3DHQ]: Performance-wise, a Voodoo5 should be able to run today’s games at 40fps. Drivers themselves can only probably add another 5% to the raw performance of the cards, but don’t mistake that with games gaining speed from the eradication of incompatibilities. Games that have driver issues with Voodoo cards could gain far more performance increases with the removal of performance-decreasing bugs.

Image quality can still be improved more. Our work-in-progress OpenGL ICD does in fact have what is an almost completely software-based anisotropic filtering algorithm, as well as improved FSAA. Also we already have updates for Glide3 drivers than in Glide3 and OpenGL (which runs through Glide3, currently) cause the use of 2X FSAA to also enable a higher-sample edge anti-aliasing, giving 2X FSAA almost the visual quality of 4X FSAA, which looks better only because of the higher-grade anti-aliasing of textures within polygons.

[NH]: I just have to ask: what is Revenge, any hints? (Visit http://www.tdhq.net to see what I’m curious about.)
[3DHQ]: Revenge? What Revenge? Oh, that banner on our web site… darn, you saw it… heh. Unfortunately I can’t give you any hints on what it means or is, except that you’ll enjoy it when it arrives.

[NH]: When do you expect your drivers to come out of their beta stage?
[3DHQ]: As per our original plan, the drivers will lose their ”beta” designation when they include the updated OpenGL ICD. This was supposed to happen far earlier, but things got a bit mixed around in the process and did not happen as we originally foresaw. We actually originally thought we’d have OpenGL updates available before D3D updates, but it’s turned out the other way. We’ve decided that we’ve waited this long for the OpenGL ICD and to remove the ”beta” from the drivers’ release names, that we might as well continue to wait as per our original plan.

NH send their best regards to Devin Phillips and the whole 3DHQ team, thanks a lot for your time!