DMDX Help.


Test Modes

    DMDX has various test modes, turned on with the <TestMode> parameter and frame option. The value of this keyword selects which test is to be activated. Test modes that gather data now dump their display to the diagnostics.txt file and also the job's data file when the test mode changes or when the job is stopped. Current tests are:

0Turns off the test mode.
1Turns on the Display Test Mode. When DMDX is waiting for a request and there is no active display it displays a test screen with information about how well DMDX is keeping track of the vertical retrace.  Contains the same sort of information as the TimeDX Time Video Mode display.
2Turns on the Millisecond Callback Latency test. When DMDX is waiting for a request and there is no active display it displays a test screen with information about the millisecond callback latencies. Currently a particular routine, called millisec() should be called by the OS every millisecond, it is responsible for polling input devices and turning clocks on and dispatching sound event related tasks. Win32 not being a real time OS this does not in fact occur at exact millisecond intervals and can in fact have large latencies, this test mode allows one to see exactly what latencies are involved. The latencies reported by this test measure the error in polling the PIO12 and Joystick (and RawJoystick) input devices (amongst other things) and not interrupt driven devices like the keyboard or the mouse (see testmode 6).
3Functionally equivalent to test mode 2 but it only monitors millisecond callback latencies while the display is active.
4Turns on the DirectDraw Sleeping Interval test. Prior to DMDX flipping the display so the next display buffer becomes visible the vertical retrace routine sleeps for as long as it calculates that it is safe to sleep for to allow the movingimages() routine to move something into the last display buffer to deal with situations similar to the tachistoscopic acid test (many single tick frames) as there is no other time under those circumstances to move those displays. This test measures whether the machine is in fact sleeping for the requested amount of time as a sleep here of longer than intended would generate a display error.  Test is superfluous and generates no data using the 3D rendering path.
5Functionally equivalent to test mode 2 but it only monitors millisecond callback latencies while DMDX is waiting for an input.
6Turns on the Positive Response Latency test.  This test and others like it require external hardware to close a key contact on a regular basis. When DMDX is waiting for a request and there is no active display it displays a test screen with information about the positive response latencies. This test was designed to enable us to measure the variability (if any) induced by the OS by measuring the keyboard autorepeat keystrokes, however due to the fact that DirectInput filters a keyboard's autorepeat keystrokes the test looses most of it's use (grrr). If you build a circuit that closes a switch on a regular basis you could see what variability (if any) is present in RTs from various devices (see Input) without having to trigger things from the CRT thus eliminating a small source of variability. If you use the PIO12 input device it's inter-trial polling interval should be set to every millisecond (instead of every ten milliseconds) with <id pio12 1,1>.

It should be noted that test mode 6 is an extreme worst case scenario as a new frame is being displayed as soon as the previous is assembled (on most machines this would be every other tick), a more realistic test is to use test mode 8 on items similar to those used in your experiments.
7Functionally equivalent to test mode 6 but it only monitors positive response latencies while the display is active.
8Functionally equivalent to test mode 6 but it only monitors positive response latencies while DMDX is waiting for an input. In order to make this test mode have any meaning at all DMDX will never actually see a response, it will simply record the latency data.
9Functionally equivalent to test mode 6 but it stores RTs instead of positive response latencies. This is designed for use with a phototransistor triggering off a white display some fixed number of ticks after the clock is turned on that is hooked up to some response device allowing a real world test of latency and variation of different response devices. The test only stores positive RTs (ie, correct ones) should someone ever want to use the test for another purpose.
10 Input Device button monitoring.  With TestMode 10 active any new input devices will list all their buttons in the diagnostics (both on screen and in diagnostics.txt), any button mappings in the item file will be listed and as buttons are pressed their names will be listed.  Along with the human readable name the decimal values of each character in the button name are listed to facilitate debugging any weird font issues.  As of DMDX version 5.1.3.0 the GUIDs of the devices DMDX sees and attempts to use are displayed as well.
11 Turns on wire frame rendering when using the 3D rendering path when used in the body of the item file, otherwise when used in the parameters (an accidental effect that turns out to be handy) it just overrides the background fill color thus showing the contents and size of textures presented (otherwise they're against the same color fill and you can't tell just how much of the screen DMDX is manipulating).  Similar to the alternate display in the TimeDX Video Mode Selection test and the Digital Video test turning test mode 11 on will render the background as gray and only the edges of the triangles containing the DMDX display will contain the display they would have.
12Monitors duration of millisecond callback, should always be 0.0ms or at worst 0.1ms. This is a useful test when using InstalCal drivers and the QPIO12 input device as the polling of the devices is done in the callback. If the duration of the callback rises nastily when using QPIO12 only polling every other millisecond should be considered (see <id>). Fortunately all machines tested so far have negligible values in this test.
13 Turns on the Present() time test when using the 3D rendering path. When DMDX is waiting for a request and there is no active display it displays a test screen with information about the time the Direct3D function Present() took to setup the next frame's display.  These should never be more than a few milliseconds and if one is in the order of or longer than the refresh rate there should be a corresponding display error thrown.  If used with the original DirectDraw rendering path times will be the time spent calling Flip() till it actually flipped the display.

    Example scripts using these test modes are on the server and there's also one in the TimeDX help.


Safe Modes

    DMDX has a safe mode, turned on with the <SafeMode> parameter and frame option. The value of this keyword selects which safe mode is to be activated. Any safe mode currently has the added effect of printing the item as the drawing routines see it, with the RTF control codes left in (the way all versions prior to 0.20 always printed it). Current modes are:

0Turns off the safe mode.
1Turns on the ESC check safe mode. If DMDX is latching up and hitting ESC is unable to wake it up this safe mode increases the frequency with which DMDX polls for the ESC key being hit and the criteria under which it will stop a job; for instance, it will respond to ESC while the display is still active (normally not a good thing as the Abort message will be overwritten with the next display frame, however if your item file has an infinitely long frame in it setting this safe mode beforehand is the only way to stop the job).




DMDX Index.