DMDX Help.


Direct3D notes.

    Version 5 of DMDX and TimeDX introduce a new Direct3D rendering path alternative to the traditional DirectDraw one as DirectDraw under Windows 8 (and later) is emulated introducing two ticks of latency (as far as I can tell anyway, Flip() takes 25 ms to return on all machines tested to date versus it's normal near instantaneous return so if you see messages like that in your .AZK files you need to use the Direct3D renderer) and that is capable of discarding frames outright (I suspect when it gets far enough behind).  DMDX version 5's auto mode should automatically use it when it's needed, otherwise to use the Direct3D rendering path under earlier operating systems the TimeDX File / Change Renderer command can used or the command line parameter -d3d can be used (for both DMDX.EXE and TimeDX.EXE).  Using Direct3D has a number of ramifications and I will attempt to address them all here.

    First up is the way the programs change from one display to the next.  With DirectDraw DMDX could buffer all the frames of most common items in video memory and just flip between them (with a function called Flip() appropriately enough).  When using Direct3D DMDX has to assemble the displays in textures (usually in video memory) and then present them (with the Present() function) rendered on triangles cunningly arranged so they look like a regular screen (you can see them with TimeDX's Video Mode selection test and the Time Video Mode test by pressing the A alternate display key when the test is running or DMDX's test mode 11).  This means the 3D chipset has to be able to render them to the screen in a single retrace, whether your video card is capable of it or not is another thing -- seeing Present times longer than the refresh interval during TimeDX's tests is a bad thing, similarly DMDX's new test mode 13 monitors Present() times.  Fortunately all chipsets tested to date can do this in a matter of a couple of milliseconds unless something else interferes.

    Second up is the level of control DMDX might get, there's a lot more code sitting between it's requests and the pixels going out to the display.  While all attempts have been made to write code that has the highest chance of working on all 3D hardware there's also the unknowns of what DMDX will be asked to do.  For Direct3D DMDX uses textures to contain the display data, however there's no hard and fast way of determining just how much memory a given 3D chipset has access to.  In fact, some of them will start using system memory when they run out of video memory.  What effect this has on display times can only be deleterious but worst case the display of that frame will simply be late and DMDX will catch it and flag it as such.  But knowing ahead of time where that cut off will be is anybody's guess.  However my experimentation so far indicates that the Direct3D rendering path is going to be superior in almost all circumstances, the ones where it's not are usually because of display driver issues unfortunately.

    Then there are dozens of minor differences, most of them transparent to the user, others less so.  For instance the first two DirectDraw displays (numbers 0 and 1) are the same display (it made sense a couple of decades ago) whereas in Direct3D they're sequentially numbered from zero.  Video modes in DirectDraw are either 16 or 32 bits in depth, in Direct3D they're 16 or 24 bits (there is however code to make 32 bit requests match 24 bit modes).  DirectShow could flicker and had serious issues with the abort item keyword for a long while there, problems that should be gone as of version 5.1.4.2 now that we've given up trying to decouple the VMR9 renderer from DMDX.  DirectDraw appears to be able to use a greater number of display modes so several times when I've accidentally selected a video mode I didn't intend to use that's at a higher frequency than the monitor can actually handle instead of blithely sending a signal the monitor can't handle Direct3D displays a blank screen that TimeDX will determine to have a retrace interval in the 2-3 millisecond range.  Not something I intend to address, but it does fail differently from the way we're used to it failing.  If people are concerned there's now a remote testing package here that will run the new version 5 code with the Direct3D rendering path turned on so people can quickly and easily see if it works on their hardware.

    And there are things I'm going to be doing that only apply to the Direct3D renderer, such as the fix for 2DInputDevices on multiple monitor setups.  My tendency is going to be to treat the DirectDraw rendering path as a legacy feature and new stuff will be Direct3D specific if I find myself having to add code that's unique to each renderer.

    Of course having DMDX use Direct3D now opens up all sorts of options never open to us in the past like magnifying or mirroring displays, flickering frames at different frequencies (actually having fixed the <AgainWhen> keyword so it works with the Direct3D renderer I doubt any special code will be written, see the Flicker Fusion Test in the introduction), smoothly rotating them, using stereoscopic glasses, independent animated frames with lives of their own, you name it. AMD's Freesync and NVIDIA's GSync are particularly interesting options allowing significant flexibility with display durations (there being no fixed raster interval) and has indeed been added as an option to the <VidemMode> keyword..
   
   
   
   


DMDX Index.