You might want to try the DMDX mailing list. The idea is that if
someone is having trouble they can post to the list instead of mailing Ken
(and him then coming and bugging me) and if someone other than us has solved
the problem they can perhaps provide the answer. If you want to be on it:
1. Send a message to list@list.arizona.edu from the address you want to
subscribe to the list. 2. In the subject line of your message, type in:
subscribe dmdx Firstname Name (replace 'Firstname Name' by your own first name
and name).
DMDX is the successor to DMTG and DM before it.
It moves Dmastr on to state of the art hardware running under some implementation
of Win32, currently including Windows 7, Windows 8.1
and Windows 10 (recommended), and 11. There
are no Macintosh or Linux versions of DMDX, nor are any versions planned,
however using
the Direct3D renderer DMDX works reasonably well in a VirtualBox virtual machine using
their "experimental" WDDM Direct3D drivers in their Guest Additions
and I see people running
DMDX on a Mac using Wine or a Wineskin. Windows
95 support has been dropped and is only available in the archived 2.9.05 version.
Windows
98 support was dropped in version 5 so you'll need the archived 4.3.0.1 version and
Windows XP and Vista were dropped in version 6 so you'll need the archived
5.3.3.0 version for them (although I suspect 5.1.3.4 was the last one that
operated with XP as when I recently set up a XP virtual machine it complains the
later binaries aren't win32 executables so the new compiler is producing
something XP can't grok).
Win32 is chosen as aside from the fact that it appears
to be the only direction to go in, it would appear to have some longevity, it being
the core of routines that Microsoft are building several operating systems around
-- so when the next OS gets built I shouldn't have to do anything, or if I do it
shouldn't be very much. DirectX is the standard that allows access
to the hardware with as little intervening OS stuff as possible and it is now the
layer that Win32 uses to communicate with the hardware itself.
The actual hardware that this all runs on was not
any panty waisted machine, not by 1997's standards anyway -- most 1998 boxes were
adequately equipped however and anything you buy these days is fine from a
performance perspective
however a number of recent machines (2024) appear to overheat when DMDX hammers
the raster status registers. I've yet to find a reliable way to predict
which machines will suffer and which will not (laptops being the worst offenders
but I have seen desktops too) short of running the Introduction's test modes on
the things. Not all is lost, most of the machines that overheat revert to
relaxed raster tracking and perform reasonably well however some do not so my
advice to anyone buying lab machines is to buy machines with adaptive sync
monitors and graphic cards (beit AMD Freesync or NVidia GSync devices) as here
DMDX does not need to track the raster as long as you're putting "freesync" in
your video mode parameter (so <vm desktop freesync>).
To facilitate figuring out how given hardware is
supported by DirectX the TimeDX program determines the capabilities of the DirectX
components available. TimeDX (like TimeG before it) was the test
bed that the individual components of DMDX were built and tested in before rolling
them all together into an usable program.
FAQ.
Q. How accurate is the response timing?
A. For those people concerned about MYORS in Behavior Research Methods, Instruments and Computers 1999, 31 (2), 322-328
I built some new test hardware that produces a electronic switch closure every 524.3ms
(a 2.000MHz crystal divided by 2 to the 20th power) and using Test Mode 8 (which
simply records the time between response signals) with a single post target mask
the following results were obtained:
PIO12 values are:
Version 1 results:
ms n
523 87
524 200
525 239
526 46 Mean 524.4ms
572 sd 0.843ms
Version 2 results:
Mean 524.37ms
sd 0.77ms
PIO12 values with an 11025KHz 16 bit wave file playing:
PIO12 values with 5Mbps network transfer between two other machines at the same
time (which was an extreme amount of traffic at the time the test was run back
when 10baseT was special):
Instacal QPIO12 values with at twice the closure rate:
Version 3 results:
ms n
261.8 701
262.8 346
261.7 38
261.9 19
262.7 19
262.9 13
261.6 2
263.0 2
261.5 1
262.0 1
262.3 1
263.1 1 Mean 262.13ms
1144 sd 0.47ms
Test machine for the Version 1 results was an AMD-K6
300 with a Riva 128 4M video card and 64Meg of RAM under Windows 98.
Test machine for the Version 2 results is a Celeron 400 multi-monitor system with
a Riva TNT 16M primary display and a S3 Virge GX 4M secondary display, the secondary
display being used as the subject's display with 128MB of RAM under Windows 98SE.
Test machine for the Version 3 results was an Athlon 1700+ with NVIDIA GeForce 4MX
video card with 512MB of RAM under Windows XP. As you can see
the standard deviations are nothing like Moyors' ~16ms under Windows 95 -- which
just goes to show that if you are going to test an operating system then writing
code specific to that operating system will yield much better results than writing
code for another operating system (DOS) that the operating system you are testing
(win95) only
provides backwards compatibility for.
The standard deviation for the keyboard is as high
as it is due to the standard keyboard polling effect that is part of all keyboard
hardware and is unavoidable and is also the reason the keyboard should never be
used as an input device, Moyors' test uses the keyboard auto-repeat as a signal
generator and not as a real response device as we are using it (we cannot use the
keyboard auto-repeat as a signal generator as DirectX filters auto-repeat codes,
we have to repeatedly generate keystrokes instead and thus incur the keyboard timing
error).
Interestingly enough using test mode 9 that is designed
to be used with a phototransistor triggering off the display (it just stores positive
RTs), over one hundred trials with a PIO-12 on the third test setup produces a standard
deviation of 0.29ms, almost exactly millisecond accurate timing, substantially better
than the test mode 8 results would indicate. The trouble with
test mode 8 is that it measures two variabilities, the beginning and the end of
each period, test mode 9 however knows pretty much to the microsecond when the retrace
began so it's variability is substantially lower:
Instacal QPIO12 values, refresh 11.76ms, trigger after 10 frames Version 3 results:
Q. Does it work with future operating systems?
A. It might, but as we found out with Windows 8's release, there's a
chance it will do poor things so we had to write a new renderer to handle that.
Q. Will it support old Item Files?
A. Yes, it's Dmastr, it wouldn't be Dmastr unless
it read those horrible old inscrutable scripts. That is not to
say that the ITM file structure will not have new things added to it, easier
alternative methods for doing things and so on. For instance,
the way fonts are specified is different as TT Fonts are another ball park compared
to the Borland ones, but that is not to say that results similar to what would have
been produced with DMTG are not possible.
Things I have done with it:
RTF item Files. In order to smooth the
use of different fonts that contain extended character sets it occurred to me
that the item file is going to have to have those fonts in it (no other way to
reasonably tell what the text is otherwise) which complicates things no end.
The easiest solution that I saw was to use the RTF (Rich Text File) format for
item files, meaning the .ITM file extension will probably not be usable, or long
files names could be used with names like "itemfile.itm.rtf".
This means the editor you use must produce RTF files, MS Word and the standard
WordPad both do. It also means that the font must be usable
in those editors that produce RTF files.
Matter of fact, given the power of this the old font
specification methods have been abandoned and even the pure ASCII .ITM file format
has been pretty much abandoned. If people want to use old item
files they'll have to save them as an RTF file (no big deal) and if the file contained
font manipulation stuff this is going to require re-working anyway.
Using the RTF file enables usage of bold, italic, COLOR, multiple fonts and styles
and colors all within a single frame -- no hassle, there in the item file, as
close to WYSIWYG as we're gonna get any time soon.
Sound. The VM extensions are long gone. What
is provided instead is a much simpler scheme of specifying when a given file is
to be played that is integrated into the regular syntax of a frame specification.
If at a later date someone needs the enhanced and exceptional control of the VM
syntax then it can be added as an additional way of specifying the position and
duration of sounds, more than likely it will be it's own separate non-display
driven program however.
Also, it uses .WAV files now, no more .ADF
files, no more BLISS.
Palette manipulation. The V and VV switches for
palette manipulation are not supported.
Graphics. No more .IMG
files, kiss EDTSCR goodbye, it's all Window's .BMP files now.
And, yes, I have written a converter,
here .
I wasn't going to for the longest while as the aspect ratio has changed, all the
old images will appear squished, however DMDX has the ability to stretch bitmaps
so it makes more sense to make a converter. The converter will
however only work with monochrome .IMG files, 16 color .IMGs are still unreadable
by anything except EDTSCR.EXE.
Digital Video. Using
DirectShow DMDX can now display Digital Video files, .MPG, .AVI, Apple Quicktime,
whatever codecs you've got installed DMDX can play. It is however
going to take a fast processor and hard drive not to drop any frames (a P200MMX
isn't even close).
Audio Input. Two special
input devices interface with DirectSoundCapture, the DigitalVOX device and the
RecordVocal device. The DigitalVOX input device does away with
external electronic voice keys using a microphone and sound card instead and the
RecordVocal input device writes the subject's vocalization to disk.
Hardware Features Used by DMDX:
Multi-monitor machines. You can plug two
monitors into a lot of PCs these days and one (the primary display) can be used one for an experimenter's
display and the other for a subjects display.
GamePads and So Forth. In using DirectInput DMDX can interface to joysticks, mice and such without too
much trouble, while mice behave a bit better than standard keyboards joysticks
are an excellent alternative to installing a PIO-12 (as long as you don't want
output).
The reason I include such information is not that
I expect people will want to use a joystick or a gamepad per se, but that these
devices are much more amenable to modification (ie, to build a regular response
box out of) than a PIO card. Not that the PIO won't be supported,
it is already, but the skill required is reduced to 'Can you operate a soldering
iron' from 'Can you read and understand a simple schematic diagram'.
All that will be required is to solder switches in parallel to existing ones,
if someone wants to get really carried away they can junk the plastic of the original
device, but this is not necessary.
Interface Cards. DMDX
can use an 8255 based interface card for input and output (usually referred to
by me as a PIO-12).
Gazepoint eye trackers. DMDX
can send and receive TCP/IP packets with the <send> keyword allowing it to
interface with anything using a network interface that talks TCP/IP such as
the Gazepoint eye trackers.
AMD Freesync and NVidia GSync adaptive
sync monitors are now supported and it's
entirely
possible that the only way DMDX can sync with the retrace in the future
may be to use adaptive sync monitors with <vm
desktop freesync>.
Hardware found to be Usable with DMDX:
As a general
rule all new hardware is going to work with DMDX. The exceptions are interface cards and
laptops. Interface cards will generally need modifications to DMDX to
handle new ones and laptops should be the ones that are built for gamers --
although we've seen any number of business class laptops work when audio is not
a priority.
Whole Systems
Desktops.
Been a long time since we saw a desktop DMDX wouldn't work with, even ones
with cruddy built in video chipsets on the motherboard work nicely these
days.
DELL Inspiron and Latitude machines.
These laptops tend to function beautifully.
Video.
Pretty much all new cards are going to work well these days.
Interface Cards.
DMDX can use an 8255 based interface card for input and output.
ComputerBoards CIO-DIO24. While it does have a counter on it you don't have to use it. Better to
buy the following DIO24 card:
Computer Boards nstaCal drivers. Computer Boards
InstaCal Universal Library drivers can be used for Computer Boards interface
cards under Windows 2000 and XP etc.
Keithley cards with DriverLINX drivers. While their products
cost three times that of Computer Boards and as long as you have a mother
board that still POSTs with the Keithley card installed (anything with an ASUS
A7M266 won't) Keitheley cards under Windows 2000 and XP are usable with the
DriverLINX drivers installed (they have some kind of emulation mode of Direct
I/O for older OSes). But snakes alive are they crappy
drivers. Not only are the DriverLINX drivers 100 times slower
than the InstaCal drivers (.1ms to read the card vs .001ms) but they are fragile
as hell in a multithreaded environment (read DMDX). Be sure
you use the queued version of the DMDX input devices, QPIO12 instead of PIO12
for instance.
With the addition of support for inpout32.dll DMDX
can now send and fetch bytes from arbitrary ports meaning almost
anything can be supported these days.
Monitors
TFT / Flat Panel / LCD devices
.
The prevalence of LCD devices these
days can make purchasing a CRT rather difficult, however if you are
interested in tachistoscopic presentation rates the extra effort will
not be for waste as there are several caveats to TFT use as noted in
the
TimeDX documentation. Notably one has to make sure one is using
the native resolution of the display but even beyond that there are
several gotchas as some models (predominantly nicer PVA displays) have
significant lag no matter what you do. And if you really have to use
a TFT display for tachistoscopic presentations you'll want one with a low
response rate but the ones with really low response rates come with other
drawbacks. Really, not recommended unless you do some serious
research on the issue, barring that buy something made for gamers.
CRTs. Good luck finding these any more. Tick values in the 10ms and less range are now possible
with LCD monitors made to cater to gamers so the reliance on CRTs is no longer
absolutely
necessary.
AMD Freesync and NVidia GSync monitors
are now supported with the
<videomode> freesync modifier. Indeed it's entirely
possible that the only way DMDX can sync with the retrace in the future
may be to use adaptive sync monitors.
Sound Input and Output
AC '97 and Crystal Sound inbuilt sound.
Lots of modern mother boards have built in sound these days and the ones I've
come across work nicely even if the amount of noise found on them is less
than terrific.
Input
As a general note, DMDX will not be doing anything with the axes of input devices
unless one used the 2DInputDevice keyword, it will only be using the buttons.
PIO card based response boxes. See
Interface Cards above.
Regular Mice and Keyboards. They work,
timing characteristics need to be measured on an individual basis as there are
large variations even within one model.
Logitech Wingman Extreme. Works. The
polling timebase is 3 milliseconds and the POV "hat" basically won't ever be
usable (unless I modify DMDX to record axes) because technically it's an axis
kind of thing. If you short the axes pots out then the timebase
can drop to 1 ms.
Any old joystick or joypad or gamepad.
All joysticks are usable in one form or another although the original 15 pin
jobs are going to be tough these days.
Parallel port based response boxes.
These are now supported with the
inpout32.dll support
Windows Touch touch screens.
Windows 8 and 10 touch screens are now supported with the
<2Did windowstouch> keyword
Hardware found to be unusable with DMDX:
Whole Systems
Macintosh computers running Virtual Machines. In
the past DMDX was just plain not going to work in a virtual machine, regardless of whether
it was a Mac or whatever (we just happen to see people trying it on Macs),
these days CPUs are so damned fast that you actually stand a reasonable
chance of getting DMDX to run. My experiments show that the millisecond
accuracy of RTs takes a big hit (SD up from .1 ms to .3 or more ms) but as long as
you're using the Direct3D renderer you actually stand a shot at getting
this working, hell I see people even getting
Wine to run DMDX on a Mac
(just how accurate that is remains to be seen, I'd bet for tachistoscopic
purposes it's impaired). Traditionally Bootcamp has pretty much been your only option if you want to run Windows and
OSX on the same hardware, other boot loaders are available for Linux
machines and I'd certainly go that route if I wanted a seriously accurate
machine, but for people using keyboards for RT gathering where we've seen
SDs in the order of 10 ms Wine or VirtualBox is probably not too bad these
days (2019).
Microsoft Surface Pros. Some
people seem to be having issues with these machines. After extensive testing
our basic recommendation remains to avoid Microsoft Surface Pros however for
people doing remote testing this is not exactly reasonable so 5.1.5.0 contains
code that at least stops DMDX locking the things up and may in fact allow a
strong semblance of functionality. We say "may" because there was at least
one issue that remained with the tachistoscopic acid test however it appears
to be idiosyncratic and there's nothing else I can think of that might address
it at the moment. Basically what happens now is that if the retrace tracking
thread gets blocked for a second or more DMDX switches into a relaxed retrace
tracking mode that doesn't hammer the vertical blanking bit and instead only
polls it once per millisecond. And obviously if you're looking for an event
that's a few tens or hundreds of microseconds in duration you're going to miss
a lot of them polling once per millisecond. Fortunately machines I've tested
(two) can still track the raster well enough to not generate display errors
(this is with the tachistoscopic acid test so a pretty rigorous test).
Unfortunately the Surface Pros inadequacies don't stop there and on at least
one Surface Pro the first frame of a tachistoscopic batch can be missing.
Maybe the Surface Pro's 3D drivers can't handle two threads making requests at
once, maybe it's just that machine, who knows. The user of that machine is
going to use EZ mode on it and not test subjects with it, at least they'll see
the full display and worst case it's a tick off in it's presentations.
A bit of sleuthing after the HP EliteBook problems surfaced makes it look like
the Intel HD 520 video chipset in the Surface Pro machines
appears to be the source of the problem as the HP device has the 5500 version of
the same chipset in it. Argument against that is that my Dell Inspiron
15 5566 has an Intel HD 620 video chipset and it's golden. Difference may
be that I perform clean installs of the OS on my machine, no shovelware.
That or the Intel 5xx and 55xx devices are just cursed...
HP Envy and EliteBook laptops. Similar
to the Surface Pro problems it appears these HP Envys and Elitebooks are similarly
cursed with having to use relaxed raster tracking if not
EZ mode.
Given that Windows 7 was in use on at least one of these I'm thinking it's
the Intel video chipset that may be cursed so it's Intel HD Graphics 5500 is
listed as problematic below in the video section.
Built in or integrated video motherboards. The rule
used to be that there was nothing intrinsically wrong with built in video
chipsets (in the early days this was definitely not the case). However
given that most built in video chipsets tend to be from Intel and we have
two cases of exceptionally poor performance with the Intel 520 and 5500
devices there's a pretty strong caveat now.
Video
Intel HD Graphics 5500 and 520 video
chipsets. See the Surface Pro
and HP Elitebook problems in the whole system section above. Appears to
have stupidly cursed video drivers. I'd be avoiding anything from Intel that
begins with a 5 as my Intel 620 is fine whereas both the 520 and 5500 are
unusable without countermeasures.
NVIDIA cards. Classic DMDX (prior to auto mode)
would have problems on these cards unless the back buffers were limited to
4. Seeing as auto mode already limits the back buffers to 2 with the
classic DirectDraw rendering path and the Direct3D path limits itself to one
they're fine.
ATI cards. They're fine these days.
Sound
None. Almost any sound card can
be made to function with DirectX,
however if there are no specific drivers for the card then the dreaded (emulated)
appears after the cards name and latencies for that card will typically be 200-300
milliseconds (not good). Worst case if you're using RecordVocal you
provide some
overrun protection for it.
Input
Parallel port based response boxes.
These are now supported with the
inpout32.dll support
Latest files:
The DMDX version number scheme now follows
Microsoft's A.B.C.D format,
where the A version number (3 as of 04/03/03) indicates system level changes, I
don't expect this will change in a very long time.
The B version number (0 as of 04/03/03) indicates very major additions or
changes, the C version number (1 as of 04/03/03) indicates significant additions
to DMDX's functionality or significant steps in the code base such as finishing
the port to the MS VC 6.0 compiler. The D version number (4 as of
04/03/03)
indicates minor additions that are more often than not fixes to
existing things. DMDX version 1 and 2's version numbers
were A.B.CC. TimeDX retains the 3 number variant.
DMDX 1.3.01 is
provided for 486 processors,
2.9.05 is provided
for Windows 95 support,
4.3.0.1 is
for Windows 98/ME,
5.1.3.4 is
for Windows XP and
5.3.3.0 is
for Vista. These are the versions we used to use, we almost
always use the current version.
DMDX binaries and demos are
here.
The DMDX text / graphic / audio demos in demos.zip are
here
The DMDX digital video demo in DVDEMO.ZIP is
here.
Progress to Date.
03/04/24
Well I think the addition of parsing Unicode to UTF-8 outside quotes in
item files completes the Unicode odyssey we've
been on the last few years with DMDX 6.4.0.0, if there's another place DMDX
could handle Unicode and it doesn't I can't think of it, I declare DMDX to now
be a fully Unicode aware program (assuming the Unicode option is in effect of
course). After having added named
counters to match the named macros it dawns on me people might want to use
special characters unique to their locality in those names, lordy, was that ever
a mistake. While it was relatively straight forward getting the Unicode
counter names working macros were another thing entirely. In order to have
Unicode outside quotes in item files I have to use UTF-8, something I'd already
more or less done for localized keywords (never went anywhere and the code for
it remained dormant) but a macro has to expand within quotes, no particularly
big deal except macros can contain other embedded macro definitions so we have
to be able to mark up our UTF-8 names back to UTF-16 found in quotes.
Beyond having to deal with UTF-16 surrogate pairs (emoticons anyone?) I had to
pull the recursive macro code written in the late eighties for DM apart and rebuild
it; for one thing it wasn't handling embedded named macros now that they're
UTF-8
and for another if anyone had tried to use Unicode in the subject ID I mention
below I'm pretty sure any use of macro S would have produced mojibake.
I spent close to a week on and off with the debugger on that trying to get the
new expansion code to work the way the original code was calling it; not only
that, the debugger gets it's
knickers in a twist occasionally when debugging recursive routines, can't say I
blame it, mine get twisted with recursive stuff too, I still remember my
amazement at getting that original code working at all...
And then as I'm updating the Unicode notes I realize that using UTF-8 outside
quotes has serendipitously solved a lacunae from all the way back when I first
added Unicode to DMDX in the late aughties and that was that in order to include
Unicode characters in a macro body one has to quote the definition of that
macro, as in mM"ॐ", something I go to some lengths to point out in the Unicode
notes (it arises because DMDX strips RTF control words out outside quotes but
Unicode is encoded with RTF control words). Well having Unicode outside quotes now means you can gaily have
mM+ॐ+ and it will now expand correctly when you use ~M in quotes.
I love it when an unintended side effect is actually beneficial.
05/12/23
Spent the last few weeks (periodically) removing
references to www.u.arizona.edu in the help and elsewhere and making them HTTPS
psy1 references and putting a .htaccess file on it that redirects all traffic to
psy1 as UITS is retiring that server. They would also like to banish psy1
but that battle is still being fought, if we loose then I'll set up an AWS
server -- which doesn't come for free so people frequently using psy1's remote
testing features will be donating to that cause, if you want to help feel free
to send me an email (jforster{@}arizona[.]edu), won't be more than a few bucks a
month. Hopefully if this comes about UITS can point psy1's DNS record at
the new Amazon server and people won't notice the rather dramatic underlying
changes.
06/11/21
After a year of fixing and tweaking various things it
occurs to me that if DMDX can use Unicode file names for resources it should
also be able to open and read item file names with non-ASCII characters in them
too, so we have DMDX 6.2.0.0 where I've not only allowed browsing to said item
files to run them with DMDX I've also updated most of the utilities (ANALYZE,
AZK2CSV etc) to use Unicode file names
too. For completeness' sake I've updated the command line parsing code to use the
wide Unicode versions even if batch files need a bit of jiggering (you have to set the code page to UTF-8 with
chcp 65001). And seeing as the subject ID
can be used as part of a filename it's now UTF-8 as well. While there's a good chance you could have always used names with
characters from the machine's local code page you for sure couldn't use
characters from other code pages (so if your machine was Korean you could
probably use Hangul but not Hebrew) and a bit of testing here with Hebrew makes
me believe it may not have always been possible even then as I had the machine's
language set to Hebrew but wasn't able to open files with characters from that
alphabet. Said fix also re-enabled the use of relative path names for
resource files that had been busted for almost 15 years, oops, pretty sure I
noticed it on at least two occasions but each time a fix would be found before I
had to crack open the compiler so I never fully investigated it, this time I ran
over it as I had to rip up all the file I/O to handle UTF-8 names.
06/07/20
A few months ago someone sent me a file with Hebrew
characters for it's file name which reminded me about DMDX's long standing
inability to load graphics and other resources that use non-ASCII characters in
their names (the long standing advice has just been to use ASCII resource names)
and it got me wondering whether DMDX's recent additions to the
Unicode option might not finally allow DMDX to in fact load such files.
After a fair bit of work it turns out that it does and after several weeks of
progressively finer tuning the Unicode option is now much more usable than it
used to be. Besides allowing the use of any Unicode characters or code
page extended characters in resource file names version 6.1.2.18 can now render UTF-8
characters in diagnostics and error messages which means that after DMDX
converts them from it's own internal representation to UTF-8 they are much
easier to parse and look much the same as they do in an editor (in the past such
was not the case when the Unicode option was on), I never realized just how powerful UTF-8 was, sure is a shame
Microsoft went down the UTF-16 path (actually it was UCS-2 back then) when they developed Windows NT, it would
have made life much easier if they'd chosen UTF-8 (to be fair they may have had
to make the decision before UTF-8 existed or was ready for prime time).
Sure wish I'd known about UTF-8 when I put DMDX's Unicode option in years ago.
Regardless, after a couple of weeks of not thinking of yet another error message
that needs conversion I think I've pretty much nailed it.
10/09/19
And just when it looked like things were going to get
quiet again I get a request to control a Gazepoint eye tracker using TCP/IP.
This is something I'd been waiting for for some time as it always appeared to me
to be the next logical medium to send signals between machines to synchronize
them but no one ever asked for it and I wasn't about to go looking for it's use
preemptively. However having gotten the request in version 6.1.0.0 we now
have the
tcpip input device that will open a connection to either a remote machine or
a process using the loopback address (127.0.0.1) that's either using the Open
Gaze API or some another type of API, be it JSON or what have you.
09/27/19
Looks like the built in introduction I started back in
December is more less completed along with the ability to port a
version of it
to HTML in the help file. It started out being a simple thing to address
the people who complain about DMDX's steep learning curve (you'd never believe
that there are people that claim it's easy to use) but then as more and more
things occurred to me it's now a pretty comprehensive affair only lacking
examples for presenting media files (which it can't do, people will have to fall
back on the traditional demos).
02/27/19
Well that didn't take long, normally there's eons between updates here but
I recently got access to a modern touch screen device (a very nice Inspriron 11,
even with a meek AMD processor in there it handles DMDX with aplomb).
I'd always hoped that DirectX could be used to interface with modern touch
screens but having gotten one to play with I see it's definitely not the case
and one needs to use the Windows Touch system to interface to it. However
adding support for Windows Touch necessitates the cessation of support of
Windows XP so I had left it alone not having privileged people hound me for it.
Now of course XP is years out of support and I don't see very much evidence of
it's use with DMDX so 5.3.3.0 will go down as the last version supporting XP
(although I suspect 5.1.3.4 was the last one that operated with XP) and
will be set aside and always available in the legacy downloads. All hail
the king, we now have version 6.0.0.0 of DMDX supporting the new windowstouch 2Did
pseudo input device.
02/19/19
Recent work takes DMDX up to version 5.3.2.3 and
includes the support of generic PIO devices, dramatically tighter parsing of
parameters to keywords, comprehensive Unicode support for East Asian fonts (DMDX
will now translate double byte code page references to Unicode correctly so that
item files that contain mixed Unicode and double byte code page references found
in Vietnamese item files for instance now work) and a built in introduction/demo
item file that made me nicen up a number of DMDX's features related to textual
display (you can tell retirement can be a tad, unchallenging, shall we say)...
04/01/18
So more to save me thinking
about it every time it comes up in conversation than any actual request for it I've made the modifications to DMDX
5.2.0.0 to support AMD's FreeSync and NVidia's G-Sync technology along with a
couple of new test modes (14 & 15 in version 5.2.0.1) for testing how the
freesync code is running (given that the video handler is now being called every
millisecond or so instead of every retrace) allowing the presenting of displays of any arbitrary duration as long as it's as long as or longer than the minimum refresh interval of the display itself (typically these devices appear to have a native refresh rate of 144 Hz which opens up displays down to 7 or so milliseconds). For the uninitiated
in a FreeSync or G-Sync system there is no longer any fixed raster interval as such, instead retraces are generated whenever there's a change in the display.
11/13/16
DMDX 5.1.4.2 finally resolves the issues the Direct3D renderer had with
digital video. While the previous code developed in 2014 ran moderately well
combining it with <AbortItemExpression> would produce crashes (and of course the
vast majority of the time if you're using <dv> you're also using <aie>).
After an extensive debugging session I discovered that only wholesale
reconstruction of the way the Direct3D video rendering code operates would solve
the crashes given the completely evil way the VMR9 code was functioning (it was
doing things like allocating surfaces after it was given and acknowledged the
stop command). Of course, this is probably the way I should have gone in
the first place as (a) it's simpler and (b) closer to the example code but it
didn't occur to me at the time and that's because I now just block the VMR9
thread once it's produced a frame to be rendered until DMDX finally renders it,
no more out of phase efficiency and so on. While more of a bug fix
than a feature update this is likely to be the last new development for DMDX as
the UofA has cut my position and unless someone else decides to fund DMDX's
development (or a relative of mine needs something) I'll just be doing minor
fixes and answering questions on the list serve. I'll also keep psy1 alive
as long as possible for remote testing and other services it provides, it's
already been converted into a VM running on John Allen's servers so kudos to him
for stepping up and helping the wider DMDX community. It was an amazing 20
years (almost thirty really if you include DM and DMTG the immediate
predecessors to DMDX) and while I never thought I'd build a Turing complete machine
(I'm pretty sure DMDX is one) it's so long and thanks for all
the fish...
06/17/14
And in right quick time we have DMDX 5.1.0.0 where we
exploited the new 3D rendering path to support NVIDIA 3D Vision stereo shutter
glasses...
05/09/14
OK, it's time to release DMDX 5.0.0.0 and TimeDX 5.0.0. While there are still a few problems with digital video playback under Direct3D in DMDX 5 and the experimenter's display when using Direct3D is a nice uniform shade of blue the absolute vast majority of people aren't going to notice and it will take me quite some time to resolve those issues (the VMR9 code for Digital Video has already sucked the last two months of development time I have and there's no sign of it being perfect yet) and there are for sure more and more people with Windows 8 that are using DMDX so it's time to get the general distribution updated to handle win8.
03/21/14
Alpha versions DMDX 5.0.0.0 released to check the new 3D rendering path needed for
rigorous tachistoscopic performance under Windows 8.
05/13/09
DMDX 4.0.0.0 released with soldieron mode to handle DDERR_SURFACELOST recovery (improved handling when not soldieron too),
unicode macros and a major overhaul of original macro code.
03/12/09
DMDX 3.3.0.2 adds a Unicode path to DMDX with the -unicode command line option
to deal with otherwise intractable Asian fonts. Didn't ever really think we'd make
a Unicode DMDX but due to a fortuitous feature of RTF text files it turns
out it was relatively simple for 97% of cases, moderately complicated for
another 2% and only a right pain for the last 1%... Amongst other recent
developments we've been working on a remotely executable version of DMDX
that's packaged up in a self extracting archive that lets experimenters post
experiments on their web servers and have users run DMDX on their machines.
It's using DMDX's EZ mode that dispenses with raster synchronization and once
a bit more work is done that will allow DMDX to handle a loss of application
focus it should be pretty solid.
09/13/06
DMDX 3.2.0.1 adds data logging functionality to the 2D input devices added
in 3.1.0.0.
10/14/04
DMDX 3.1.0.0 dramatically increases DMDX's scope
with the ability to handle 2D inputs for touch screens and a special mode to
handle the system mouse.
12/12/02
As far as I can tell all of the work I intended
to do (and then some) for Version 3 of DMDX is done, DMDX 3.0.0.13 and TimeDX 3.0.05
look like a wrap. Among the myriad things added are an installer, a .CHM help
file that is searchable with an index and a table of contents, radically restructured
RecordVocal and DigitalVox devices that won't break a lot of broken audio drivers
and that allow variable length recordings, input devices that work on any international
machine, and last but by no means least a vastly improved automatic refresh timing
routine in TimeDX that I've only seen fail on machines with broken video drivers
where DMDX wouldn't stand a chance of running anyway (and when it does fail it fails
safe with a notice for the user so if it works at all it works properly).
Of course, there are a ton of smaller changes too.
07/29/02
I'm currently porting DMDX to the Microsoft Visual
C++ 6 compiler and there will be several repercussions. First,
the version number will be 3 and the previous 3D work will be dropped.
Also, there will be a semi-major version number (as in 3.0.0.00) added as I expect
version 3 will be around for large number of years. I don't think
the 3D path is going to eventuate so DMDX's current structure is likely to have
extreme longevity and I'm going to need more flexibility for version numbers.
Lastly, Windows 95 support is going to be dropped. The current
version 2.9.05 will get archived for anyone that needs 95 for an OS as 1.3.01 is
currently archived for anyone that needs 486 processor support.
Other than that no one should be able to tell the difference although several aspects
of the program are likely to become significantly optimized (notably the high performance
timer code). There may be other repercussions, I'll know as the
work proceeds.
12/26/00
I thought I'd just whip out a RTF to HTML converter
for windows help files, wrong. Instead, after days of head
pounding recursive call nightmare debugging sessions we now have a rather finely
crafted RTF2HTML utility with the resulting Help files now online at:
https://psy1.psych.arizona.edu/~jforster/dmdx/help/dmdxhdmdx.htm and
https://psy1.psych.arizona.edu/~jforster/dmdx/help/timedxhtimedxhelp.htm.
The ASCII art is still kludged but at least it's usable now, after spending a day
looking at what I'd have to do to automate bitmaps in the .RTF file that could either
produce .HLP or .HTML the kludge and the ASCII art don't look so bad at all.
10/10/00
I switched DMDX 2.1.00 to use DirectX version 7 so
that a TimeDX Enhanced Retrace Rate test can be done. The new
test allows unequivocable measuring of the retrace interval, the catch is your video
card must be capable of unsynched flips which basically means it has to have been
made since DirectX 7 was released last year some time -- or at the very least to
have had a completely new suite of drivers released for it that know about DirectX
7's new features. This probably means that machines running 2.1.00
should have DirectX 7 installed (sorry, but I can't test it, all my machines already
have DX7 installed and I'm not about to retrograde any of them as I've never found
a downside to having version 7 installed), DX70ENG.EXE for the English version at
https://psy1.psych.arizona.edu/~jforster/dmdx/directx/.
08/07/00
Ok, the preliminary release of DMDX 2.0.00 and TimeDX
2.0.01 are up on the website. The old version of DMDX (1.3.01)
is still available in DMDX1301.ZIP, I won't be deleting it any time soon as it's
the only version of DMDX that can work on old 386 and 486 machines.
I won't be updating version 1 again, any fixes or modifications will be made to
the version 2 code. The new version includes greatly enhanced
(read largely re-written) support for multi-monitor machines (the secondary subject's
display can now be a part of the windows desktop which it tends to be by default)
and exclusive use of the win32 Performance Timer (read microsecond accurate RTs
if you can find an input device that accurate and basically more accurate timing
all round). I'm still working on it, sorting out joystick polling
issues raised previously and other things but testing by me to date indicates I
haven't broken anything and that RTs are in general at least 0.3ms more accurate
than they used to be so I'd like people to at least start testing it.
Note, you must use the new TimeDX to record registry settings for the new DMDX,
they use different forks of the registry tree (so version 2 settings won't upset
version 1 code).
05/23/00
Well I finally crafted a reliable retrace rate determination
routine -- well as reliable as '98 will allow. Instead of trying
to detect the retrace I realized I could simply use the Flip routine that changes
the displayed page of video memory, as it can't be executed twice in a row until
the first flip is finished it's guaranteed in synch, and given that TimeDX 2 is
only using the high performance counter it's just a case of call Flip 100 times
and wait for the last flip to finish and divide by 100, viola, accurate values to
2 significant digits (or more with larger Ns). This removes what
I consider to be TimeDX 1's most crucial failing.
05/20/00
I have begun the version 2 re-write.
Issues addressed by this will include optimizing the code to only use the High Performance
Counter found on Pentium class machines (read: "no more 486 support"), redesigning
TimeDX's and DMDX's use of windows so that MultiMon systems are far less prone to
problems and in general cleaning up a lot of TimeDX that is no longer of any use.
Hell, I might even update which DirectDraw interfaces are used, get away from using
the original DDS for Flip but DDS2 for everything else (because DDS2->Flip is
fucked broken) and use DDS3 for everything. 'Course,
then I'd have to figure out the new damned GUIDs...
07/22/99
Among many things that 1.1.10 has in it is another
new input device, the RawJoystick. This device simply polls port
201H that is the low level interface to the ancient IBM analog game port interface,
it doesn't use generic routines that read the axes so it is as fast as a PIO12 and
due to the enhanced ease of wiring up switches (no more messy resistors) it becomes
the method of choice for millisecond accurate custom response switches.
The DigitalVOX tests now also checks for incompatable sound devices that report
functionality but in fact provide no data.
06/07/99
I knew I shouldn't have released 1.00, no sooner
is it out the door than another major feature is added. Now we
have version 1.1.00 that has a couple of new input devices, the DigitalVOX device
and the RecordVocal device. The DigitalVOX input device does away
with external electronic voice keys using a microphone and sound card instead and
the RecordVocal input device writes the subject's vocalization to disk.
Also, I accidentally wiped the update in here about
the DMDX mailing list. The idea is that if someone is having trouble
they can post to the list instead of mailing Ken and if someone other than us has
solved the problem they can perhaps provide the answer. So far
it looks like it's just a mechanism for me to answer people's queries, haven't seen
much if anything in the way of trivial problems. If you want to
be on it send mail to DMDX-request@psy1.psych.arizona.edu
with the word "subscribe" by itself with no quotes in the body of the email (not
the subject). Once your subscription is confirmed posts can be
made to DMDX@psy1.psych.arizona.edu.
The list archive is available at
https://psy1.psych.arizona.edu/cgi-bin/DMDX/thread
.
05/04/99
Ok, the problems section is empty and the to do section
is full of little things that I might never do, 1.00's out!
The help file is now a new beast with indexes everywhere and the latest tweaks
have been applied to the multimon code. To celebrate Ken is putting
the finishing touches to his user level documentation (as opposed to my stuff that
is more or less reference level).
04/23/98
1.00's gonna take a little bit longer, I've decided
to rework the DMDX help file providing indexing for all the keywords and it's a
lot of work.
04/12/98
Long time no update, this puppy's getting pretty
stable. Version 0.27 incorporates fixes and features needed over
the last few months, once I've added a few more key things like an <OverSize> keyword
to catch stray pixels with arabic fonts version 1.00 should be released.
Things fixed or added include: <StreamingAudio> for long audio instructions, <NoNTNPrompt>,
<pan> and <volume> for wave files, <xy>, wave file and graphic file of same name
confusion fixed, repeated nut to butt playing of the same wavefile, keyword parsing
issues when no spaces separating two of them fixed, <ClearFeedback>, and <TimeCriticalFrames>
for suppressing error messages in .AZK output for people that don't care at all
about errors or only wish to know about errors when they count.
11/10/98
Stuck a few semantical checks in to 0.22b to catch
obvious errors with clockons, missing CRs and frame delimeters.
10/28/98
The ability to tune priorities of processes has been
added to 0.22, more as an exploratory effort to see if the display error rate can
be lowered on some machines still having trouble -- there will probably be much
more tweaking here as doing things like making the retrace thread supreme also means
that the PIO inputs aren't polled while it's active, not to mention the possibility
of bombing some other part of the OS (although it currently looks like DirectX just
ups the ante when DMDX boosts itself, possibly not a bad thing because then DirectX
might stop functioning if it didn't up it's priority). See TimeDX's
Advanced / Task Priorities for more info.
10/13/98
Multiway branching added to DMDX 0.21, fixed the
missing " crash. It would appear that DirectX 6 fixes the pauses
after DX initialization, apparently previous versions wrote to the registry after
startup and this would take some time to get flushed. People with
excessive refused flip messages should be aware that reducing the sleep time in
TimeDX fixes this problem.
I'm tweaking all the priority stuff so the next version
may have significantly improved immunity to other machine activites (not that the
current stuff is shabby), due primarily to my realizing that high performance timer
code will not be blocked by a THREAD_PRIORITY_TIME_CRITICAL retrace sync thread
(the original callback timer code is blocked); between that and boosting the whole
process to REALTIME_PRIORITY_CLASS there should not be anything that stands in it's
way (hopefully, not at least according to my process viewer).
I'm also changing most of the file I/O over to pure win32 function calls so I can
use a flag (FILE_FLAG_WRITE_THROUGH) that makes any disk writes get performed at
the time of the call as opposed to some arbitrary time later, usually in the middle
of a tachistoscopic presentation. Changing these kinds of things
is likely to upset large portions of DMDX (like the Digital Video already looks
like it's gonna need a bit of TLC) so you might wanna make sure you keep a copy
of 0.21x before using the next release.
9/30/98
Found a major oops in TimeDX 0.29 remembering video
modes with some number of scan lines other than 480 and then re-programming the
number of scan lines to 480 (say 800x480 instead of 800x600) the next time it ran
(which crashes the DELL Inspiron 3000 laptop, not too surprising, which b.t.w. is
very nice DMDX box). Also, in version 0.20a of DMDX the <ZillionEnterKey>
keyword/MDSP bit has been changed to provide feedback as the user types a response.
9/25/98
The .IMG file to .BMP converter
IMG2BMP is
done along with DMDX 0.20 which when used with <DefaultBMPMultipliers 1.0,1.371>
will stretch all the .BMP files to the correct aspect ratio. Version
0.20 also includes dramatically better WYSIWYG .RTF file parsing in that you no
longer need to make sure text formatting falls inside the text double quote delimeters.
Oh yeah, the default output format is now .AZK, if anyone wants a .DTP file they
will have to use the <DTP> keyword (I doubt anyone was using it as there was a bug
in the code that wrote the binary data).
9/10/98
Released DMDX 0.19 with alpha blending, stretchable
bitmaps and Digital Video. There is a Digital Video demo that
lives on PSY1 because
it is over 4 megabytes. I'll probably be writing a monochrome
.IMG file to .BMP converter given that you can now stretch bitmaps in DMDX, I'll
probably also implement a global bitmap stretching factor similar to the <FontMultipliers>
switch.
8/20/98
Added alpha blending to fade from one frame to the
next, very cool if CPU intensive. The demo item file Features.RTF
now requires a 16 bit per pixel display to facilitate the alpha blending demo and
the graphics (which should always have been displayed with a 16 bpp display).
8/19/98
DMDX 0.18 released. Digital Video
will probably be in the next version, till then I had to release the current fixes
which include: fixed REQUSCHED and D param (use of either resulted in ISI times
in tics that were the value of the current millisecond timer, oops), last used item
file now remembered, fixed rect. of wrong color on some devices, <!> remarks, tuned
multimon code to use DETACHED secondary displays (that are not part of the desktop),
introduced <safemode> for latched up item files. All video modes
will need to be re-timed as the registry key names have changed to facilitate differentiating
between identical display cards on multimon systems (I've also changed the default
sleep times to free up more CPU cycles on machines with High Perforamce counters
[read: all pentiums]).
7/17/98
In the process of adding (or seeing if adding is
possible) support for DirectShow enabling the display of .MPGs, .AVIs, Apple QuickTime
and whatever else it supports. If it works (and doesn't blow the
rest of DMDX up) there'll be a new frame specification akin to the sound and graphic
frame specs, it's duration will be however long the .AVI (or whatever) file plays
for -- I've seen no reference to cursors in the multimedia file formats yet so cursor
control will not be immediatly forthcoming, perhaps the duration will be overridable
and the initial playing position but these are likely to be values in the item file,
either time, percentage or number of frames. .AVIs will be played
full screen (this could be overridden in the item file I suppose), it's faintly
possible that the audio from the .AVI and DMDX could be mixed although there will
be no special attempt to get them in synch (if you want the audio in synch with
the video put it in the .AVI that way).
6/23/98
Despite MicroSoft's decision to not make DirectDrawEnumerate()
function the way they said it would function I have managed to get the Multimon
stuff functioning -- 'course you need '98 to do it but DMDX will function with it
when you get a Multimon system together. Currently the only cards
I can find that function as a second display device are cards based on the S3 Trio
64 chipset.
As a result of the secondary display device being
a memory mapped device the code that re-programs the number of scan lines on a display
cannot function with a secondary display device, maybe I'll have luck and find that
there is some sort of standard for memory mapped displays but don't hold your breath.
5/18/98
Made the Naming task Negation code use the remote
Monitor (if found). Changed the PIO code to allow changing it's
base address, primarily done because Computer Boards is making a PCMCIA card with
an 8255 on it (the PCM-D24CTR3) and it doesn't have jumpers on it so people will
have to run the configuration utility to change the address -- on top of that it's
generally more difficult these days to make sure 310 is free for the PIO.
This means laptops can now have millisecond accurate response gathering (which they
basically lost with the advent of the ECP and other variants of the parallel port).
5/14/98
Put the start and end cue code in to play portions
of wave files, fixed a number of small things (like 24 bit wave files causing the
machine to allocate something like 64 megs of swap space...), changed the demo quite
a bit.
5/7/98
The remote monitor network code is coming along nicely,
this means you can monitor DMDX's operation from another machine assuming they are
networked together with TCP/IP. Pretty cool if you ask me.
Seeing as it's TCP/IP that machine can be anywhere in the world which at first I
thought was pretty useless, but as Ken points out, it actually stands a chance of
being useful for us to remotely diagnose a machines operation without having to
transfer the diagnose.txt files -- not that that's any big inconvenience transfering
the file.
4/28/98
Put a syntax check only mode in that quickly checks
syntax and media files used.
4/16/98
Left the implementation of the millisecond callback
to dispatch vid_int() INCOMPLETE. movingimages() (I guess) screws
up when there is a long lag between msec callbacks and seeing as the whole operating
premise is that this doesn't happen I'm not going to invest any more time in getting
it going. Maybe NT has a better callback (the opinion of people
on the wire appears to be that NT has much better multi-tasking) but that can be
left for a later date. Looks like we're going to implement the
ability to play a section of a wave file between cursors, or more accurately, the
ability to play a file from some point other than it's beginning and the ability
to stop playing a file at some point other than it's end.
4/8/98
Implemented the ultimate in retrace syncronization.
If the high performance counter is present (and it would appear to be present on
all Pentium machines) DMDX uses the millisecond callback to dispatch vid_int() as
the callback is the only thing that doesn't get pre-empted too much.
The blitter I suspect still gets it and things that grab the win16 mutex probably
also get it; the former is still dealt with by keeping the blits small and the later
are not much of a problem as they are typically associated with the drawing routines
and they are typically not active during critical displays. The
reason this wasn't done before was that I hadn't yet thought of a way to do it (you
can't sleep if you are running at real time priority) -- needless to say the final
result is an amazingly complex process. Now, if I can just get
it working properly...
3/27/98
Made a nice little demo that'll go up on the web
page when I've fixed all the little things it turned up in DMDX...
3/19/98
Due to the joysticks extreme usefullness as an input
device (error of +/- 1.5ms or so) and the fact that a program compiled with the
DX 3 SDK can't see a joystick on a DX 5 machine we have decided to make the minimum
version of DirectX needed 5.0 instead of 3.0.
3/13/98
Two historic dates on two successive Friday
the 13ths, ooooh. It's benched and I didn't find anything
out of whack ('course I've also fixed a dozen things too). The
thing's smart enough now to detect if a loss of synch has occured at a critical
time and flag them as display errors (might eventually write this to the ascii output
file, I dunno) otherwise it gracefully recovers so my guess is it's just about
done. Call version 0.08b the Beta release. The only other things to be added are
minor details (like the ability to use a cursor in a sound file to set it's duration
to sync. with the visual display). And of course fixes for the
odd combinations of things that don't work that will always pop up...
Hot damn, I was even using the animate switch with sound files in testing it.
3/11/98
Sound is done. Well, at least,
whole files anyway, playing portions of files between cursors can wait for looong
time. Next benching and more benching.
Man, DMDX has more threads than you can poke a stick
at. The kernal (your operating system) has three threads (typically),
DMDX has one for the main processing of DMDX, preparing images and moving them into
video memory, a second thread to keep track of the vertical retrace, a thread per
input device, a thread to play sounds and it uses the system timer callback, effectively
another thread. That means your average DMDX with two input devices
has SIX threads!
3/7/98
All input devices debuggered, haven't measured their
latencies (on our machines anyway) yet. Output debuggered too.
Response contingincy crashes it but other than that (and the hundred other things
that haven't been found yet) it's probably usable. Sound goes
in next week.
3/4/98
The keyboard and mouse drivers work (polled PIO and
joystick still to be debugged -- actually output and and just about everything else
too), but it is a functioning Dmastr nonetheless.
3/2/98
Finished coding the input stuff.
About as complex a thing as I have ever designed -- with the number interruptions
I had while writing it it will have some interesting little funkadoodas for a while
I imagine.
2/13/98
Finally deduced how to get the back buffer's COM
objects, the documentation is wrong about three different ways...
Anyways, another historic date, we have tachsitoscopic Dmastr under
Win32, DMDX lives! No input or nothing,
just display only (well, it does use a space bar for a request), but it goes and
it uses all available video memory to do it's thing and I ain't getting error
messages out the wazo about it not being able to get things displayed at the right
time so it's cookin'.
2/10/98
Nothing like a 13 hour straight coding session at
home ('cept for a slight break to break in the new driver at the driving range,
a real splurge there with a TI Bubble 2, mmmm hhmmmm) to figure out the nitty gritties
of the display code. Colds are good for something I guess.
Which, I might add, was a good deal more tricky than I had realized, I hadn't quite
scoped out just how complicated any number of back buffers can be if you aren't
blithely updating the whole buffer. Not to say it's all working
yet, or even running with real page flips, but the simulated mode is mostly together
which is a huuuge step. Put it this way, it works
well enough that if you accidentally turn the clock on it latches up like Dmastr's
supposed to if there's nothing to respond with (and there ain't, not yet anyways).
2/6/98
Most of the drawing routines are done, although there
is probably going to be many modifications owing to the possible complexity of RTF
syntax and DMDX implimentation of a subset of it. Next comes the
tricky bit, the tachistoscopic routines that take what has been drawn in memory
and display it in a timely fashion -- I am going to leave the sound till last, too
many people need basic DMDX ASAP. Finally got tired of Word 6.0
(my file names tend to be longer that 8.3 these days...) and installed 97 and noticed
this convert to HTML option so I converted the help files for TimeDX and DMDX and
put them up (above) so people can get a better idea of what's happening.
1/28/98
Well, after a slightly longer than intended break
(the engineer resigned leaving me to carry the technical support load by myself)
I am back at it writing the drawing routines. Got off to a good
start by lifting a rather complex set of function calls from the MicroSoft site
(and adding a bunch of error checking) and having it all work, TimeDX can now load
BMP files -- just how well and how many different types remains to be seen, but
it's a good start and if bits of it don't work I am at a loss to see how I could
change anything actually...
12/11/97
item_sched() started. Looks like
we won't be getting any early betas in December as I will be leaving for Oz soon
and will be back in January when work will commence on the graphic code (text only
to begin with) and then the video memory frame buffering display code -- so maybe
late January instead. item_read() is no longer limited, no max.
item size (within reason, as with all unlimited DMDX things your machine's RAM poses
the only limit), the display queue will be the same, no number of frames limit.
12/01/97
Cleaned up a few bits of TimeDX and DMDX's scrambling,
figured out a bit of the palette madness that is Windows in 256 colors.
Started moving job_get(), item_read(), getp() and all manner of timeless Dmastr
routines into DMDX.
11/18/97
Built the keyword parser and modified the scramble
routines so there are no limits other than available memory, no block number limits,
no fixed text limits, no items per block, nada. Fixed a long standing
error in the scramble routines dealing with $$, it still isn't correct leaving a
stray $ in the scrambled output, moral, don't use $$, use $ $.
11/13/97
For want of being unable to decide what to do next
I have begun writing the RTF parser and scrambling routines for DMDX.
Looks like the RTF is going to be a can of worms for a while, largely because there
are so many things you can do with RTF that DMDX will not do.
11/03/97
Re-did the retrace code so it can take advantage
of the high performance timer if it's present, and it's sweet.
So good, the automatic sleeping and timeout values are actually usable now.
Added detection of certain errors so there is the strong chance of DMDX being able
to take emergency measures should '95 grab the CPU for a while.
Chucked a few ping packets at a box keeping synch with the retrace and it didn't
even notice them, a very good thing as the network is rapidly becoming an indispensable
part of a computer.
10/24/97
Well, having found out the behavior of the millisecond
callback I have incorporated the High Performance Counter into the millisecond code
and it appears to have had a good effect, at least I can use the highest priority
for the retrace sync thread now (it used to over-ride the millisecond callback,
now using the high performance counter the time is not dependant on the callback).
Actually, given the thing's resolution (microseconds on these pentiums) I may be
able to measure the retrace exactly and do things with it, more testing will ensue
to see if this is indeed necessary as it's looking very good already.
10/21/97
Found out one of the reasons it's so hard to keep
track of the retrace, the millisecond clock is all over place.
It probably has 1000 callbacks per second but the phase varies all over place, time
between callbacks can vary from .2 msec to 1.8 msecs... Probably
and argument for the fastest damned machine you can afford.
10/17/97
Historic Date. The file
DMDX.CPP has been created. Doesn't do spit, but it is
created. Gotta make TimeDX export it's Driver settings to the
registry so DMDX can get at them.
10/15/97
Sound Latency test completed. Revealed
the fact that even though an emulated (no hardware support from DirectX Setup App.)
DirectSound driver may sound perfectly nice it's onset time is through the roof
(200-300ms for the emulated Crystal CS 4232). A sound card with
a driver supported in hardware (Sound Blaster 16, not emulated) has an onset of
15ms or so, this will vary with CPU and sound card. Mixing multiple
sources appears to have negligible (2-3ms) effect.
10/13/97
DirectInput done, good thing the DirectX 5 docs were
at hand, I'd never have figured out what was supposed to happen from the DirectX
3 docs, rather akin to learning a language from a dictionary, it assumes you know
what you want to do and what all the parts are for already. Might
check the latency of DirectSound mixing as I saw a worrying reference to it being
slow in the News Groups. Thinking hard about DMDX design.
09/24/97
Tachistoscopic routines appear to survive having
the sound system active, there is a larger timeout rate with cards not supporting
the DirectDraw GetScanLine function but it's only a few percent and there is no
visible visual degradation (read loss of synch with the retrace).
There also appear to be longer periods on all machines where the timeout rate goes
right up, but even then it does not appear to be catestrophic.
Guess I'll have a look at DirectInput and then it's time to start thinking hard
about DMDX's foundation.
09/20/97
Yowza, got the sound going, only one fantastically
subtle error in there -- DirectSound was carefully muting all my buffers for me
because it thought TimeDX was two apps and not one, a little frustrating.
Thank God I can't meditate otherwise I'd have never figured that one out, sitting
for meditation allows one to see really subtle things if one isn't actually absorbed
in the state one is supposed to be absorbed in, as is the case almost all of the
time with me. Next we see if the tachistoscopic routines are upset
by DirectSound stuff going on.
09/16/97
After a break for illness and other projects I am
back at it. The PIO code is completed, now the sound code.
08/01/97
Major success this week, didn't even have to pull
too many hairs out. Built code to re-program the number of scan
lines on the screen (read, adjust the refesh rate) and to access the PIO card.
The hairs come from the fact that this is Win32 and you're not supposed to access
the I/O ports anymore, and to enforce this the compiler indeed no longer has inportb()
etc., so you have to buy the Turbo Assembler (32 bit version) just for two instructions.
Sheesh.
07/16/97
Used Event Signaling from the video retrace thread
to the tachistoscopic routine (so the thread doing the tachistoscopic presentation
goes to sleep till the retrace thread specifically wakes it up), a much less daunting
task than redesigning the whole damned thing and it works much better
than on 07/13/97. It even works through Multiply Missed retraces,
something I was hoping for and am impressed to see working (which is not to say
there is not a bunch of code to make it work, just that it's amazing that
it actually works without me having to pull my hair out fighting the SOB), although
a lot of that is still dependant on how well the user tunes the sleeping and timeout
values for a given video mode.
Matter of fact it's working so damned well right
now I don't think it'll ever muck up a prime (unless it's too big), especially if
I implement triple buffering in the video routines.
07/13/97
Well, I've been playing with the Tachistoscopic Acid
test for a while now and as best as I can tell DMDX is going to loose track of the
retrace periodically and that's that. Meaning that every now and
then a frame is going to be displayed for longer than requested because some other
process (read KERNAL32.DLL) is going to snatch a bunch of CPU cycles and as of right
now there ain't spit I can do about it and it ain't for lack of trying, believe
me. Time will tell if I can minimize the interferance further,
but my guess is it's only going to get less, not go away. About
the only occasion I can think of where this is unacceptable (and un-get-aroundable
except by using DMTG) would be where you don't want people to know if there is a
tachistoscopic prime at all, ever -- because every now and then one of those primes
will be visible, might only be one in several hundred items, but you won't miss
it when it happens. Your stats should wash these out without any
trouble and the voice parts of DMDX will know about it so the sound will get back
in sync (assuming you are not playing enormous many second long sentences, I can
only re-sync when any given sound starts) so it's not a total wash, DMDX can still
be built, but it's not going to have the rock solid nature DMTG has.
A price we pay I guess.
Seeing as the ONE routine I can rely upon is the
millisecond timer I'll try reconstructing the tachistoscopic code using the millisecond
callback to Flip the displayed page and see if things work better.
06/27/97
Had a little bit of trouble building a reliable vertical
retrace synchronizer, time will tell how well it functions on different boxes as
it can utilize one of two possible schemes depending on the video card.
I'm back to using passpoints -- with multiple threads, millisecond callbacks and
DirectX page flipping I don't think anything short of an ICE would handle TimeDX.
06/12/97
Millisecond interrupt code completed.
Turns out that hidden deep in the Multi Media extensions there is a usable millisecond
interrupt -- kinda, but it appears to be working. Major hurdle
overcome there, many thanks to Deja News
http://postnews.dejanews.com/ without which life would be much harder than it
currently is.
06/04/97
Lordy Hallelujah, found the Flip hang, there it is,
documented all the way four levels down in the last minute release notes, "BTW,
DDS2->Flip may hang, use DDS->Flip as a work around". DirectX
is a seriously tough thing to interface to without thousands of dollars for MSDN.
Even with the public DirectX news group that still took days.
05/29/97
Tired of fighting BC 4.52 and will now use 5.01 till
5.02 turns up in a week or two. At least I can step through programs
now instead of suffering from passpointitis. Of course, that's
assuming I am not deep in a bit of EXCLUSIVE mode DirectX where you can't see nottin
'cause the IDE don't know about DirectX... Must see if I can get
the debugger to run over the net between the two machines, but I'd have to RTFM
for that so it'll wait I guess.
05/14/97
Font selection code in TimeDX done.
First bug in DirectX circumvented, must not release a DirectDrawSurface until the
derived DirectDrawSurface2 is finished with. Sometimes.
05/05/97
First step of TimeDX done, code to initialize DirectDraw.
This actually represents a hell of a lot of work (like at least 1000 pages of documentation
read to begin with).
DMDX Updates
Page.
DMDX now has a built in introduction, just click the
Introduction button or
you can
see
the text here.
Windows 7, Windows 8.1
and Windows 10 (recommended), and 11. There
are no Macintosh or Linux versions of DMDX, nor are any versions planned,
however using
the Direct3D renderer DMDX works reasonably well in a VirtualBox virtual machine using
their "experimental" WDDM Direct3D drivers in their Guest Additions
and I see people running
DMDX on a Mac using Wine or a Wineskin. Windows
95 support has been dropped and is only available in the archived 2.9.05 version.
Windows
98 support was dropped in version 5 so you'll need the archived 4.3.0.1 version and
Windows XP and Vista were dropped in version 6 so you'll need the archived
5.3.3.0 version for them (although I suspect 5.1.3.4 was the last one that
operated with XP as when I recently set up a XP virtual machine it complains the
later binaries aren't win32 executables so the new compiler is producing
something XP can't grok).