Capturing video of older, running software can be a bear. A link to the full-size YouTube video and a smaller in-situ version are included directly below. I kept things simple for this first evening just to see what issues I’d encounter.
The video shows a brief slice of a running simulation of a two-line tunnel furnace with shuttles. Two casters are each feeding steel slabs directly into a reheat furnace of about 800 feet in length. The shuttles are used to transfer the slabs to the furnace that is inline with the single rolling mill. The simulation itself was written from scratch (by me) in Borland Pascal version 7, which was the last version to run in DOS. I think that version even had a Windows interface but did not yet produce Windows executables (that would have to wait for Delphi). The program runs at a full-screen resolution of 800×600 pixels. Since I no longer have a machine that will run DOS natively I instead ran the simulation program in DOSBox version 0.74, which adds a few pixels to the height and width for its header and borders. VMWare Fusion, apparently, stopped supporting DOS environments a version or two back, as did Microsoft’s Virtual PC tool, so this still appears to be the best option, though it hasn’t been updated in several years.
The simulation program is controlled by simple keystrokes indicated by the highlighted letters in each of the available commands in the top section of the screen. Commands in blue simply executed an action. The most basic of these were to control the simulation by advancing a single time step, running continuously, freezing, or reinitializing. Since this was a continuous or time-domain simulation the time steps were always the same (three seconds in this case). Commands in purple generally initiated some sort of editing action which took place in an overlay. I had to save the image of the windowed area, perform the desired functions in a pseudo-window, then restore the windowed area. The Edit command itself allowed the user to select and modify any of the values in the variable list, shown in the two columns to the left. The green and red commands are states that can be toggled between on and off. I can’t remember how the yellow and gray items worked. All of the updating elements could be toggled on and off individually (or in groups of similar items like the values in the variable list).
Stopping the updates of more and more of the display elements allowed the rest to run more and more quickly, since the program didn’t pause to run as slow as real time. This feature is especially useful when running the calculations for predicted discharge temperatures and displaying the second 3D furnace display that shows them in addition to the actual temperatures you see in the video.
DOSBox itself intercepts the control-F1 key for its own purposes which makes it annoyingly difficult to set the program to automatically feed the Line 1 furnace. That meant that I had to hit the F1 key myself whenever I wanted to start feeding a new slab into it. That hindrance can be overcome in a later iteration.
Since this was only for internal analysis there was no attempt to make it pretty. Each update is drawn from scratch in its entirely each time step. The flicker occurs because the program didn’t screen flip between alternating buffers. My reading indicated that it was possible to do in that version of that language but I never implemented it.
I did the screen capture with Roxio Creator NXT Pro 3 using the custom area capture tool and I came within a pixel or two of sizing the area just right. The flicker works a bit better when viewing it with the naked eye but the screen capture ended up looking ok. As reporter Dickie Dunn from the movie Slap Shot would have observed, it captures the spirit of the thing.
The result of the original video capture was actually very clean. There is some flicker as described but the resolution is captured perfectly. Too bad that clarity didn’t quite survive the rest of the process. This wouldn’t be an issue for a photograph or as much of one for larger text, but changing the size of video involving these kinds of graphics starts to make things fuzzy real quick.
I’m still getting used to the flow of the screen capture tool itself so I captured several minutes of video and needed to trim it down to the 21-second sample you see here. The problem with most video editing tools is that they generally insist on creating outputs in specific resolutions. This is great when you want to target a specific device but I wanted to work with the video in its native resolution, which turned out to be 804×628. I could get the obvious video editing tools (Roxio and Windows Movie Maker in my case) to create outputs with custom dimensions but they both insisted on importing the video into a 16×9 or 4×3 aspect ratio. The native resolution is close to 4×3 so the import operation added black bars to either side of the video. Had the width been more than about 837 pixels the program might have chosen to add bars to the top and bottom instead.
In the end I could have done a few things to improve the quality of this video:
- Capture the video quickly so I end up with something small that doesn’t have to be trimmed and hence altered by the editing software.
- Find an editor (cheap or free as this isn’t my everyday toolset) that will let me work with video in its native format.
- Spring for an expensive editor for the same reason.
- Capture an area that matches a standard resolution so the editor won’t need to modify it on import or export. I might then have to accept borders of some size, though if I cut off the DOSBox header and borders I might be able to get 800×600 exactly if I was careful. Sims I have in other resolutions (I think I have some in 1024×768) may or may not be a problem. An editor that would let me output a custom-sized subset of that result would probably also allow me to work in native resolution in the first place, though that idea warrants some further research.
- Learn more about the Roxio screen capture tool itself, just in case I’m missing something. Since the tool only captures video in .wmv format I’m probably not missing anything there, but changing the frame rate of the capture might help.
- If I wanted to get real creative I could modify the program to save its own screenshot after every time step update, and the captures could then be stitched back into a movie. Maybe. I once had a video tool that claimed to do the reverse operation but it never actually worked. I would also have to set up a DOS environment to successfully host the development software.
Did I miss anything?
For the time being I’ve also chosen not to add titles, multiple cuts, transition effects, and narration. I also captured the original video with no sound. One thing at a time, right?