Doom3 BFG Source Code Review: DooM Classic (Part 4 of 4) >>

Doom 3 BFG allows us to play Doom 1 and Doom 2 :) ! From a programmer perspective, it doesn't seem too complicated to integrate Doom Classic engine inside Doom3. A straight-forward approach would be to provide abstraction layers for:

• Inputs :
  • Joystick/Keyboard/Joypad/Mouse.
  • Network.
• Ouputs :
  • Video.
  • Audio.

But Doom 3 BFG is not that simple in the sense that it allows split-screen multiplayers. Something the original idTech1 was never intended to perform.

Doom Classic Architecture

Doom Classic uses a standard design: An infinite loop, interacting with sub-systems where each subsystems is using local or common global variables as follow :



The multiplayer experience was aimed at LANs (Internet was not very widely adopted in the early 90s). There was no client/server: Each player ran its own game simulation and had to wait for inputs from each players before rendering a frame :

    
    while (gameOn)
    {
  
      while(true){
        ReadIncomingIPXPackets();          // Receive network Inputs
        if (allPlayersInputsReceived())
           break;                          // The engine can only proceed when a command for each player has been received.
      }    
      
      DrawScreen();                        // The local simulation state can be drawn to screen.
      EmitSound();
      PlayMusic();
      
    }
    
    

The Challenge

So the architectural challenge is : How do you run several instance of a game with no client/server and many global variables on a single machine ?

A naive approach would be to host 4 Doom engines (loading several times a DLL). Doom3 could them route inputs to the proper instance and also retrieve the framebuffer for outputs.

How does Doom III runs Doom Classic ?

Doom 3 BFG ended up doing something rather elegant: They refactored idTech1 into a state machine which involved modifying 100% of the old codebase :

• All state variables have been moved and are now declared in vars.h.
• That file is included in order to declare a type :

        
        struct Globals {
              void InitGlobals();
              #include "vars.h"
        }
        ;
        
  
        

Fabien is awesome. (Hoi-En Tang)
• That structure is used in an array of four elements:

           
           Globals *globaldata[4];
           

  At any time the Doom engine variable ::g is pointing to one of these elements:

           
           Globals *g;
           

• Changing the state of the machine is done via DoomLib::SetPlayer which essentially set the ::g pointer to the per player gamestate in the array. All inputs and outputs are then involving the currently set player state only.

Higher resolution

It is not immediately apparent because of some old assets (such a the weapon) but Doom Classic is running at three times the resolution (from 320x200 to 960x600). The rendition is still performed with the old school software renderer:

DooM I/O

Type	Implementation details
Video	The Doom 1 renderer writes pixels to a Doom 3 texture that is uploaded to the GPU at the end of each frame via idRenderSystemLocal::UploadImage.
Sound	Direct calls to XAudio2, the low-level audio API.
Player Inputs	Joystick inputs are converted to events and feed a brand new Events System (D_PostEvent,D_ProcessEvents) on a ring buffer.
Filesystem	Abstracted via Doom3 idFileSystem.