For every video mode and color depth that DMDX can use it must find the timing values of that mode in the registry. If they are not in registry you must put them there with TimeDX using TimeDX's Video Mode selection and the Advanced Vertical Retrace Sync test.

Wait for input thread to die failed

or

Wait for sound thread to die failed

   It's safe to ignore thread failing to die messages. Some machines seem to take forever to kill off threads that were doing things that are part a job that was running. Alas I never get to see such machines so never get to fully investigate them but the work of running the item file and saving the data has already been done so they are of no consequence. If the thread was responsible for saving data or some such thing there would be cause for concern but no thread is so it's just a case of me religiously sticking error messages around everything that possibly could fail and you having a machine that for some reason takes forever to kill off threads.

could not open registry key <SOFTWARE\TimeDX\some_name> error code 2

    DMDX is unable to locate a registry key containing information it needs to run. In-between versions of DMDX new registry keys are sometimes added for new functionality, as TimeDX usually creates these keys it is necessary to run TimeDX again and set the new feature up and thereby create the new registry key. Some of the keys and TimeDX test to run to date are:   

    When an frame cannot be moved into video memory by the time it should be this error occurs. Less stringent timing is required or less of the display needs to be manipulated. Or best yet you need to buy a video card with more memory, DMDX displays the number of video pages (or buffers) when an item file is commenced, this is the number if frames ahead that it can buffer the display sequence, once frames are in video memory they can be displayed with no further processing. This error used to cause the halting of the job as the display sequence was incorrect, however with the 0.08 rebuild of vid_int() timing errors and such forth are handled with considerably greater aplomb, now the previous frame will have been displayed while this frame was moved into memory for an extra time of however many ticks this frame is late by and all succeeding frames will be rescheduled to allow this frame to be displayed for it's correct duration.
    A third line can appear as part of this message:
    -- possibly caused by another process taking %d ticks
    Here a certain video error has been detected by the retrace synchronization code as the kernel pre-empted DMDX during the presentation of the item so the code that moves stuff into video memory may have been robbed of it's usual amount of time to move frames and hence it may not be solely the design of the item at fault -- it would still be a good idea to adjust the timing of the item file to avoid such conditions as DMDX can do nothing about other processes needing to be executed (they are usually part of the kernel and if DMDX pre-empts them the machine stops working).

    Occasionally it can be difficult to determine why a particular frame is being loaded into video memory too late -- the usual explanation is that DMDX keeps track of what is in each of the video pages (and there can be up to 25 of them) and adjusts the size of any given frame to overwrite the contents of the video page that that frame will be moved into. This means a the size (the amount of the screen containing information) of frame in the past can make a later frame much slower to move into display memory. For instance, if you only have a video card with one meg of memory there are 2 video buffers (at 640x480 8bpp) plus the one being displayed, if the frame three before the current frame manipulated the whole screen then the current frame, regardless of what it displays will update the whole screen too -- if you have 4 megs of video memory on your display card a given frame will be related to the frame 13 frames before it. If you think that's tough to comprehend you should try writing the code that does it. Now imagine you are doing an extremely stressful task, your item file is scrambled and you have a great big multi-line instruction in there -- the frame the number video buffers plus one after the instruction (no matter what scramble puts there) will be much larger than the other frames.
    If this sounds daunting then remember that most new video cards can have a full page moved into video memory in a tick or less, I include these instructions on the wild off chance that someone actually manages to want to do something that can't be done.
    Should you have a video card with enough memory to buffer the complete item and are still getting this display error you probably need to increase the time between the request and the commencement of the display, the <Delay> parameter -- being careful to make sure you don't wind up with a request scheduled display by specifying the value with a negative number.

Display error at ms %d, tick %d in item %d, frame "%s"
%d ms of refused video flips occurred

    DirectX has refused to flip the video pages and DMDX has retried the flip a number of times. This error can occur on some machines when pressing the machine to it's limits by presenting long sequences of 1 tick frames, basically it means DMDX is eager to get a flip done and DirectX ain't ready for it and it can also occur on other machines that have crappy video cards. This error is printed if and only if the time spent trying to flip the video pages is longer than the time to the next retrace, if it occurs with regularity then it could be because the maximum blit set with TimeDX is too big or more likely it is simply because the sleep time has been set too large and that video chipset cannot accept a flip too close to the next retrace. The frame will have been presented late by the number of ticks equal to the refused time divided by the refresh rate rounded up.
    There is one thing you can do to try and remove the refused flips errors and this is to dicker with the the timing parameters for that video mode in TimeDX / Advanced / Vertical Retrace Sync Thread. Essentially what is happening is that DMDX needs to setup the flip for the next retrace to display the next frame, however the video card is complaining that it can't do it at that time. In my experience it can't do it for one of two reasons, either DMDX has waited too long to ask for the flip and because it's a wretched video card it can't accept commands to flip when it's within a few milliseconds of the next retrace (most video cards have no problem with this) or it can't accept the command because it's busy blitting data to a video buffer, but this is much less likely as DMDX in most instances has so many video pages that it's likely to have moved everything into video memory long before the frames are going to be needing flipping to be displayed.
    So the first thing is to reduce the Sleeping Time, this is the amount of time that DMDX spends doing other things besides tending to the vertical retrace before the next retrace, so the longer this value is the closer to the next retrace DMDX will ask for a flip. Be careful however, reducing this value means DMDX has less time for other tasks. The other thing you can do is reduce the maximum number of lines to blit at once, this will make DMDX do less blitting in a single chunk and therefore tie the video card up for less time at a time and therefore possibly reducing the chance of a refused blit, but this assumes that you have a video card with little memory or are using a video mode that uses an enormous amount of memory -- you can see how likely this is to be the cause of your problem by looking at the diagnostics DMDX displays, at the start of running an item file there will be a line displaying the number of video memory buffers using the requested video mode for that item file, if there are more buffers than you have frames in an item this is unlikely to be the cause of your trouble.
    A third line can appear as part of this message:
    -- possibly caused by another process taking %d ticks
    Here a certain video error has been detected by the retrace synchronization code as the kernel pre-empted DMDX during the presentation of the item so the code that flips the pages may look to have been refused simply because the Kernel was executing instead. If the time refused is consistently just greater than the timeout time minus the sleep time you could try lowering the sleep time -- you can't lower it too much as the sleep time is the time that blits get performed.

    Either of the above Display Errors can have one of the following three additional diagnostics following it if the vertical retrace code is being dispatched by the millisecond callback (not the default case in Pentiums and any other machines with High Performance counters):
-- but more than likely due to msec callback being %d ms late
-- exaggerated by msec callback being %d ms late
-- due to msec callback being %d ms late

There were more than %d display errors

    This message appears after a number of the two display errors above, usually 10 of them, indicating that more errors occurred in the most recent item's display than have been reported. This is due to the fact that in order to stop the printing of a diagnostic further snowballing timing errors only a fixed number of them are queued, once more than that number are generated in a given item the rest are thrown away. When the next item is read they are printed and the queue reset.

Preparation A %d ms, B %d ms

    These are not errors, these are the time taken to prepare the item. Time A is the time taken after the display of the previous item finishes (including it's feedback), usually, but by no means always, before the request for the next item is received. It includes the time taken to flush any recorded responses to disk (AZK and ZIL but not DTP response modes), the time taken after an <animate> frame to set all the video memory buffers back to the background color and the time taken to read any bitmaps and wave files from disk. It also includes the time taken to send monitoring messages to a remote machine over the network if they are being used. If a job has the continuous running option set or uses the <continue> switch (or the user presses the request immediately) then the <delay> parameter must allow for this time as well as the B preparation time. The <MediaLife> keyword can be used to reduce preparation A times.
    Preparation time B is the amount of time spent loading fonts and manipulating bitmaps and assembling the images in memory prior to their being displayed tachistoscopically. The <delay> parameter must always allow for this time (NOTE: <delay> is specified in ticks while these times are in milliseconds).

DQ adjusted by %d ticks to allow for sound

    Not actually an error so much as a re-organization. In order to play a sound in accordance with it's visual probe it must begin before the current display queue begins, so the display queue has been moved later in time (the default delay has been extended for this item). If you have <RequestScheduled> on you may want to re-do your timing allowing for the length of the wave file.  This error usually occurs because the item begins with an audio segment and DMDX's cautious nature figures there's a chance that'll go astray so it shifts the item by tick to make sure the audio thread has a chance to schedule the audio before it's actually needed.  The solution is to begin the item with a visual display, even if it's just a blank frame for a single tick. Or live with the warnings, it's what I do...

RTF control word <\%s> used in quoted text, not supported

    Your editor has a used an RTF control word (or character) that DMDX does not support (see Item Files. above).  You need to check the Ignore Unknown RTF checkbox in DMDX's main dialog.  After that if your display in DMDX doesn't match what your editor displays you'll have to reformat your item file, often opening and saving the file in WordPad will rectify this.  If the display effect you want doesn't survive WordPad there's a good chance DMDX won't support it anyway (for instance blinking text won't ever be supported).

Comma Frame Separator cannot be used with Sound Frames

    The use of the comma frame separator with a sound frame has been banned due to the unexpected results it provides. For instance, / "text" , <wav> / results in "text" being lost as the sound frame never generates a visual display to merge with "text" and / "oldtext" / <wav> , "text" / will leave "old text" on the screen merged with "text". Neither of these results are what the user expects to happen so the comma being an intrinsically visual operator is no longer usable with sound frames as they are non-visual.
   
READ ERROR BRANCHING (type %d) TO ITEM %d

    The item file contains a branch to an item number that is not in the item file. The most common cause of this is forgetting that to get DMDX to branch to an item number before the current item the destination item number must be negative. If you are having trouble diagnosing branches then turn on the branching diagnostics with <brdiags>.

PIO Polling FIFO full at time %dms

    When using the QPIO12 or QPIO12output16 devices the queue used to store input data may become full and thus some input signal may be detected late. This normally happens during particularly intensive conditions, say as DirectDraw is initialized at the start of an item or during particularly bad display errors. If you find this error message occurring during data gathering you might want to provide a third parameter to reserve more than the default 16 elements of buffering in the <id> keyword to reserve more queue elements, for example <id qpio12 10,1,48>. See Input.

DirectX reports no support for Page Flipping.
The video card in this machine is not adequate for DMDX's purposes

DirectX reports no support for Page Flipping.
While TimeDX allows certain use of this DMDX will not.

    When hardware acceleration for a graphics card is turned down DMDX can't use features it needs to use.  Go to Display Properties / Advanced / Troubleshoot and set the hardware acceleration slider to Full.



DMDX Index.