Do not be distressed if you cannot get a sustained 1 tick per Blit rate without Late Frames, this is due to this test only using double buffered video (DMDX will use triple buffers if there is enough video memory), this code never gets a moment to rest. My old Pentium 166 with a Diamond Stealth video card that had the fastest blitter I had ever seen couldn't keep up with 1 tick presentations without falling behind every second or so, the Celeron 400 test bed using a S3 secondary display (so it's on the PCI bus) can't keep up, however the same Celeron 400 using the primary TNT display (an AGP device) keeps up forever.
    The times provided for the sound buffers (see Sound for buffer properties) are the retrace count at which to commence playing that buffer. If it is zero the buffer is not played, if all buffers are zero then the primary sound buffer is not setup (meaning there is no overhead for sound). You can use the diagnostics provided below to see if the commencement of a buffer's playing corresponds to an unsightly increase in loss of synchronization. The recycle time enables the buffers to be played repeatedly, if a given buffer has not finished playing by the time it is recycled it will continue to play out and not be restarted again that cycle (ie, if it has finished by the next cycle it will then play every second cycle).
    The Pulse Train check box provides a pulse train with the PIO similar to the Time test pulse train. This is provided primarily so I can determine the effect of changing the priority of the retrace sync thread (see the Task Priorities command), if it is pushed too high the millisecond callback might be affected.

    This test blits the rectangle in the middle of the screen (the size of which you specify) alternating from black to white as each frame is displayed. Because the test is a steady 50% duty cycle you should be able to clearly see when errors occur, assuming the timebase is set at a reasonably fast rate.

    The numeric keys can be used to select the numbered option below, where two numbers are listed the A key alternates between the two displays. When the test finishes (when you click the mouse, press space or hit escape) all results are displayed in a dialog box:

    1/ The video retraces that have been Timed Out and those that were Multiply Timed Out, see the discussion on the Vertical Retrace Sync Thread. I present this so that you can see if the Multiply Missed retraces are the culprits behind display glitches, also these may coincide with item 8/.
    2/ The maximum time taken to complete a Flip, the Blit and the Text preparation times. The Flip time should never be longer than the Vertical Retrace duration plus a couple of milliseconds -- it is the time between the code detecting that the retrace before the flip should occur has occurred, issuing the flip command and the flip status routine reporting that another flip can occur. The text preparation is the time taken to prepare this diagnostic, the Blit plus Text time are going to limit the maximum rate that this test can go at, regular DMDX will not have to prepare any text so it's speed won't be limited by the Text time, however it will be limited by the Blit time -- plus whatever the audio processing takes away something that this test does not measure.
    2/ Alternately, the maximum time lost pumping the windows message queue (needed to so the test can respond to keystrokes). This is only done once per flip but if you see values in here larger than the period times the retrace interval this can be a cause of missed flips.
    3/ The total number of Flips missed for any reason. As you can see below there are a number of mechanisms at work striving to get that Flip done on time, any of them can break.
    4/ The number of Flips missed by more than a tick and the number of ticks that the most recent Flip was missed by. These are Flips that the retrace thread is responsible for triggering and for some reason by the time it got around to either triggering it or being asked to trigger it the requested video time was already well passed.
    5/ The number of last minute (LM) Flips missed and the number of milliseconds that the most recent last minute Flip was missed by. The last minute Flips are not triggered by the retrace thread, they are an instance where the Blitting of the image to the backbuffer has been completed during the retrace before it is to be displayed, the retrace thread could not pick this Flip request up as the retrace before the Flip is to occur has already occurred -- so the preparation code does the flip, however if it is too many milliseconds late (like the Sleep Time plus three milliseconds, see the Vertical Retrace Sync Thread for a discussion on the Sleep Time) the Flip is deemed impossible to complete on schedule. See 9/.
    6/ The number of Flips missed while Waiting For a Blit (WFB) to finish and the number of milliseconds that the most recent one was missed by. If a Blit is still in progress and a Flip is due to occur (can't Flip while Blitting) then it waits to see if the Blit finishes before it is too late to do the Flip, if it doesn't then this counter get incremented (the Flip still occurs, it's just late).
    7/ The number of times Flip refused to flip. For reasons unknown Flip can decide that it's not going to, and it isn't because there was a Blit going, I check for that already. The number of retries is the literal number of times through the loop till it did actually flip, the limit is currently 100000 -- after that it is considered an error (bad policy I know to have a hard coded number of retries given the way processors keep getting faster but I don't want yet another if() executed every millisecond).
    8/ The number of times that the WaitForSingleObject() routine timed out. This is when the Blit is completed and the thread goes to sleep waiting for the retrace thread to wake it up at the correct moment to Flip the display and it never does, or at least it doesn't do it before the calculated last minute (read millisecond). Probable reasons for this are missed retraces, hopefully the calculations are correct and the Flip can be executed at the right time even though the retrace thread is out to lunch.
    9/ The number of Last Minute Flips and the number of Waiting For a Blit flips. These are not missed, or bad, so much as the amount of work to be done to prepare each frame is nearly too much to be done at the rate requested. Keyboard response can get shoddy if there are a lot of these frames as the keyboard and mouse are not checked after last minute flips, normally it is checked after each flip.
    0/ The current video time and millisecond time.
    0/ Alternately, the number of requested flips.
   
        The 'R' key resets all values except the Video and Millisecond times.



TimeDX Index.