ST-CS-10-339-75
March 2002
5. Demos and Movies (U)
Half-life offers functionality to record gameplay. Two forms of recording are supported; demos and movies.
To produce an AVI file, either form of recording will do, but a movie is much less work since it can be very easily converted into an AVI, whereas a demo must first be converted into a movie, which is time consuming.
A demo is literally a recording of the data streams going into and out of the client as the game plays. As such, the file size is very small - about 4 kilobytes per second. Demo files are played back by Half-life using the playdemo command.
A movie is where Half-life stores a BMP file for every frame it generates - an actual screenshot per frame. Since there are normally at least two dozen frames per second and the frames are completely uncompressed, this is a vast amount of data; even at 400 by 300 at 25 frames per second, Half-life generates seven megabytes of data per second.
(Note all the applications and utilities mentioned in this page are available from Appendix 1, page 2, "Applications".)
The main issue with demos is that recording must start the instant a server is joined. If the demo is started even a short time after joining a server, the demo will not be useable.
This is because when the Half-life client joins a server, it generates or recieves some crucial data (of an unknown sort - apparently related to precaching files and other resources). If this data is not recorded by the demo, when Half-life attempts to play the demo back, it simply cannot - it's a bit like trying to decode a JPEG file without the header.
The other weakness of a demo is that all Half-life is doing is reading the stored in and out data streams and doing as they say to do; it has access to no other sources of information about what occured in the game.
So, for example, when beginning to play a demo, Half-life does not know what team each player is on, since this is not specified in the data streams and is not stored anywhere. As such it must randomly choose a player skin for each player, and so shows Counter-Terrorists with Terrorist skins, for example.
Similiarly, it is often the case Half-life does not know how much ammunition is held, or how much armour the player has.
However, these problems gradually sort themselves out over time, since when something happens in the game which causes a missing piece of information to be sent in the data stream to the client (e.g. a player dies, which then shows which team he is on) the demo from then on "gets it right", for that particular fact.
The upshot of this is that a demo needs to run for a round or two before the playback fully and accurately shows things as they should be.
The main issue with movies is that they require a very high performance disk subsystem.
This is because, when recording a movie, Half-life buffers one seconds worth of frames and then attempts to write them all out to disk - but if it cannot do this before the next frame has to be drawn on screen, the game will stutter because while the data is being written to disk, Half-life does not update the display. If the game stutters, the movie recorded also stutters and of course it is also impossible to play a game of Counter-Strike which pauses for one frame per second.
At 400 by 300 at 25fps, the hard disk needs to write out seven megabytes of data in 0.05 seconds, or the next frame will arrive and the game will stutter. This implies a disk capable of writing 140 megabytes/second. This is basically impossible at the current time and the solution is to use a software disk write cache which will temporarily store the seven megabytes of data in RAM and write them out to disk over the following second (during which no disk activity is occuring since the frames are being buffered in RAM by Half-life).
Note that FAT32 appears better than NTFS for this kind of work since NTFS requires more disk head moves than FAT32 to record a given set of data, and disk head moves are the critial bottleneck for highly demanding disk operations.
Supercache 2000 is recommended for disk caching, although it is Windows 2000/XP only. The author knows of no disk caching software for Windows 9x/ME.
The output from recording a movie is a single file; it is in fact a contigious array of BMP images, one per frame. A utility called mkmovie is used to obtain the individual BMP files, and various applications (VideoMach is recommened) can convert these images into an AVI.
The huge advantage of a movie is that it is directly recording the AVI (albeit in BMP format) as the game is played, and recording can be switched on and off at any time, and of course all the skins/ammo/etc are correct, since all that is effectively being done is a screenshot being made every frame.
It is essential also that the disk being recorded to is fully defragemented prior to recording - if this is not done, the unnecesary disk head moves induced by file fragmentation will prevent data being written in a timely manner and stutter will occur.
Prior to attempting a movie capture, it is important to perform a dry run, or to play the game for a round or two.
This will allow Half-life to load any disk files it needs (blood splash sprites, sound files, etc). If Half-life is forced to try to load these files while a movie is being recorded, stutter will occur and frames will be lost.
Note that Half-life does not understand paths and cannot use shortcuts; you can only write the file into the Half-life directory. If you have a fast hard disk and wish to use that disk, you will need to have your installation of Half-life on that drive.
To convert a demo to a movie, play the demo back as normal and while playback is occuring, execute the startmovie command.
| prev page | - ix - | next page |