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. | ||
− | + | 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. | + | 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 == | ||
− | + | * {{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
- Doomworld thread on statdump and the statistics driver mechanism
- Statdump external statistics driver at Doomworld/idgames
- Doom External Control API at Doomworld/idgames (contains an improved, bugfixed version of statdump).