Difference between revisions of "Statistics driver"

From DoomWiki.org

[unchecked revision][checked revision]
(statdump inclusion)
m (Automated edit - rm .zip to avoid legacy redirect)
(8 intermediate revisions by 5 users not shown)
Line 1: Line 1:
 
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.
 
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.
  
A statistics driver has been written by [[Simon "Fraggle" Howard]] in late 2007
+
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 [[Versions of Doom and Doom II|Doom v1.6]].
  
 
== Technical ==
 
== Technical ==
Line 57: Line 59:
  
  
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. The statistics driver would have to set up its own timer to periodically check the buffer for new information.
+
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.
 
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 ==
 +
 +
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 [https://github.com/chocolate-doom/statcheck 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 ==
 
== External Links ==
[http://www.doomworld.com/vb/showthread.php?postid=692751 statdump by Simon Howard] at [[Doomworld]]
+
* {{dwforumsp|692751|Doomworld thread}} on statdump and the statistics driver mechanism
 +
* {{idgames|file=utils/misc/statdump|title=Statdump external statistics driver}}
 +
* {{idgames|file=utils/misc/ctrlapi|title=Doom External Control API}} (contains an improved, bugfixed version of statdump).
  
 +
 
[[Category:Doom engine]]
 
[[Category:Doom engine]]

Revision as of 04:23, 27 April 2020

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.

Technical

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:

//
// INTERMISSION
// 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

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