D3DQuake is a port of Quake and QuakeWorld to run under Direct3D 8.0.
D3DQuake is currently hosted on SourceForge. View the project summary. You can use CVS to check out the sources, or you can download one of the following ZIP files.
|CVS Source Code Browser||Source Code Browser||n/a|
|D3Dqwcl (QuakeWorld Client) for DX 8||D3Dqwcl.zip||304 KB|
|D3DQuake program for DX 8||D3DQuake.zip||366 KB|
|D3DQuake program for DX 7||D3DQuake073.zip||322 KB|
|D3DQuake program for Matrox cards||D3DQuake06.zip||273 KB|
|Shareware version of Quake 1.06||quake106.zip||8.67 MB|
|Source Code for D3DQuake and D3Dqwcl 0.81||D3DQuake.zip||5.26 MB|
|Source Code for D3DQuake 0.73||D3DQuakeSrc073.zip||2.65 MB|
D3DQuake is a modification of the id Software GLQuake program. D3DQuake is just GLQuake modified to use Direct3D 8.0 instead of OpenGL. Similarly, D3Dqwcl is the GL QuakeWorld client modified to use Direct3D 8.0.
Q: What is D3DQuake?
A: D3DQuake is GLQuake modified to run on top of Direct3D 8.0 instead of OpenGL. GLQuake uses a fairly small (50 function) subset of OpenGL. It only took a few days to write Direct3D versions of these calls. (It's taken quite a few more days to get all the bugs out.)
Q: Why did you do this?
A: Because I wanted to learn about Quake, and about Direct3D, and I thought it would be cool.
Q: In your day job you work for Microsoft. Don't you have an ulterior motive for doing this?
A: Sure! OpenGL is great, but DirectX deserves more respect that it currently gets.. One reason I wrote D3DQuake is that I wanted to see how well Direct3D compares to OpenGL in terms of ease-of-use and performance.
Q: And what did you find?
A: So far, I have to admit that OpenGL's API is cleaner and easier to use than Direct3D. As for performance, I think with enough work, I could match OpenGL's performance. The trouble is that current OpenGL drivers are optimized for running Quake, and current DirectX drivers aren't. Currently the big bottleneck appears to be related to updating lightmaps.
Q: Will D3DQuake work on any video card that supports Direct3D?
A: No. Right now the D3D card has to have DirectX 8 drivers, and 8 MB of RAM. D3DQuake has only been tested on Windows 2000 with the NVIDIA GeForce cards. (However, other users have reported some success running D3DQuake on other video cards.)
Q: Any relation between your code and the controversial 1996 D3DQuake written by a Microsoft summer intern?
A: Nope. I didn't even know about that when I began writing my version. That version was reported to be only 3% to 5% slower than GLQuake. I wish I knew how they made it that fast!
Q: Quake II's source code has been released. Are you going to make a DirectX / Direct3D version of Quake II?
A: Probably not. I was all set to do a Quake II port of my code, but then I played Quake II again. I found that I just wasn't enjoying myself -- more recent FPS games like Halo (on Xbox) are just so much better. Also, while Quake II was innovative for its day, it looks quite dated now. It basicly doesn't seem interesting to me. Sorry!
That being said, I think it would be quite easy to write a DX / D3D graphics driver for Quake II. Anyone who does this is certainly welcome to use any code they want to from D3DQuake!
|Card Notes (alphabetical)|
|Runs for a while, but then the textures get messed up. (If you're using prerelease Windows 2000 Voodoo drivers, you will need to define the symbol USE_D3DFRAME and recompile the application.)|
|Mixed reports. Some users have reported crashes at startup. One user reported that the D3D graphics are actually better than the GLQuake, due to bugs in the Matrox OpenGL driver.|
|Works. (After all, that's the card I use to develop
Latest Win2K beta drivers, version 3.75, fix invisible weapon problem with GeForce.
All the Direct3D-specific code is in the file gl_fakegl.cpp. In addition, I had to make a few changes to the main sources. These changes are #ifdef'd using the preprocessor symbol D3DQUAKE. Presumably, you could merge this code base with any of the other modifications to GLQuake, and it would still work. The only caveat is that if the other modification uses some new feature of OpenGL, you'd have to add support for that new feature.
If you look at the source code for gl_fakegl.cpp, you'll see that it's all pretty straightforward. For the most part, each of the OpenGL calls that Quake uses has a corresponding D3D call. All I had to do was convert the arguments.
To compile, open the WinQuake project in Visual Studio 6.0 or later. Choose either the "Win32 D3D Release" or the Win32 D3D Debug" configuration. Build. The resulting executable can be used the same way as GLQuake.exe.
Current performance of D3DQuake is not very good. On a GeForce card it's about half the speed of GLQuake. VTune tells me that 50% of D3DQuake's time is being spent in the file gl_fakegl.cpp. This is a file that I wrote to convert OpenGL calls to D3D calls.
To speed D3DQuake up further I will have to modify Quake's GL-specific code to make it more D3D aware. VTune tells me that I'm spending at least 10% of my time just copying vertices into buffers to hand to DrawPrimitive. If I use vertex buffers, and change the Quake code to fill the vertex buffer, I bet I could get a significant speedup.
Lately I've discovered that updating light maps on NVIDIA hardware is much slower using NVIDIA's D3D driver than when using NVIDIA's OpenGL driver. This is why the frame rate is so slow when you're in a room with dynamic lighting effects. This is probably due to NVIDIA's texture maps being stored in a non-linear format. Presumably there is some way around this problem, but I haven't figured it out yet.
Pentium III Celeron-A 500, 192 MB RAM
|Software||Windows 2000 Pro SP1|
|3D Accelerator||Generic Geforec 2 GTS 64 MB with beta NVIDIA W2K driver 6.47|
|Command line args||none|
|console args||timedemo demo2|
Pentium II 300, 128 MB RAM
|Software||Windows 2000 RC3|
|3D Accelerator||WinFast GeForce 256 SDR with beta NVIDIA W2K driver 3.6.5|
|Command line args||-window -nosound -nocdaudio|
|console args||timedemo demo2|
|D3DQuake v0.1||39.9||36%||Original D3DQuake.|
|D3DQuake v0.2 Single Texture||43.5||39%||Eliminated some redundant state changes.|
|D3DQuake v0.2 Multitexture||33.5||30%||Yes, multitexture really is slower than single texture. I must be doing something wrong.|
|D3DQuake v0.3 Single Texture||49.6||45%||Shortened code paths.|
|D3DQuake v0.4 Single Texture||50.3||46%||More VTune-directed tweaking.|
|D3DQuake v0.71 Win98||66.0||56%||Use vertex buffers with append mode.|
|GLQuake Win98||129||100%||Full optimizations|
|D3DQuake v0.72 Win98||95.6||74%||Full optimizations|
I'd like to thank id Software, especially John Carmack, for releasing the sources to Quake. And I'd like to thank the members of the DIRECTXDEV mailing list for answering my questions.
10-11-2001 188.8.131.52 First SourceForge Version, based on release 0.81.
01-17-2001 0.81 After many requests, finally implemented D3DQuakeWorld. Also fixed minor bug that caused problems running the DX8 version of D3DQuake in a window.
12-30-2000 0.80 Converted D3D Quake to use Direct X 8.0. Converting to Direct X 8.0 didn't make any difference on speed, but did allow me to throw out several hundred lines of initialization code. The source ZIP file got larger because I include the DX 8 header files and libraries, which are larger than in DX 7.
01-29-2000 0.73 Thanks to a bug report from "The Spectere", D3DQuake new works with more screen resolutions and depths.
01-29-2000 0.72 I turned on full optimization. Wow, what a difference! I think this confirms that a lot of time is being spent converting the graphics from OpenGL format to D3D format. The optimizer did a good job of speeding up this conversion code.
01-29-2000 0.71 Got vertex buffers working correctly.
01-29-2000 0.7 A little faster, with more compile options.
I've spent the week experimenting with different ways of trying to speed up D3DQuake. I haven't had much luck. My best guess is that the speed difference is due to (a) the overhead of converting OpenGL to D3D, and (b) the lack of Quake-specific performance optimizations in the D3D drivers.
01-23-2000 0.6 This version might actually work on a Voodoo card. Let me know if there are still problems.
01-21-2000 - 0.5 Fixed mip-mapping. I had accidentally turned mip-mapping off. Now it's on again. Fixed GL_TEXTUREMODE so it takes effect immediately. (I think this may have been a long-standing bug in GLQUAKE.) Implemented the gamma (brightness) command, but it doesn't seem to do anything on TNT cards. Does D3DQuake's Brightness control work for anyone? Please let me know if it does.
01-16-2000 - 0.4 Fixed a buffer-overflow bug. Rearranged some code, and played with some compiler flags. Clamped color values, which fixed flame brightness. Fixed console transparency to match GLQuake. Changed call to D3DXCreateContextEx to attempt to work around crash on Win98. Avoid calling some OpenGL-specific initialization code.
01-14-2000 - 0.3 Improved redundant state setting. Found out that multitexture is slower than monotexture because of state changes -- GLQuake sorts single-texture triangles by texture, but doesn't sort multi-texture triangles. Installed VTune. Discovered that much of the time is being spent copying vertices from OpenGL format to D3D format. Who knew?
01-13-2000 - 0.2 Fixed bugs. The output looks very close to the original OpenGL now. Improved speed by avoiding some redundant state changes. Implemented multi-texturing (but it's slower than not using it!)
01-12-2000 - 0.1 Got everything working. Released version 0.1
01-12-2000 - Got flash-blending to work. Got the status bar to stay on the screen.
01-11-2000 - Got light maps to work. Noticed that window vs. full screen was already working.
01-10-2000 - Announced to DirectXDev mailing list.
Web space provided by