MESS provides a series of options to capture not only static images of the emulated system, but audio and video streams too. This feature actually might not work as it is normally intended - as they say, it's not a bug, it's a feature! - soon we'll explain why… but first of all, here are the commands:

• A snapshot is taken by pressing F12 (provided you are in UI mode and you haven't redefined the snapshot key): a .png file will appear in the directory defined by the -snapshot_directory option. Two further options, -snapname and -snapview control the name of the snapshot and the part of the picture (in MESS jargon, the view) that's actually captured. If the system uses multiple screens, all of them will be captured at once.
• Those who have enabled the debugger might find useful the snap command, which gives more control about the name of the .png file and allows the capture of single screens.

To capture audio and video streams it is not necessary to use the user interface, since the relevant options are provided by the command line.

• To capture the audio output, it is sufficient to provide to MESS a filename using the -wavwrite option. The resultant .wav file will contain all the audio of the MESS session, from the beginning to the end.
• To capture the video, the same mode of action is employed, with the important difference that the user is allowed to choose between two formats: -mngwrite will create an audioless movie in .mng format. Of course, -wavwrite can be used on the same command line to provide an audio track which can be mixed with the video capture.
• Lazy users can use -aviwrite to dump both audio and video to an .avi file at the same time: the price to pay is a greater overhead and consequently a slower and more sluggish emulation.

The audio file will be located in the same directory as the MESS executable while the video file, regardless of its format, will be located in the snapshot directory.

So now you have successfully taken a screenshot of your favourite game running on MESS and going open it in a graphic editor just to discover that the picture is totally different from what MESS had displayed on screen - surely there must be a bug somewhere…

The answer is that there is no bug in the screen dump code - the reason is in the way the image that you see on the screen is actually drawn: to make a long discussion short, MESS has to draw, in the worst case, a certain number of entities on the screen:

1. an artwork, i.e. one or more pictures (divided into bezels, backdrops and overlays) that give a more realistic appearance to the emulated system or enhance its usability. These images depict elements that on a “real” machine are represented by “real” objects, e.g. a sheet of transparent plastic to lay on the TV set, or the keyboard of calculator machine.
2. a screen, the picture generated by the emulated system, i.e. the image which the “real” system would draw on the screen of the TV set.
3. an effect, i.e. a small picture which, tiled and superimposed on the screen, mimics the scanlines pattern that can be observed on old TV sets.
4. the user interface, if activated by the user.

Each one of these elements has different requirements:

• the artwork can extend far beyond the area occupied by the screen, and can also overlap it.
• the screen usually must be squashed to a 4:3 ratio (most systems use rectangular rather than square pixels).
• the effect must overlap the screen, but not the artwork.

In order to meet these requirements MESS draws these pictures separately and subsequently merges them using a renderer: a lengthy and very interesting explanation of its capabilities is provided by its author, the maintainer of MAME, Aaron Giles here, here and finally here.