Porting Quake II to MS-DOS pt5 – 3DFX, GameSpy, Quake 2, and The Universe

The following is a guest post / wrap-up of the Q2DOS adventure by [HCI]Mara’akate.q2dos_3dfx_4
In the last update sezero and I([HCI]Mara’akate) tied up most loose ends with regards to Q2DOS.  Specifically: adding in DXE support for mods and cleaning up some code from the early efforts.  During this time, a forum user by the name of ggorts (strogg spelled backwards!) mentioned the possibility of using an old Mesa version with 3DFX support in DOS. I worked on separating the ref_soft from being statically linked into a DXE form and sezero cleaned up any potential problems there.

I mentioned the possibility of attempting the Mesa port to sezero and he thought it was probably a wasted effort and thought making a ref_glide depending only on glide3x.dxe would be a better way to go with less overhead.  I started some initial work on it but quickly abandoned this side-project as I have no real glide (or even OpenGL) knowledge and didn’t have enough time on my hands to play around with it.

Around this time, we also separated the GameSpy browser code into a separate DXE for potential legal issues.  The GameSpy code was publicly released, but never officially GPL’d.  Using this method, other port authors could link against a gamespy.dll to add in the browser capabilities that connect to my GameSpy master server emulator (see QDOS branch for source code to that particular project).

Ggorts also came up with some code for us to be able to finally use the banked modes and Mode-X 320×240.  Though 320×240 Mode-X seems to have some issues with certain emulator configurations, for the most part it works OK.  This also helped us to get some ASM rendering code in from Q1 and help clean up the original mess that was the SVGA driver; a lot of unused code from Q1 was removed and sezero found a clever way to send the video modes list between the game binary and renderer DXE.

In any event, one night I figured I’d take a stab at trying to get Mesa working in Q2DOS.  Checking out the Mesa3d FTP and researching the various changelogs it appears as if Mesa 5 series was the last true effort with Mesa 6.4.x series being the last maintained version with 3DFX specific code.  I got everything to compile but ran into hard-lock issues no matter what I attempted.  During this time, ggorts found out some various small, but now obvious issues. Including increasing the stack size to 1MB and he hard-coded the ref_gl to only work in 640×480.  It took a lot of pleading but eventually he released his source with a static compile for Voodoo 1 cards only as he was testing this on emulators like DOSBox with glide support and PCem dev branch.

I worked on cleaning up the source and he produced some glide3x libraries for me for Voodoo 2 and Voodoo 5 as these were the only cards I personally owned.  Imagine my surprise as I first loaded it up and it actually worked!  And it was smooth with no rendering issues!


At this point, sezero became involved and worked very hard to clean up the Mesa compile issues, including various scary warnings and helped to update us to the final glide3x commit pushed to the development branch and Mesa v6.4.3 which was an unreleased maintenance update for Mesa v6.4.2.

It was a long journey to get the code all working together just right, and a big thanks goes out to the early Mesa crew including Brian Paul, Daniel Borca, and “KoolSmoky” and the mysterious ggorts fellow who pushed hard for this feature.

To recap, Q2DOS from the last time we talked now has:

  • 3DFX Rendering with Mesa v6.4.3 for all Voodoo cards.
  • Separated renderer so it is no longer statically linked.
  • GameSpy is now a DXE.
  • WAV streaming, which is practically free as opposed to the OGG format.


We are about at the end of our Q2DOS journey.  A few odds and ends with Mesa and Voodoo 5 SLI issues remain (though nothing too show stopping) and there’s a small wishlist of some unnecessary features but it’s come a long way from the initial null driver effort!


I have to say it is simply incredible to see how Q2DOS went from a very primitive ‘wow it works’ port to a full featured port.  Simply amazing!

For those who missed the adventure it starts in Part 1, continued in Part 2, Part 3 and Part 4.

15 thoughts on “Porting Quake II to MS-DOS pt5 – 3DFX, GameSpy, Quake 2, and The Universe

      • Yes I downloaded from here and from other place and the same error , just in regular way I type q2.exe from DOSbox and even from real DOS 7.1 (windows 95 version) the same problem , strange that in files there no such directory “pics”

  1. sorry about my many comments but WOW
    in your windows port (why actually you maded win32 and win64 ports :D)
    the same error ! this time in little window dialog box
    (a am with windows XP)
    I tryed this archive q2dos_20151102_win32.7z

  2. I am stupid as fuck! now I realize that I must put those files (your archive) in original windows Quake 2 folder in order to run the game! haha so stupid of me sorry about all my comments! I will try the game 🙂 I vary happy with it

    • Ok, that makes a LOT more sense why it wouldn’t run then!

      Maybe it’s time to re-write the inability to open PAK files as a major error… And maybe for WIN32 to chain them from a steam directory.

      • I copied you DOS files ins original Quake folder it is working 🙂 than I do the same with your win32 files and it working (i noticed that you add new futures 😀 )
        but the strange thing is that from wind32 ver single player crashes ! but in DOS ver single player is ok even sound is working but only in multilayer mod in single it out of memory and no sound (my sound is Realtek ALC888 @ Intel 82801GB ICH7) my be because of the model I do not know you mentioned in readme that new sound cards are not tested enough . I wil test the game in my pentium 1 or 3 with standart sound blaster and voodoo2 card 🙂 to see how it works this is just amazing ! I wonder can DOS and WIN version play together in multilayer 🙂 ??

  3. In q2dos (tested in win32) the load game menu cursor is offset by minus two. This patch to menu.c seems to fix it:
    @@ -2696,7 +2696,7 @@ const char *LoadGame_MenuKey( int key )
    if ( key == K_ESCAPE || key == K_ENTER )
    – s_savegame_menu.cursor = s_loadgame_menu.cursor – 1;
    + s_savegame_menu.cursor = s_loadgame_menu.cursor;
    if ( s_savegame_menu.cursor < 0 )
    s_savegame_menu.cursor = 0;
    @@ -2731,7 +2731,7 @@ void SaveGameCallback( void *self )
    void SaveGame_MenuDraw( void )
    M_Banner( "m_banner_save_game" );
    – Menu_AdjustCursor( &s_savegame_menu, 1 );
    +// Menu_AdjustCursor( &s_savegame_menu, 1 );
    Menu_Draw( &s_savegame_menu );

    @@ -2766,7 +2766,7 @@ const char *SaveGame_MenuKey( int key )
    if ( key == K_ENTER || key == K_ESCAPE )
    – s_loadgame_menu.cursor = s_savegame_menu.cursor – 1;
    + s_loadgame_menu.cursor = s_savegame_menu.cursor + 1;
    if ( s_loadgame_menu.cursor < 0 )
    s_loadgame_menu.cursor = 0;

  4. I noticed that when you saved a game from DOS you can play it only from DOS and when you save from win32 it only works in windows 🙂 if you try to load in in win32 from saved game made from DOS it crashes , and when you try to load from win32 save in DOS versions it do not crash, but tells you in the console “ERROR: Game error: Savegame from an other OS.”
    you DOS version is definitely butch better than win32 one :DDDDD
    I will try again online in DOS, but with voodoo2, and if I find compatible sound blaster on PCI , because on my integrated sound works but when enter in action it stops. I will share the results 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.