DMDX Help.


Differences.

   
    Listed below are the key differences between DMDX and previous versions of Dmastr, DM and DMTG.

    By default DMDX now produces .AZK output files, if a .DTP file is required use of the <dtp> keyword is required.

    The command line has gone completely and the ability to transfer files and so on has not been implemented (except as the standalone UNLOADAZK utility available in the DMDXUTILS.ZIP archive). About the only things left are the ability to run a job and the ability to abort it. Control C has gone, the escape key (ESC) is used to abort a job instead. When a job finishes the last item will be left on the screen until the ESC key is pressed at which time instead of being asked to abort the job DMDX will ask if you wish to save the data (if you don't the data is gone, you won't get another chance to save it).

    Besides the fact that item files are now Rich Text Files (RTF, see Item Files. above), item files now have keywords and operands enclosed in angle brackets as well as the traditional switches and parameters. Keywords are implemented for all traditional switches and parameters used in DMDX (ie, things like the L parameter and the I switch have disappeared). A list of old switches and their new equivalents is available under Original DM/DMTG switches.

    Graphics have changed radically, DMDX reads window's .BMP file format. You should check the specific notes on Bitmaps.

    The input subsystem has changed dramatically, see Input.

    The VM extensions to DM and DMTG have not been implemented, instead a new frame type, indicated by the <Sound> switch has been created. The channel specification is part of the <Sound> switch itself, the duration of that frame will be the duration of that .wav file (unless overridden with the <FrameDuration> switch). The ability to make the frame's duration end when a cursor is played is implemented with the <SetVisualProbe> switch. The sound will not cease to be played when the frames duration expires, simply the visual system will resume it's display, also many sounds can be played at once (although there is some additional overhead, what this is remains to be determined, initial benchmarking has it at a few milliseconds). See Sound below.

    Scrambling block, group and number of items limitations are removed. Item size too. For that matter all arbitrary limits have been removed. Item files must be small enough to fit in memory, however we should have a special prize for the person that builds a real item file that exceeds this limit (assuming of course that they're not running DMDX on a machine with only 8 megs of RAM).

    Color specifications have changed, no longer are palette indexes specified for writing colors but instead RGB triplets are always used regardless of whether the display is 256 colors or 2^24 colors. These are specified to DMDX as a kilo color spec.

    The parameter line is extendible. If the keyword <extendedparameters> (or <ep> for those who dislike lots of typing) occurs in the traditional parameter line (the first physical line of the item file, forgetting about all the RTF stuff that you don't see) then the file is processed as parameters until the <endofparameters> (or <eop>, or </ep> for HTML people) keyword is encountered.

    There are another couple of frame delimiters in addition to the slash (/), the comma (,) and the colon (:).  Of the two the comma by far the most common one to be used as the colon is only relevant when using the NVIDIA 3D shutter glasses.  When the comma is used it is equivalent of putting a %0 in the frame before the comma and a non-erase in the one after -- ie, it merges the frames together in a very easy fashion. The comma frame separator being an intrinsically visual operator is not usable with sound frames as they are non-visual.  A common mistake made with the comma operator is to specify the duration of the merged frames in the first frame in the series, however because the comma frame delimiter is exactly equivalent to %0 / ! the duration is overridden by the %0.  Putting the duration in the last frame of the merged series solves this issue.

    Branching can be performed relative from the beginning of the input file (instead of the current item) thus enabling endless looping. If the destination branch item number is negative (and the branch conditions are met) it is negated, the input file is rewound to the end of the parameters and that item number is searched for. The negative item number has nothing to do with the '-' CR indicator. There are also branch types that allow branching that is conditional upon the error rate being greater than or less than a certain figure (these also reset the error rate regardless of whether the branch is performed or not so as to allow for successive uses). There are also a bunch of counter related keywords, see the <SetCounter>.

    DMTG went to inordinate lengths to emulate DM's screen erasing behavior, a feature that was very difficult to implement and which to my knowledge has absolutely never been used, worse, it only got in people's way, hence the creation of DMTG's E switch. Well, to hell with that, it's gone. Now, unless you specifically specify the <NoErase> or the <OnlyClearBehind> switch anything that was on the screen will be erased, the code keeps track of everything on the screen including instances of the <NoErase> switch (even multiple uses of it). The <EraseAll> switch has been implemented in DMDX only as a last resort in case the display engine breaks and for some odd reason (like a font is bigger than windows thinks it is which I have seen, there is code to deal with this, but you never can tell...) stray pixels are left on the screen -- be warned, arbitrary usage of this switch has severe performance penalties as it's use causes that frame to update the whole screen (better to use the new <OverSize> keyword that cleans up those stray pixels). Additionally, coincident with the removal of palette manipulation a mechanism has been added to change the background color, the <BackgroundColor> switch (and parameter) and, while I am at it, the default screen background is now white and the writing color black (although the writing color is always specified in an RTF file so it's moot unless the MDSP bit RTFCOLOROVERRIDE, 020000 has been set, see <RtfColorOverride>.

    The way the <Animate> switch has been implemented is rather different and although it's eventual function should be the same as DMTG's A switch there is more time required for the preparation of an animated item (roughly double the regular amount) and much more time required before the next item commences. The extra time for preparation is due to the frames having to be generated in the usual fashion and then re-made with a border large enough so that any frame will erase any other frame as DMTG's frames are, not the usual case with DMDX, usually each frame is exactly big enough to erase the previous frame (ie, every frame is a different size whereas for animation they must be all the same size). The time at the end of the item has to do with the much more sophisticated screen buffering available with DirectX, when animation is used there is little hope of me being able to write a smart enough algorithm to determine the state of all the screens back buffers (DMTG only had one buffer, DMDX will use up to 24 if you had an 8M video card and used 640x480x8bpp), so DMDX simply clears the lot after an item's use of animation. Fortunately you can get an idea of the size of these times with the Preparation Times A and B (see below in Errors you might encounter).

    The method of input is now restricted to the PIO12 inputs, see Input. Also the PIO12 device can read 16 input lines, the PIO12output16 device only uses 8 input lines and instead provides 16 output lines. The PIO12output24 has no input lines.

    The <LastFrame> (old L) switch has been rendered nearly obsolete as the code checks to see if another item follows after parsing the current one and if nothing but whitespace follows it flags the last frame as being the last frame.




DMDX Index.