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.