Incident Player
Usage
If you have all the necessary files in one directory on your hard disk, using ip.exe is as simple as
ip<enter>. For more information on command-line switches etc., see ip.doc. If ip.exe doesn't work, read everything below, as well as ip.doc. If this doesn't help, do send a bug report to the author - there are instructions for doing this in ip.doc.Timing & Memory
MPEG2 animation is the heart of Incident. Decoding and displaying MPEG2 is also the most time-critical part of Incident Player. For timing, Incident Player uses a simulated vertical retrace interrupt. The animation is decoded into a large memory buffer while the interrupt displays frames from the buffer on the screen. This system enables the player to display the animation smoothly even when the mass storage where the data file is located has very high seek times or other variable-length delays. As long as the average transfer rate is high enough, it's ok.
If the player can't decode fast enough, the buffer will get empty as the interrupt displays and discards frames at a constant rate. When this happens, the player will exit and display an error message saying "MPEG decoding too slow" or something like that. In ip.doc it is suggested that in this case you try freeing up some memory. What does free memory has to do with the decoding speed? Well, nothing, but more free memory means larger buffer which will help if the decoding is fast enough on the average, but has long delays. Note that usually freeing memory doesn't help if you had more than 8 Mb free already. While Incident Player can use as much as 32 Mb of memory, it rarely does so.
Some Programming Details
Interrupts
Aside from the real-time clock interrupt 0x08, all interrupts have been left intact. This means that for example Ctrl-C will exit the player but leave the screen as it is to give you that "unfinished program" look. This is not due to the incompetence or the lazyness of the author - the thinking behind this is that no-one presses Ctrl-C by mistake; if the user wants to make this crude exit, let him.
MPEG2
Why MPEG2? Because it is the best video encoding method currently available. As far as Incident is concerned, there is very little difference between MPEG and MPEG2. The most usable source code I could find for both encoding and decoding was MPEG2, so Incident uses MPEG2.
For decoding MPEG2 Incident uses Stefan Eckart's mpeg2play. If you've been playing around with MPEG-software, you know that Eckart's mpeg2play is not the fastest MPEG2 decoder around. But it's pretty good and implements the MPEG2 standard better than anything else I've found.
Why Incident Is Black and White
The resolution of the animation in Incident is 320x120 and it is black and white (grayscale). (The screen is the familiar mode 0x13 320x200 of which an area of 320x120 pixels is used.) This doesn't seem very demanding. So why the minimum requrement of Pentium100? Because the MPEG2 decoding (mpeg2play) is a bit slow and the frame rate in Incident is quite high (23.3 frames/s in Part One). Besides, P100 is actually not a minimum requirement - Incident Player will try to run on any hardware and it may run properly even with a P75. P100 is mentioned as a minimum requirement only because it is a "sure shot" - Incident Player should run nicely on any P100 system.
So why black and white? Even if the MPEG2 decoding would be a lot faster, color would still be impossible. This is because the 256 colors of mode 0x13 just aren't enough. On the other hand video crads that support the glorious 320x240x16bit and 320x240x24bit modes are very rare, so one would have to use the 640x480x16bit mode to get a color picture. Updating a 640x480x16bit screen takes a lot if time. However, even if that could be done, or even if one could use the 320x240x16bit mode, the conversion from YUV color space into RGB would become a bottleneck. (MPEG2 uses YUV color space while video cards use RGB.)
Windows 95 users
Incident Player does not work under Windows 95. There are probably several reasons why. Incident Player attempts to detect Win95. The detection is not foolproof, but usually it works. If Win95 is detected, the player will notify the user and ask whether to quit or to continue. At this point you'll want to quit unless you're certain that you're not under Win95. Under Win95, Incident Player can crash the entire system.
What to do: restart in MS-DOS mode and then run Incident Player.
Windows NT users
The simulated vertical retrace interrupt doesn't work properly under Windows NT. This makes the animation jumpy and slow. Otherwise the player runs fine. Running Incident Player under NT is not recommended.
OS/2 users
I haven't tried it myself, but Incident Player should run under OS/2 with the proper DOS-session settings.
Data files
As a convenience for downloaders, every part of Incident is released as three different size versions. What is different about them is the MPEG2 encoding quality (and sometimes the JPEG quality as well).
Size versions usually have the following charasteristics:
Small
The picture is clearly degraded. All the typical MPEG-errors are visible. Whenever the camera is moving quickly, MPEG blocks become very obvious and many details in the picture disappear. However, it is still easy to tell what the picture represents. In this case picture degradation is not altogerher a bad thing anyway, since it leaves a bit more to your imagination.
Medium
With a fast-moving camera, MPEG blocks can still be seen. Otherwise the picture is surprisingly good. Most of the time you have to know what you're looking for if you want to see MPEG-errors.
Large
The picture is near-perfect. Even with fast-moving camera MPEG-errors are no longer apparent unless you know what to look for.
Last updated 1997