Above-Real-Time Training and the Hyper-Time Algorithm
Altering time in human-computer interfaces
Dutch Guckenberger, Liz Guckenberger, Frank Luongo, Kay Stanney, Jose Sepulveda
Dutch is the senior software engineer for ECC International and teaches graduate simulation courses at the University of Central Florida. Liz is a research associate with UCF, while Kay and Jose are associate professors in UCF's Industrial Engineering Department. Frank is a software engineer at ECC. They can be contacted at [email protected].
Historically, the rate of information presentation for a computer application is chosen and hard coded by the original software developer. The programmer tries to select a rate that is not too fast for the novice, nor too slow for the expert, and rarely allows variability in the rate of presentation. The net effect of this "developer selection" is that no group is completely happy, and we are forced to adapt to the machine. The hyper-time algorithm (HTA) empowers the user to dynamically control the rate of information presentation. HTA is a modular addition to existing applications.
HTA makes it possible for you to alter the flow of "simulated time" to benefit the user of a computer or simulator. Slower than real time can be used for novice users or to emphasize a particular section of interest. Faster than real time can be used for experts or persons "time surfing" (analogous to TV-channel surfing) over uninteresting portions of information. NASA and U.S.-military research has utilized HTA to demonstrate that "Above Real Time Training" (ARTT) improves human performance, increases retention, increases training-device effectiveness, and decreases stress. On the flip side, slowing down the rate of information presentation also has benefits, particularly when it comes to debugging, emphasizing important points, and helping disadvantaged learners.
Over the years, we've converted seventeen different simulators and six different computer applications so that they can perform above/below-real-time operations using the hyper-time algorithm. More recently we've developed a control for varying the video rate of MPEG video presentations, and we're currently working with Sigma Design to synchronize faster-than-real-time audio. Once we have combined faster-than-real-time video and audio, HTA-MPEG will make it possible for you to watch a two-hour movie in 80 minutes, while having a more intense involvement and better memory recall.
Interestingly, advertisers have been aware of the nonobvious benefits of above real time for many years. When time-compressed speech is used in radio advertisements, people like the commercials better and remember them better (MacLachlan and LaBarbera, 1978). The TV-advertising industry notes similar results using time-compressed commercials (MacLachlan and LaBarbera, 1979; MacLachlan and Seigel, 1980; and Riter, Balducci, and McCollum, 1982). For instance, do you remember the FedEx commercials with a fast-talking actor? Have you ever noticed how fast the motion is in MTV videos, or watched the fast motion of the old silent movies? What you probably didn't notice was that your comprehension did not suffer. Humans are able to quickly adapt to different rates of information presentation. It's unfortunate that the advertising community is using our above-real-time adaptability to put slogans and trivia into our brains, while educational TV programs and computer-based training have yet to capitalize on these techniques. Shouldn't we be using this technique to better educate our children? ARTT could be used to make education more enjoyable, while helping students retain more information. (We're currently developing above-real-time MPEG playback for education and training purposes. Educators interested in testing or applying the technique can contact us for more information.)
A less-obvious benefit is that HTA supports a new method of training in simulators. ARTT, the focus of our research for the last six years, is a multidisciplinary research program with theoretical support garnered from neuroscience, cognitive psychology, human-computer interaction, and learning theories, as well as applied research. ARTT research has received three national awards--National Security Industrial Association, best paper 1992; NAVAIR 4th Airborne Weapons Conference 1993, best technical paper; and Link Foundation Advanced Simulation and Training Fellowship 1993--94 (Guckenberger, et al., 1992, 1993, 1994). ARTT research has been supported by NASA's Dryden Flight Research Center (DFRC), ECC International, the University of Central Florida, the U.S. Navy, the Link foundation, and the U.S. Army. Currently pending is support from the U.S. Air Force, a commercial airline company, the Chicago Cubs, and the Cleveland Indians (for ARTT batting practice). We mention this simply to illustrate that HTA and its application in ARTT have widespread applicability. For the purposes of this article, we'll emphasize applications and try to restrict theoretical considerations. If you're interested in the intrinsic time adaptability of humans, a good place to start is Chapters 1 and 2 of Human-Computer Interaction, by Card, Moran, and Newell (Lawrence Erlbaum Associates, 1983). The variable cognitive processor-rate principle and the variable perceptual processor-rate principle of the human-information processor model are starting points for understanding ARTT phenomena.
Above-Real-Time Background
Simulators utilizing ARTT allow you to "over-train" in the time dimension. In simplest terms, ARTT pseudostresses individuals in safe, simulator environments, preparing them for additional real-world stresses not present in the simulation. Research has shown enormous benefits in performance and retention of ARTT-trained tasks; tank gunnery has shown 50 percent higher performance, and the accuracy of F-16 pilots improved 28 percent in performing emergency procedures under stress. The ARTT pilots not only performed the emergency procedure with near-100 percent accuracy, they followed by removing the stress (in this experiment, the stress was enemy MIGs). The ARTT pilots killed six times as many MIGs as the control real-time pilots (Guckenberger et al., 1992, 1993).
ARTT refers to a training paradigm that places the operator in a simulated environment that functions at faster than normal time. In the case of air-combat maneuvering, a successful tactical air intercept which might normally take five minutes is compressed into two or three minutes. All operations of the intercept would correspondingly be accelerated--airspeed, turn and bank velocities, weapons flyout, and performance of the adversary. In the presence of these time constraints, the pilot would be required to perform the same mission tasks to the same performance criteria as he would in a real-time environment. Such a training paradigm represents a departure from the intuitive, but not often supported, feeling that the best practice is determined by the training environment with the highest fidelity. ARTT can be implemented economically on existing simulators. It is important to realize that ARTT applications require the simulated time to change, not the update rate. Over 20 years ago, flight-test engineers recognized that if you could program a simulator to operate in "fast time," you could give test pilots a more accurate experience or "feel" of real-world stresses that would be present in the aircraft (Kolf, 1973; Hoey, 1976).
The bulk of the original support for ARTT in simulators came from NASA reports. During the X-15 program in the late 1960s, researchers at NASA's DFRC needed a mechanism to address the X-15 test pilots' post-flight comments of being "always behind the airplane_" and "_could never catch up" (Kolf, 1973). Clearly, there were some differences between the perceived time in the well-practiced simulator flights and that in the experimental aircraft. The first time NASA used fast-time simulation was toward the end of the X-15 program. Pilots compared practice runs at various time constants with flights they had already flown. A fast-time constant of 1.5x felt closest to their flight experience and was successfully implemented in the lifting-body programs, but lack of funding prevented the program from fully developing the capability. Nevertheless, NASA's test pilots at DFRC have endorsed the use of fast-time simulation as part of the training process. It is important to note that DFRC's Jack Kolf is the father of ARTT in simulators. He recognized the problem, fostered a successful solution, and implemented ARTT for NASA test pilots.
Vidulich, Yeh, and Schneider (1983) examined time compression as an aid in training a basic, high-performance air-traffic-control skill. One group practiced an intercept with a target plane traveling at 260 knots. The second group practiced the intercept at 5200 knots--20 times real time! Both groups were then tested in real time. The time-compressed group performed certain aspects of the skill significantly better; in other areas, their performance was the same as the real-time group.
ARTT benefits have been extended to virtual-reality environments, where college students were able to perform 40 percent faster and with less workload and stress than conventionally trained, control VR subjects (Guckenberger, Stanney, Mapes, 1993).
The concept of time surfing may be useful for observing information hitherto obscured by the low-repetition rates. For example, it may be possible to identify enemy traffic routes, supply areas, headquarters, and communication centers by fast-time playback of information from a God's-eye view of the battlefield. The traffic patterns and key crossroads would be easily distinguished. The fast-time playback would blur the positions of individual vehicles into a moving line, which would not only give direction, but also the traffic load, as revealed by the intensity of the line. A good analogy is the fast-time playback of cloud movements during the weather report you see every night on TV. Time-lapse radar images also show the internal-structure elements as the weather patterns move.
The key point is that the rate of information presentation varies for the benefit of the user. The control of this rate can be assigned to the user, the instructor, or intelligent-tutor software that matches the rate of information presentation to a user's current performance level. The simplest case for an intelligent tutor is a lookup table that selects a rate of information presentation as indexed by current-performance score.
Manipulating Time
To manipulate time, you must adopt an entirely new way of thinking about it. Once you understand HTA, you'll see that update rate and hardware requirements are unaffected--you're merely altering "simulated time."
For example, consider the case of a real-time vehicle simulator. Somewhere deep in the heart of the software is an assigned value (usually hardcoded) for the hardware clock-tick value, TICK_VALUE. The physics model calculates the next frame's x,y,z location from the present x,y,z, plus the Velocity_Vectors, multiplied by the TICK_VALUE. By dynamically assigning different values to TICK_VALUE, you can alter the flow of simulated time without effecting the hardware-update rate, without changing the physics model, and without changing the I/O rates; that is, you change only the time-frame integration value. (The HTA implementation for controlling video-disc and CD-ROM interfaces are a little more complex, although not unduly so.)
The HTA implementation should not affect normal real-time use of the computer application or simulation. If the HTA is implemented as a command-line parameter, then it's an initialization issue. If it's implemented as a dynamic variable, then the cost to the real-time process is one extra comparison per loop.
The real work is done in the alter_ time_rate() function (see Example 1), which is platform dependent. If the platform utilizes a video disc or similar per-frame encoded device, alter_time_rate() modifies the presentation of the frames in faster than real time by skipping frames and in slower than real time by increasing the display time of some frames. If the platform does its own computer-generated imagery, alter_time_rate() has only to alter the TICK_VALUE variable as described earlier. If the application is a word processor that goes as fast as the calculations can be made, a timer module is added to allow alter_time_rate() to control the rate of information presentation. If the platform is an MPEG playback board like Sigma Design's ReelMagic Board, the application interface can be used to allow alter_ time_rate() to control the rate of video information presentation. If the simulation is to run at the same rate of information presentation for the entire simulated mission, the ARTT rate can be done as a simple initialization function; see Listing One. Listing Two is source code to change Sigma Design's ReelMagic MPEG playback board to run video at above (and below) real time. (In the future, we'll examine ways to add audio to HTA-MPEG, covering RAPID-COMmunication, a patented method developed by the U.S. Air Force that has demonstrated higher throughput and improved retention of computer-displayed information.)
Implementing ARTT
To illustrate how you can implement HTA, we'll examine the VideoDisc Interactive Gunnery Simulator (VIGS) built by ECC International for the U.S. Army. We chose this particular simulator as an example to emphasize that the computation requirements are not effected by implementing ARTT.
The VIGS unit--an 8086-based PC running under MS-DOS with ECC-proprietary video, sound, and I/O boards--was designed to teach basic gunnery skills. The trainer uses realistic battlefield scenarios created using an image generator and recorded onto a video laser disc. Scene and target information for each frame of every battlefield scenario are garnered from the image generator, and stored on disk. The video-playback system uses a Hitachi laser-disc player which offers several different playback modes, including normal playback (30 fps), 2x playback (60 fps), and a step function which allows the video disc to be stepped through one frame at a time. The video player is controlled via an RS-232 port.
The ARTT experiment required some changes to the instructor interface of the system. Upon the initialization of each lesson, the instructor was presented with an option screen like Figure 1 to select the operating mode of the machine. The instructor used a numeric keypad to select a menu option. If the ARTT mode was selected, a screen similar to Figure 2 appeared, letting the instructor set up the experiment parameters. The first five selections in Figure 2 are self explanatory. The random-mode selection presented the subject with random-ARTT variables, while the sequential-mode selection presented the subject with increasing ARTT variables.
During the real-time-operation mode, the video player was placed at the normal-playback rate (30 fps), and the loop times for ballistic calculations, target tracking, and scene movement were synchronized to 30 Hz. This was done by writing an interrupt handler which was triggered by a 60-Hz interrupt signal generated by the video board. All target, scene, and some ballistic information was stored in tables indexed by frame numbers (remaining ballistic information was based on gun elevation and target range). These frame numbers were synchronized to reflect the relative frame number of the video-disc scene being displayed. Target hits or misses were determined by accessing these tables and performing dynamic equations.
The ARTT implementation of this trainer was greatly simplified by realizing the value of keeping ballistic calculations based in "real time" while causing target and scene movement to accelerate. Manipulating the target and scene time constant was a simple task: The video-disc playback rate and updates of the frame-number variable were simply manipulated during the 60-Hz update rate. Using 30 fps as the normal-playback rate, the different update rates were calculated using the equations in Example 2. Example 2(a), for instance, determines the amount of time the ARTT-adjusted scenario will run, while Example 2(b) determines the necessary frame variable and video-player update rate by dividing the total number of available frames by the ARTT scenario time.
By using the ratio of ARTT-update rate to 60 Hz, we developed an algorithm to synchronize the video-playback rate with the frame-number variable used to index the information arrays. Example 2(c) shows the calculations used for the 1.33x ARTT constant. Assuming a 60-second, real-time scenario, the 1.33 ARTT-adjusted scenario runs approximately 45 seconds.
A 60-second scenario contains 1800 frames of information, resulting in Example 2(d). Substituting Hz for fps, we obtain the ratio 40 Hz (required ARTT update rate)/60 Hz (video interrupt), or 2/3. To implement this ratio, the video player was placed in step mode and issued a step command "2" out of every three 60-Hz interrupt loops. The frame variable was incremented every time the video player was stepped. Similar calculations were used on the 1.6X and 0.5X ARTT constants, yielding ratios of 4/5 and 1/4, respectively. Figure 3 shows an associated flow diagram while Example 3 presents pseudocode. Listing One is the video-player driver.
Although the sample code presented here was specific to the VIGS and the video-disc player, adapting it to similar applications using video disc or CD-ROM formats should be straightforward.
Conclusion
ARTT research has demonstrated that humans are time adaptable, and therefore capable of sustained performance and learning at much higher levels than conventionally accepted. In this context, real time--as treated by typical approaches to software design and human-computer interaction--is an artificial barrier, a self-imposed limit, and an incomplete paradigm.
Note that a thorough theoretical treatment of ARTT is scheduled for publication by Rochester Press later this year on behalf of the Link Foundation Fellowship in Advanced Simulation and Training. If interested, you can obtain a draft copy and additional information by contacting us.
References
Card, S.K., T.P. Moran, and A. Newell. The Psychology of Human-Computer Interaction. Hillsdale, NJ: Lawrence Erlbaum Assoc., 1983.
Guckenberger, D., K.C. Uliano, and N.E. Lane. The Application of Above Real-Time Training for Simulators: Acquiring High-Performance Skills. Presented at the 14th Interservice/Industry Training Systems and Education Conference. San Antonio, TX, 1992.
------. Training High-Performance Skills Using Above Real-Time Training. NASA Technical Report Contract NAG-2-750. 1993.
Guckenberger, D., K. Stanney, and D. Mapes. Virtual Time: Adding the Fourth Dimension to Virtual Reality. Presented at the 15th Interservice/Industry Training Systems and Education Conference, Orlando, FL, 1993.
Guckenberger, D., K. Stanney, and N.E. Lane. The Effects of Above Real-Time Training (ARTT) in an F-16 Simulator, 1993.
Hoey, R.G. "Time Compression as a Means for Improving the Value of Training Simulators." Unpublished manuscript, 1976.
Kolf, J. "Documentation of a Simulator Study of an Altered Time Base." Unpublished manuscript, 1973.
MacLachlan, J. and P. LaBarbera. "Time-Compressed Speech in Television Commercials." Journal of Advertising Research (August 1978).
------. "Time-Compressed Speech in Radio Advertising," Journal of Marketing (January 1979).
MacLachlan, J. and M.H. Siegal. "Reducing the Costs of TV Commercials by Use of Time Compressions." Journal of Marketing Research (February 1980).
Matin, E., K.R. Boff, and R. Donovan. "Raising Control/Display Efficiency with Rapid Communication Display Technology." Proceedings of the Human Factors Society 31st Meeting, 1987.
Matin, E. and K.R. Boff. "Information Transfer Rate with Serial and Simultaneous Visual Display Formats." Human Factors, 1988.
------. "Human Machine Interaction with Serial Visual Displays." Proceedings of the Society for Information Displays (SID). Las Vegas, NV, May 1990.
Riter, C.B., P.J. Balducci, and D. McCollum. "Time Compressions: New Evidence." Journal of Advertising Research, 1982.
Schneider, W. "Training High-Performance Skills: Fallacies and Guidelines." Human Factors, 1985.
Thompson, M. "General Review of Piloting Problems Encountered During Simulation Flights of the X-15." Presented at the 9th Annual Meeting of the Society of Experimental Tests Pilots, 1965.
Vidulich, M., Y.Y. Yeh, and W. Schneider. "Time-Compressed Components for Air-Intercept Control Skills." Proceedings of the 27th Meeting of the Human Factors Society, 1983.
Example 1: Initialization and HTA.
initialization() {
...
/* initialize ARTT variables */
current_artt_rate = 1.0;
old_artt_rate = 1.0;
}
main_loop() { ...
/* get the artt-rate if input from user, otherwise lookup list */
....
/* if artt_rate is different from last pass change rate */
if (current_artt_rate != old_artt_rate ) {
alter_time_rate(current_artt_rate);
old_artt_rate = current_artt_rate;
}
....
}
Figure 1: Sample VIGS operator screen.
M1 GUNNERY TRAINER ECC INTERNATIONAL Select Mode of OperationL 0: Normal 1: ARTT 2: DEMONSTRATION
Figure 2: Sample VIGS ARTT menu screen.
ARTT MENU SCREEN Time Mode For Trails: Mode Legend: 1: REAL TIME 2: 2X #: 1.3X 4: 1.6X 5. 0.5X 6. RANDOMSELECT 7: SEQUENTIALSELECT Your Choice?
Example 3: Pseudocode for typical ARTT-based application-flow diagram.
HTA skipped frame pseudocode */
Initialization of HTA_Skip */
HTA_Skip_mode =1
/* User Input */
User Select mode 1=1.0, 2 =2.0, 3=1.33, 4=1.6, 5=0.5, 6=3.0
/* Error Check User Input */
If (error_check(mode) == TRUE) then
{symbol 183 \f "Symbol" \s 10 \h} Report error
{symbol 183 \f "Symbol" \s 10 \h} Re-prompt for input
{symbol 183 \f "Symbol" \s 10 \h} Offer quit option
Case mode
1: play 1.0x @ 30 fps (skip every other 60-Hz pass)
2: play 2.0x @ 60 fps, increment
3: play 1.33x @ step every 2 out of 3 60-Hz passes
4: play 1.6x @ step every 4 out of 5 60-Hz passes
5: play 0.5x @ step once every 4 60-Hz passes
6: play 3.0x @ step 3 times every 2 60-Hz passes
/*for Videodisc updates */
Example 2: Calculating ARTT-based application-update rates.
(a)
60seconds/ARTTConstant=
ARTTScenarioTime
(b)
TotalAvailableFrames/ARTTScenarioTime
(c)
60Seconds/1.33=45Seconds
(d)
1800frames/45seconds=40fps
Figure 3 Typical ARTT-based application-flow diagram.
Listing One
{ /*
*****************************************************************
** ECC INTERNATIONAL CORPORATION
*****************************************************************
** %BEGIN_HEADER
** %NAME: play.c
** %PURPOSE: Above Real-Time Modified Version of VIGS
** %DEPENDENCIES:
** -----
** DEVELOPMENT ENVIRONMENT
** COMPILER: Pascal
** OPERATING SYSTEM: DOS
** COMPUTER: PC
** COMPILATION INSTRUCTIONS: uses Borland MAKE. Type 'make'
** TARGET ENVIRONMENT
** CPU: 8086
** HARDWARE NAME: VIGS
** OPERATING SYSTEM: n/a
** MACHINE DEPENDENCIES: n/a
** %CHANGE HISTORY:
** REV: 3.0 DATE: 08-07-91 PROGRAMMER: Frank Luongo
** DESCRIPTION: Added Above Real-Time Modifications per Hyper-Time Algorithm
** %END_HEADER
*****************************************************************
*/
}
.....
Procedure Play;
{code for Hitachi laserdisc driver}
const
PLAY_1 = 37;
PLAY_2 = 102;
STEP = 36;
begin
Case mode_number of
1{1X} :
{ a 30Hz flag is set in the interrupt handler}
if v30flg then begin
if frame_cnt = 1 then begin
{wait for Tx ready}
while ((inport($3fd) and $20) <> $20 ) do
{since loop time of program is considerably less than 30 ms
we use the play command for 1X instead of the step command.}
outport($3f8,PLAY_1);
{only send play command once so not to reset frame_cnt}
frame_cnt := frame_cnt + 1;
end;
{increment frame number variable to sync with videodisc player}
frame_num := frame_num + 1;
end;
2:{2X}
begin
if frame_cnt = 1 then begin
{wait for Tx ready}
while ((inport($3fd) and $20) <> $20 ) do
{since loop time of program is less than 16 ms we use play
command for 2X instead of the step command.}
outport($3f8,PLAY_2);
{we only send the play command once so we do not need to reset
frame_cnt}
frame_cnt := frame_cnt + 1;
end;
{increment the frame number variable every 60 Hz to maintain sync
with the videodisc player}
frame_num := frame_num + 1;
end;
3:{1.33X}
begin
{keep track of the number of 60Hz passes}
frame_cnt := frame_cnt + 1;
{issue step command and inc frame_num every 2 out of 3 60 Hz passes}
if frame_cnt < 4 then begin
{wait for Tx ready}
while ((inport($3fd) and $20) <> $20 ) do;
{send the step command out the serial port}
outport($3f8,STEP);
{increment the frame variable to maintain sync}
frame_num := frame_num + 1;
end else
{reset frame count}
frame_cnt := 1;
end;
end;
4:{1.6X}
begin
{keep track of the number of 60Hz passes}
frame_cnt := frame_cnt + 1;
{issue step command and inc frame_num every 4 out of 5 60 Hz passes}
if frame_cnt < 6 then begin
{wait for Tx ready}
while ((inport($3fd) and $20) <> $20 ) do;
{send the step command out the serial port}
outport($3f8,STEP);
{increment the frame variable to maintain sync}
frame_num := frame_num + 1;
end else
{reset frame count}
frame_cnt := 1;
end;
end;
5:{0.5X}
begin
{keep track of the number of 60Hz passes}
frame_cnt := frame_cnt + 1;
{issue step command and inc frame_num every 1 out of 4 60 Hz passes}
if frame_cnt > 3 then begin
{wait for Tx ready}
while ((inport($3fd) and $20) <> $20 ) do;
{send the step command out the serial port}
outport($3f8,STEP);
{increment the frame variable to maintain sync}
frame_num := frame_num + 1;
end else
{reset frame count}
frame_cnt := 1;
end;
end;
end;{case}
end;
Listing Two
//*****************************************************************
// ECC INTERNATIONAL CORPORATION
//*****************************************************************
// %BEGIN_HEADER
// %NAME: artt_dos.c
// %PURPOSE: Above Real Time Video Demonstration:
// Demonstration of Above Real-Time MPEG Playback on Sigma Design's
// ReelMagic Board. Modified Sigma Design example code for demonostration.
// Note: If compliling with compilers that do not use Borland's BGI (like
Visual C++), be sure to comment out the indicated lines
// This example demonstrates how to get the position in the appropriate
// time format and how to vary the playback speed buffers.
// At the dos prompt, type "artt_dos <MPEG FileToPlay>"
// Use up and down keys to change the speed, escape to exit
// Note : link it with FMPFCTS.OBJ. Use bat file Dutch.bat to load fmpdrv
// and play nfl file and unload driver
// %DEPENDENCIES:
// Important: Ensure fmpdrv.exe TSR is running prior to executing program.
// FMPFCTS.OBJ
// <stdio.h>
// <stdlib.h>
// <conio.h>
// <bios.h>
// "types.h"
// "fmpdrv.h"
// "fmpmacs.h"
// "fmpfcts.h"
// DEVELOPMENT ENVIRONMENT
// COMPILER: Turbo C or Visual C++
// OPERATING SYSTEM: DOS
// COMPUTER: PC
// COMPILATION INSTRUCTIONS: uses Borland MAKE. Type 'make'
// TARGET ENVIRONMENT
// CPU: 486
// HARDWARE NAME: PC with MPEG Playback
// OPERATING SYSTEM: n/a
// MACHINE DEPENDENCIES: n/a
// %CHANGE HISTORY:
// REV: 1.0 DATE: 06-07-94 Software Engineer: Dutch Guckenberger
// DESCRIPTION: Header installation splayer.c modifications
// DATE: 07-03-94 Software Engineer: Dutch Guckenberger
// DESCRIPTION: Modified Sigma Design's Example code provided by Dennis
// Gutridge to compile and run on MicroSoft's Visual C++. Key
// was turning off audio prior to ARTT replay.
// %END_HEADER
//
// ***************************************************************************/
#include <stdio.h>
#include <stdlib.h>
#include <conio.h>
#include <bios.h>
#include "types.h"
#include "fmpdrv.h"
#include "fmpmacs.h"
#include "fmpfcts.h"
#define KEY_UP -72
#define KEY_DOWN -80
#define KEY_ESC 27
#define SPEED_DIV 50
#define SPEED_MIN 1
#define SPEED_MAX 200
#define SPEED_STEP 1
// Error function - Writes Msg and stop the program
void Error(char *Msg,int ExitCode)
{
fprintf(stderr,Msg);
exit(ExitCode);
}
void main(int argc,char *argv[])
{
BYTE hStream;
BOOL Done=FALSE;
BOOL NewSpeed=TRUE;
int Speed=SPEED_DIV;
int ch;
DWORD d;
if (argc<2)
Error("Specify a file to play.\n",1);
// Locate the driver
if (!FindDriver())
Error("Driver not found.\n",2);
// Re-init the driver
FMPInit();
// Open the file
hStream=FMPOpen(FMPF_FILE,(DWORD)(LPSTR)argv[1]);
// if hStream is null, the file has not been properly opened
if (!hStream)
{
Error("Error while opening the file.\n",3);
}
// has the file been recognized ?
if (FMPGet(hStream,FMPI_STM_TYPE)==FMPF_UNKNOWN)
{
FMPClose(hStream);
Error("The file format is unknown.\n",4);
}
// set the destination window
FMPSet(hStream,FMPI_VID_DEST_SIZE,MAKEDWORD(352,240));
FMPSet(hStream,FMPI_VID_DEST_POS ,MAKEDWORD((704-352)/2,(400-240)/2));
// set the time format to frames
FMPSet(hStream,FMPI_STM_TIME_FMT,FMPF_FRAMES);
// if it's a system stream, let's unselect the audio channels
// because speed variation will not work properly with audio .
if (FMPGet(hStream,FMPI_STM_TYPE)==FMPF_GROUP)
{
int i;
BYTE aStream;
BYTE n=FMPGet(hStream,FMPI_GRP_NB);
for (i=1;i<=n;i++)
{
aStream=FMPCommand(FMP_GROUP,hStream,FMPF_GET|FMPF_INDEX,i);
if (FMPGet(aStream,FMPI_STM_TYPE)==FMPF_AUDIO)
FMPCommand(FMP_GROUP,hStream,FMPF_UNSELECT,aStream);
}
}
// Following line commented out for Visual C++ Version
// clrscr();
printf("Use up and down arrows to change the speed. Escape to quit\n");
printf("Frame :\nTime :\nSpeed Ratio :");
// Play the file
FMPPlay(hStream,FMPF_END_REPEAT,0);
while (!Done)
{
// Following line commented out for Visual C++ Version
// gotoxy(13,2);
FMPSet(hStream,FMPI_STM_TIME_FMT,FMPF_FRAMES);
d=FMPGet(hStream,FMPI_STM_POSITION);
if (d!=(DWORD)-1)
printf("%7lu",d);
// Following line commented out for Visual C++ Version
// gotoxy(9,3);
FMPSet(hStream,FMPI_STM_TIME_FMT,FMPF_HMSF);
d=FMPGet(hStream,FMPI_STM_POSITION);
if (d!=(DWORD)-1)
printf("%02d:%02d:%02d %02d",HIBYTE(HIWORD(d)),
LOBYTE(HIWORD(d)), HIBYTE(LOWORD(d)),LOBYTE(LOWORD(d)));
// Following line altered for Visual C++ Version
if (kbhit())
{
ch=getch();
if (!ch) ch=-getch();
switch (ch)
{
case KEY_UP : Speed+=SPEED_STEP;NewSpeed=TRUE;break;
case KEY_DOWN : Speed-=SPEED_STEP;NewSpeed=TRUE;break;
case KEY_ESC : Done=TRUE;break;
}
}
if (NewSpeed)
{
Speed=max(SPEED_MIN,min(SPEED_MAX,Speed));
FMPSet(hStream,FMPI_STM_SPEED,MAKEDWORD(Speed,SPEED_DIV));
// Following line commented out for Visual C++ Version
// gotoxy(15,4);
printf("%.2f\n",Speed/(float)SPEED_DIV);
NewSpeed=FALSE;
}
}
// close the stream
FMPClose(hStream);
}
Copyright © 1995, Dr. Dobb's Journal
