Statistics driver


Doom incorporates the ability to integrate with an external statistics driver: in this setup, the Doom engine is invoked by an external statistics program. At the end of each level, Doom passes statistics about the level back to the statistics program.

Functional statistics drivers compatible with Doom did not actually exist until late 2007, when Simon "Fraggle" Howard finally created one.

Statistics driver support was added in Doom v1.6.


The system works using the -statcopy command line argument. The statistics program passes the address in memory of a structure in which to place statistics. For example, the following would instruct Doom to place statistics in the memory location "1234567":

 doom -statcopy 1234567

The structures used (in C, taken from Chocolate Doom's d_player.h file) for the data is in the following format:

// Structure passed e.g. to WI_Start(wb)
typedef struct
    boolean	in;	// whether the player is in game
    // Player stats, kills, collected items etc.
    int		skills;
    int		sitems;
    int		ssecret;
    int		stime; 
    int		frags[4];
    int		score;	// current score on entry, modified on return
} wbplayerstruct_t;

typedef struct
    int		epsd;	// episode # (0-2)

    // if true, splash the secret level
    boolean	didsecret;
    // previous and next levels, origin 0
    int		last;
    int		next;	
    int		maxkills;
    int		maxitems;
    int		maxsecret;
    int		maxfrags;

    // the par time
    int		partime;
    // index of this player in game
    int		pnum;	

    wbplayerstruct_t	plyr[MAXPLAYERS];

} wbstartstruct_t;

At the start of each level, statistics are then copied into this buffer. There is no trigger activated to inform the statistics driver that this has occurred. Early versions of the statdump statistics driver hooked the mouse interrupt vector as a callback to check the statistics buffer; it was subsequently discovered that the external control driver mechanism could be used to do the same thing in a cleaner way.

This system is only possible because of DOS's lack of memory protection: this kind of sharing of memory is not so easily possible in modern operating systems.

Vanilla regression testing[edit]

The statcopy mechanism can also collect level statistics during demo playback. This allows demos to be analyzed on a large scale through playback and collection of basic information about the game; doing this is useful for regression testing vanilla Doom compatibility and demo desync bugs.

An example of this in practice exists in the form of the statcheck tool, created to perform regression testing for Chocolate Doom. The tool makes use of the huge collection of demos found in the Compet-n archive. Chocolate Doom includes a -statdump command line parameter that outputs the same information as the statdump.exe DOS driver; by comparing the output of the two for a given demo, it is possible to determine (with some degree of confidence) whether a given demo played back correctly or desynced.

External links[edit]