MZM

MZMs are self-contained sections of MZX board data. Initially conceived as an improvement upon the ANSI format used to export graphics between boards (before inter-board copying was possible), they have become a convenient way to store and dynamically load game content. The first version of MZM only stored simple object types, ie nothing including external data (robots, scrolls, and sensors), and was limited to 256x256 in size. The second version (MZM2), introduced in MZX 2.80d, increased the maximum size to 65536x65536 and allowed for robots to be stored in the "board" format. It is now possible to use MZMs to completely compartmentalize a game into a series of externally loaded boards, effectively bypassing set limits within MZX.

MZM Tutorial

MZMs are relatively easy and painless to use, both in the editor and during gameplay. The biggest hurdles are learning the Robotic commands to access them, and understanding the difference between the two MZM types. Neither of these is particularly complicated. First, we'll talk about the two types of MZM, board and layer.

Board MZMs store things exactly as they are on the board, including appearance and object type, and floor beneath solid objects. In particular, board MZMs can store robots (and even execution state if created during a game). This makes them particularly well suited for storing game levels, or blocks of robots that manage specific engines, or for copying pieces of boards between games without having to export the whole board. However, due to the nature of how object parameter is interpreted by the overlay (it is read as the character code), they are generally not suitable for import to the overlay or vlayer. In the editor, any MZM exported from the board will be a board MZM. To ensure an overlay safe board MZM, you should export only artwork drawn with customblocks or customfloors. Or preferably, you should use a layer MZM instead. Board MZMs do not support saving scrolls, sensors, or the player. Instead, a customblock with the same appearance will be saved.

Layer MZMs store things exactly as they APPEAR on the board, or the layer they are saved from. They are ideal for saving artwork for sprites or interfaces without a physical component in the game. Because they only store color and character information, they are also at least three times smaller than board MZMs. They are not particularly well-suited for importing directly onto the board however, especially during the game. Importing this way in the editor provides the option of selecting customblock or customfloor (or Text) as the object type for each tile, just as if you were copying from the overlay; importing a layer MZM to the board during the game invariably creates customblocks. In the editor, any MZM exported from the overlay will be a layer MZM. Copy board sections to the overlay as an intermediate step.

To save and load MZMs during the game with Robotic, the copy (overlay) block and put commands have been co-opted with special syntax. To load an MZM, use the syntax

put "@filename.mzm" Image_file pNN at X Y

where the filename replaces the color (the '@' is a required syntactic prefix for Robotic and is not part of the filename), the parameter specifies the target layer (p00 for board, p01 for overlay, p02 for vlayer), and X and Y are the target location for the upper left corner of the MZM. MZMs placed so that they would extend beyond the boundaries of the board or vlayer are simply not loaded, so pay attention. Likewise, use

copy (overlay) block X Y W H "@filename.mzm" N

to save an MZM to a file. X, Y, W, and H are standard coordinates and dimensions (use '#' prefixing with X and Y to save from the vlayer, as explained in the vlayer tutorial), the filename uses the same prefix as loading, and N is the MZM type (0 for board, 1 for layer). It is generally recommended to save MZMs from the board using board type, and from the overlay and vlayer as layer type.

(Maybe put an example here, but of what?)