MS Frame Duration Keyword
<MSFrameDuration N [emit]>
<msfd N [emit]>
% switch and F parameter alternative. Unlike the traditional % switch
keyword this keyword specifies a frame duration in milliseconds. On systems with high performance counters DMDX knows the retrace interval to within a few microseconds and this can be used to calculate frame durations in milliseconds. The result
used to be (prior to version 188.8.131.52 of DMDX on 01/30/13) rounded up,
however this could lead to some confusing scenarios given the perfidies of
floating point arithmetic (see below) so now the result is rounded to the
nearest whole retrace interval.
If the text "emit" follows the millisecond time then the
retrace rate and the result will be emitted into the output data (so that
remote testing installations that
are trying to do tachistoscopic displays can determine exactly what a given
machine might have done). "emit" will not
work if used in the parameters.
NOTE:- Prior to version 184.108.40.206 of DMDX this was not an F parameter replacement,
it is now.
is provided for one of two situations. Either you don't care about precise
tachistoscopic presentations (for example you are specifying frame durations
that are multiple seconds long) and you don't really want to be bothered
figuring out just how many hundred ticks that's going to be, or you want an item
file to work on multiple machines regardless of their refresh rates.
NOTE:- As mentioned above this keyword was never intended for use with
tachistoscopic displays, however with the introduction of
remote testing and
auto mode it is now being used that way.
prior to version 220.127.116.11 of DMDX on 01/30/13 when
<msfd> added the retrace interval to the
requested millisecond frame duration before then dividing by the retrace
interval in order to always round up asking for exactly the right frame duration
could lead to the duration being one tick longer than desired. For
insurance, asking for a 50 millisecond frame duration on a machine that reports
a 60 Hz display mode (with auto mode ) actually resulted in a 4 tick display (not
the 3 ticks you might expect) whereas asking for a 100 milliseconds yielded a 6
tick display (as one might expect). This is due to the perfidies of
floating point binary arithmetic where the result of the 50 millisecond request
is something like 4.000000001 and the result of the 100 millisecond request is
6.99999999 (which gets truncated to 6 for the integer frame duration). So
it was changed on 01/30/13, now it adds half the retrace interval before
dividing by it producing a result taking the nearest number of retrace intervals.