Doom Technical Review

DOOM Technical Review
Ali Salehi
DOOM Technical Review 1

Agenda
— History of DOOM
— Frame breakdown
— Code review
— Parallelism
— Megatextures
— id Software programming principles

Trailer Time

History of DOOM

History of DOOM
Series of FPS games developed by id
Software
— Started in 1992 by John Carmack
developing the Doom Engine
— Rise of the term "Game Engine"
— Unparalleled 3D graphics features at
the time
— Stereo sound

History of DOOM
— DOOM (1993)

History of DOOM
— DOOM II (1994)

History of DOOM
— DOOM 3 (2004)

History of DOOM
— DOOM (2016)

Frame breakdown

Frame breakdown
DOOM (1993)

Frame breakdown
DOOM (2016)
— Uses idTech 6 engine
— Performs 60hz @ 1080p
— Hybrid Forward / Deferred renderer
— Clustered forward lighting
— Shares many technical aspects with
CryEngine
— No D3D on windows, GL an Vulkan
— KISS ideology, minimalistic code

Frame breakdown

Frame breakdown
— Mega-Texture Update

Frame breakdown
— Shadow Map Update

Frame breakdown
— Depth Pre-Pass (%20)

Frame breakdown

Frame breakdown
— Depth Pre-Pass
— Velocity map

Frame breakdown
— Occlusion Queries

Frame breakdown
— Clustered-Forward-Rendering of Opaque
Objects (%25)

Frame breakdown
Objects (%50)

Frame breakdown
Objects (%75)

Frame breakdown
Objects (%100)

Frame breakdown
Objects
— Aditional outputs: Normal buffer

Frame breakdown
Objects
— Aditional outputs: Specular buffer

Frame breakdown
Objects
— Megatexture feedback buffer
generation

Frame breakdown
— GPU Particles

Frame breakdown
— Screen Space Ambient Occlusion

Frame breakdown
— Screen Space Reﬂections

Frame breakdown
— Static Cubemap Reﬂections

Frame breakdown
— Blending Together (Before)

Frame breakdown
— Blending Together (After)

Frame breakdown
— Particle Lighting

Frame breakdown
— Downscale and Blur

Frame breakdown
— Transparent Objects (Before)

Frame breakdown
— Transparent Objects (After)

Frame breakdown
— Distortion Map

Frame breakdown
— User Interface

Frame breakdown
— Temporal Anti-Aliasing and Motion-Blur
(Before)

Frame breakdown
— Temporal Anti-Aliasing and Motion-Blur
(After)

Frame breakdown
— Scene Luminance

Frame breakdown
— Bloom

Frame breakdown
— Final Post-Processing (Before)

Frame breakdown
— Final Post-Processing (After)

Frame breakdown
— UI and Film Grain (Before)

Frame breakdown
— UI and Film Grain (After)

Frame breakdown
— Glass Rendering (Before)

Frame breakdown
— Glass Rendering (After)

Frame breakdown
— Depth of Field (Before)

Frame breakdown
— Depth of Field (After)

Frame breakdown
— Some stats
— 1331 draw calls
— 132 textures
— 50 render targets

Frame breakdown
— Timing

Code review

Code review
— Lines of Code
#LOC DOOM idTech
1
idTech
2
idTech
3
idTech
4
Engine 39079 143855 135788 23939
8
601032
Tools 341 11155 28140 128417 -
Total 39420 155010 163928 367815 601032

Code review
— Lines of Code

Code review
DOOM 3 (2004) source code
— Released in 2011
— Contanins idTech 4
— Does not contain the game data
— C with Classes
— No Exceptions
— No Refrences, uses pointers
— Minimal usage of templates

Code review
I spent a bit of time going through the Doom3
source code. It’s probably the cleanest and
nicest looking code I’ve ever seen.
It’s magic. When we explore the Doom3 source
code, we can’t say: WOW it’s beautiful!

Code review

Code review
— Doom3.exe startup
— Loads the game DLL in its process
memory space via LoadLibrary
— Get the address of GetGameAPI in the
game dll using win32's GetProcAddress
— Call GetGameAPI
gameExport_t * GetGameAPI_t( gameImport_t *import );

Code review
— Doom3.exe view on game DLL
typedef struct {
int version; // API version
idGame * game; // interface to run the game
idGameEdit * gameEdit; // interface for in-game editing
} gameExport_t;

Code review
— Game DLL view on Doom3.exe
typedef struct {
int version; // API version
idSys * sys; // non-portable system services
idCommon * common; // common
idCmdSystem * cmdSystem // console command system
idCVarSystem * cvarSystem; // console variable system
idFileSystem * fileSystem; // file system
idNetworkSystem * networkSystem; // network system
idRenderSystem * renderSystem; // render system
idSoundSystem * soundSystem; // sound system
idRenderModelManager * renderModelManager; // render model manager
idUserInterfaceManager * uiManager; // user interface manager
idDeclManager * declManager; // declaration manager
idAASFileManager * AASFileManager; // AAS file manager
idCollisionModelManager * collisionModelManager; // collision model manager
} gameImport_t;

Code review
— First usage of C++ in idTech
— OO and v-funcs are used, but optimised
using tricks
idCommonLocal commonLocal; // Implementation
idCommon * common = &commonLocal; // Interface
— Templates are only used in low level
utility classes (mainly idLib)

Code review
— Main loop (1/2)
idCommonLocal commonLocal; // OS Specialized object
idCommon * common = &commonLocal; // Interface pointer (since Init is OS dependent it is an abstract method
int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow )
{
Sys_SetPhysicalWorkMemory( 192 << 20, 1024 << 20 ); //Min = 201,326,592 Max = 1,073,741,824
Sys_CreateConsole();
// Since the engine is multi-threaded mutexes are initialized here: One mutex per "critical" (concurrent execution) section of code.
for (int i = 0; i < MAX_CRITICAL_SECTIONS; i++ ) {
InitializeCriticalSection( &win32.criticalSections[i] );
}
common->Init( 0, NULL, lpCmdLine ); // Assess how much VRAM is available (not done via OpenGL but OS call)
Sys_StartAsyncThread(){ // The next look runs is a separate thread.
while ( 1 ){
usleep( 16666 ); // Run at 60Hz
common->Async(); // Do the job
Sys_TriggerEvent( TRIGGER_EVENT_ONE ); // Unlock other thread waiting for inputs
pthread_testcancel(); // Check if we have been cancelled by the main thread (on shutdown).
}
}
Sys_ShowConsole
...

Code review
— Main loop (2/2)
...
while( 1 ){
Win_Frame(); // Show or hide the console
common->Frame(){
session->Frame() // Game logic
{
for (int i = 0 ; i < gameTicsToRun ; i++ )
RunGameTic(){
game->RunFrame( &cmd ); // From this point execution jumps in the GameX86.dll address space.
for( ent = activeEntities.Next(); ent != NULL; ent = ent->activeNode.Next() )
ent->GetPhysics()->UpdateTime( time ); // let entities think
}
}
session->UpdateScreen( false ); // normal, in-sequence screen update
{
renderSystem->BeginFrame
idGame::Draw // Renderer front-end. Doesn't actually communicate with the GPU !!
renderSystem->EndFrame
R_IssueRenderCommands // Renderer back-end. Issue GPU optimized commands to the GPU.
}
}
}
}

Code review
— Renderer

Code review
— Renderer
1. Frontend generates intermediate
world representation and light-entity
interaction table
2. Backend issues GL draw calls
3. GPU executes the commands recieved
from the driver

Code review
Some interesting choices (1 / 5)
— idClass as a common class
— Provides :
— Instance creation
— Type info management
— event management

Code review
— String manipulation library

Code review
— Main code is highly decoupled from the
GUI code
— Again not-so-common practice
— Means that only GUI programmers
have to care about MFC

Code review
— Very good utility library idlib
— Provides utilities to treat strings,
containers, and memory
— Crucial to develop high quality C++
code efﬁciently

Code review
— KISS philosophy
— A good example is id's compiler
implementation
— Just works

Parallelism

Parallelism
— idTech 4
— Decoupled renderer (Frontend and
Backend)
— Async handling of frame-rate
independent subsystems (e.g., input
and Sound)

Parallelism
— idTech 5: Job system
— Simplicity key to scalability
— Job has well deﬁned input and output
— Independent stateless, no stalls,
always completes
— Jobs added to job lists, multiple fully
independent job lists
— Not GP-GPU ready at the time

Parallelism
— Synchronization
— Simple synchronization of jobs within
list through “signal” and “synchronize”
tokens

Parallelism
— Synchronization
— Synchronization means waiting,
waiting destroys parallelism
— Architectural decision: Job processing
given 1 frame of latency to complete

Parallelism
— Jobs
— Collision detection
— Animation blend
— Obstacle avoidance
— Virtual texturing
— Transparency processing (foliage,
particles)
— Cloth simulation
— Water surface simulation

Megatextures

Megatextures
— id Software's virtual texturing solution
— Used since idTech 4

Megatextures
— Key to achieve their unique art style in
vast environments

Megatextures
— Purpose : Use textures much bigger than
V-RAM
— Key idea : use indirection in texture
access
— Similar to virtual memory addressing
— Solution : Dynamically load and keep
parts of the texture that are currently in-
use

Megatextures
— Implementation

Megatextures
— Implementation
— Manage page cache as sparse page
tree

Megatextures
— Implementation
— Resolution : %100

Megatextures
— Implementation

Megatextures
— Implementation
— Resolution : %12.5

Megatextures
— Implementation
— Determine which page to load using
the feedback buffer

Megatextures
— Implementation
— Uses a custom texture compressor
— Runtime transcoder generates blocks
of 40kB DXT texture data from
typically 2-6kB compressed data
— Runs in parallel to texture updates on
platforms that can directly write
texture memory

id So!ware
programming principles

id So!ware programming principles
Warnings!
1. These guidelines are written by John
Romero...
Romero wants an empire, I just want to
create good programs.
— John Carmack
2. They worked in the 90s, some will sound
insane in today's standards

1 / 9
— No prototypes – always maintain
constantly shippable code.
— Polish as you go.

2 / 9
— It’s incredibly important that your game
can always be run by your team.
— Bulletproof your engine by providing
defaults upon load failure.

3 / 9
— Keep your code absolutely simple.
— Keep looking at your functions and ﬁgure
out how you can simplify further.

4 / 9
— Great tools help make great games.
— Spend as much time on tools as
possible.

5 / 9
— Use a superior development system than
your target to develop your game.

6 / 9
— Write your code for this game only, not
for a future game.
— You’re going to be writing new code later
because you’ll be smarter.

7 / 9
— Encapsulate functionality to ensure
design consistency.
— This minimizes mistakes and saves
design time.

8 / 9
— Try to code transparently.
— Tell your lead and peers exactly how you
are going to solve your current task.

9 / 9
— Programming is a creative art form based
in logic.
— Every programmer is different.

Further readings
1. DOOM source code releases
2. Masters of DOOM
3. Game Engine Architecture

Questions?

Thank you!
— nysalehi@gmail.com
— @lightlordhippo

Doom Technical Review

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Doom Technical Review

Semelhante a Doom Technical Review (20)

Último

Último (20)

Doom Technical Review