Note: our questions are in italic, red. Also, do NOT start beating on 3dfx, x-3dfx, Paul or Johnny about this interview. We have interviewed two developers, all opinions herein are their/ours, and NOT 3dfx's or x-3dfx's!

Márton: Could you tell us a little bit about yourselves: who are you, what have you done at 3dfx, what are you doing at x-3dfx now?

Paul: Hi, I'm Paul, until recently a Software Engineer for the 3dfx Belfast Software Engineering Division.

I originally was employed as a placement student (intern) for STB Systems, before the company was bought by 3dfx, and now am amongst the group of engineers in Belfast, Northern Ireland, who suddenly found themselves redundant :). I have worked on a broad range of products including the MVP Series of cards from STB (4 x Riva128s) for the professional market, STB Velocity 4400, 3dfx Voodoo3, Voodoo5, Rampage.

Johnny: I'm Johnny. My alias is bod, who was a children's cartoon character form the early eighties ;-). I was also a Software Engineer in the 3dfx Belfast office.

I joined the STB Systems Belfast office shortly after it opened about 3 and a half years ago. Initially I spent a lot of time working on the tools team, which involved mostly application work. I later transferred to Sustaining Engineering, where I was responsible for updating and maintaining drivers for the current products. Just before the closure of the Belfast office I had started the process of transferring to developer relations work.

Work at 3dfx

Márton: Could you describe an average day you had at 3dfx? You got up in the morning, had your coffee, headed towards the office, and (or... :)...

Paul: Average day. Mmm... Drive my mother to work ;) dead early in the morning and try to stay awake enough to make it to the office. Once in, stick on kettle and then walk to my machine and turn it on, and read my email until the kettle ready. By this early time in the morning (about 8 AM) there are only a few of us in the office so we generally have breakfast together. And then straight to work, grab the latest source from the source control in San Jose, using our 2 MBit internet link :). Possibly using Napster to brighten up my day. Lunch time consisted of searching the local records for vinyl versions of what I had downloaded...

Johnny: My average day... Get up early to beat the morning rush hour traffic on the way into the office. I hate nothing more than sitting bumper to bumper in traffic. When I arrive at work I normally read my email over breakfast and plan my work for the day. As Paul stated the first job involves getting the latest driver source for our source control database. There are usually quite a few changes made overnight because of the time difference between all the various offices.

My day then varies quite a bit. One day I may have to fix a driver bug that occurs in a popular game. Another day I could be helping a developer with problems in a game that is yet to be released. Other times I get to work on new driver features (such as support for the next version in the DirectX API). Lunch is always a time to get some fresh air and a change of scenery. Which means a trip to the chip shop or a workout in the gym (when I'm feeling health conscious).

Márton: If I am correct, you were working on drivers/3dfx Tools for the Voodoo cards. What exactly driver development consists of? Obviously, you have to create the interface for the Glide, D3D and OpenGL APIs. Are you given a certain task of, let's say, creating a module for the OpenGL drivers, or patching a certain bug in the last release, or...?

Paul: I can only speak from the 3dfx Tools side of things. The whole tools project was initiated by the Belfast office a number of years ago, when we were still STB. It's goal was to provide a simple interface to all driver tweaks across a wide range of graphics cards.

As the tools is a long term project, it is a tight team that has been working together for several years. Initially the project was specced, with everyone having a share in authoring the documents. The whole project was split into modules that were divided into the following areas:

• driver controls,
• driver interfaces,
• common libraries for the tools,
• and the tools themselves.

I worked on the full range, but I tended to specialise in the driver controls and driver interfaces.

Johnny: Sustaining Engineering involves fixing bugs and adding new features to legacy products (Voodoo2-Voodoo5).

All bugs are entered in a bug database with a full description of how to recreate the bug and how severe the bug is. Each entry in the database is then assigned to a particular engineer. All major bugs have to be fixed before each new driver release.

The driver development work is not as modular as the 3dfx Tools work. Generally development work can be split between Glide, OpenGL, Direct3D and O.S. In the Belfast office people tend to specialize in certain areas. I mainly work in Direct3D.

Márton: How was the software development for 3dfx split up between you (the Irish and the American team, and between the 35 people (35, right?) in the Irish team)?

Paul: There were 19 developers and 6 Quality Assurance staff in the Belfast office. Of these developers, 1 was multimedia - developing drivers for the Voodoo TV, 6 were the (entire) tools team, and the rest were the Sustaining Engineering department. There are more engineers in the building that originally worked for STB, but they were spun off to form Enseo, for high end multimedia and video products.

All the Tools work was done in this office. For the drivers, the main core was developed by the engineers in San Jose and Dallas, with the Sustaining Engineers taking care of legacy products. By legacy I mean the Voodoo5! The core work and driver set was developed in the states and generally a while before release Belfast took control, fixing any bugs that were left.

Márton: What does driver optimization mean? How do you "tweak" drivers for maximum performance? You change certain core routines to assembly language, or change something algorithmically, or...?

(It was always a mistery to me, that 3dfx and nVidia both could release drivers that improved performance considerably, say, about +20-30% from time to time. How? How can someone do a tweak in the driver that yields this much performance, but was not possible to implement in the first release? Or is this due to the timeframe, that companies have to keep with product releases, in other words, is there no time to fully get to know the hardware before writing drivers?)

Paul: Most of the core 3dfx routines are written in assembly, to get the maximum performance possible, but the rest of the driver was written in C. As far as I know, only the most commonly called code segments were in assembly, as it would take too long to write the entire driver like this.

You are correct, a lot of it has to do with time. Coding large optimised routines in assembly take a lot time to write comparing to writing it in C. Some of the large performance gains have been a result of examining the code generated by the C compilers and spotting segments that could have been done better. There are also tools that were used by the performance team to help them in this analysis (VTune I think was one of them).

Johnny: In addition to what Paul has stated it is a fact that the more you work with a particular piece of hardware, the more familiar you become with it. A better knowledge of the hardware allows software developers to write better code for it, often with tricks and workarounds that improve performance. For example look at the first Playstation games that came out and compare them to the latest Playstation games. The game developers are using the same hardware but they are more familiar with it. I know that a few clever software tricks that significantly improved performance in later drivers.

It is also possible, with some research, to determine what are the most common code paths taken through our drivers when running games. Most time is spent trying to optimize these frequently used routines.

Márton: In what programming language(s) do you write drivers/3dfx Tools?

Paul: The drivers are basically coded in C, with some assembly. The Tools is a different matter. All the code is done in C++, initially making use of MFC, but this was dropped because of problems with multithreading. Other technologies involved in the tools are COM, with substantial use made of the Platform SDK for reference (I know I used it an awful lot).

Márton: How do you beta test your drivers? In a report, ID software said they prefer to test their code themselves, non-stop for days. Do you believe that bugs can be sorted easier by the programmers, or the users?

Paul: In Belfast we have a system in place where a developer will test their own code, until they are certain that it works completely, then we ask the lead of the QA department to assign a test engineer to give it a better test. This system works well, if a programmer has been working on a problem for a long time, he tends to get focused on that particular problem, often neglecting the other problems that may appear.

Dávid: Glide has been buried by online hardware sites several times. Does such an "old and tried" API have any chance nowadays, or it is the other way and those sites were right about taking Glide to the "software museum"?

If Glide is here to stay, why?

Johnny: You can get the best performance out of a Voodoo card using the Glide API. This is because the API was designed specifically for the hardware, it is "closer to the metal" than OpenGL or Direct3D. For an example of what I mean simply compare the performance of a game that supports the Glide API on a Voodoo card to the the same game on a card without Glide support (the Unreal games spring to mind). As far as mainstream games go, developers are moving to Direct3D and OpenGL because they can be used accross a range of video cards. Lets face it developers don't want to code for 3 API's when they can code for 2 or even just 1. Even if developers no longer want to provide a Glide option in newer games it still has its uses. Glide is still good if you want to produce a rapid prototype to see what a game or effect will look like. The code is simpler and shorter than the equivalent in other APIs (athough this is changing with newer revisions of Direct3D).

The Glide API is now open source. I think that it will live on in the open source community and continue to be improved for a long time to come.

Dávid: Why is the installation of Internet Explorer 4.01 SP1 required for the correct working of 3dfx Tools?

Paul: That update of IE contained updates for the windows shell that were necessary for some of the pages to function correctly. In particular, one example that springs to mind, is the tree control of the Advanced Features page.

Dávid: Let's stay at 3dfx Tools: as far as we know, the 22-bit post-filters for the Voodoo series can be reached by setting the "3D Filter Quality" to "High" and the "Alpha-Blending" to "Sharper". But it is rumored, that these post-filters are not used when doing 32-bit rendering on the V4/V5. What is the truth (why?)?

Johnny: Hmmmm ... not sure about this. The 22-bit filter was famously used on Voodoo3 cards to give an output of 22bpp even though the card only supported a frame buffer up to 16bpp. Many reviewers incorrectly compared the Voodoo3 and a competitor's card using screenshots because they failed to take the 22-bit post-filter into account. You need to use something like HyperSnap to get correct filtered screenshots.

I don't think it makes sense to use the same filter in 32bpp mode but I haven't checked what the driver does in this case.

Dávid: Undoubtly, 3dfx was in a very unpleasant financial situation (maybe they still are..?). Following the story of 3dfx it would seem logical that a big video card manufacturer's proposition could have been the solution. Much like 3dfx bought STB two years ago, a big manufacturer (for example, Creative) could have given an offer that solves the financial pressure. What is your opinion about this?

Paul: To be honest I know as much about the financial situation of 3dfx as the person on the street :(

Dávid: Do you believe that a company, as big as Creative, couldn't have considered this option very seriously?

Paul: I doubt that any other card manufacturer would step in and help 3dfx. Creative and any other companies that used to produce 3dfx cards got their fingers burnt when 3dfx bought STB. They have been making their money developing cards based on nVidia chips, so they may have been unwilling to take the risk. (I think personally that nVidia would have been able to put pressure on any company wanting to do this.)

Work at x-3dfx

Márton: Could you describe an average day you have at x-3dfx? You get up in the morning, have your coffee, head towards the office, and (or... :)...

Paul: Very little change :) Except that I now look after our web server and internal mail server and a load of other jobs that were generally done by the network administrators in America. But this is the same for everyone. We have all taken on extra responsibilities to get this project up and running.

Johnny: Don't really know what I will be doing a x3dfx yet :-(

Márton: I know you are in a hard situation regarding x-3dfx, mainly from the legal point of view. I would have a lot of questions about x-3dfx and your work there, but I do not want to be impolite, nor ask you a load of questions you are not allowed to answer. I am really interested in x-3dfx's plans for the future, a bit more precise mission statement that you had on the site on the first day :)))), who and why is legally battling with you, and a lot more.

Please tell us about x-3dfx as much as you can and are allowed.

Paul: x3dfx is basically a large group of developers who were geographically separated from the rest of the company. We have done a lot of work on the drivers and on 3dfx Tools. The working environment we have is superb, especially if you look at what we have been doing over the past few weeks. As a team we have pulled tighter together that we have ever thought possible. It is this we do not want to lose. In Northern Ireland there are divisions that you are probably aware of, and this office contains a superb group of highly skilled people from all sections of community working in a unique and special environment.

Would you like to work here? I would... :)