MZM - Revision history

Exophase at 19:44, 14 January 2008

2008-01-14T19:44:21Z

← Older revision		Revision as of 19:44, 14 January 2008
Line 1:		Line 1:
	'''MZMs''' are self-contained sections of [[MegaZeux\|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 ~~MZMs simply~~ stored ~~graphical~~ data~~, while successive versions allowed for the storing of board parameters~~ (~~such as whether an object was a customblock~~, ~~a gem~~, ~~a unit of ammo~~, ~~etc~~.) and ~~eventually~~ stored ~~robot code as well~~. 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.		'''MZMs''' are self-contained sections of [[MegaZeux\|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==		==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.		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 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.		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.

Terryn: Reverted edits by Sharpnova (Talk); changed back to last version by Wervyn

2008-01-11T13:53:38Z

Reverted edits by Sharpnova (Talk); changed back to last version by Wervyn

New page

'''MZMs''' are self-contained sections of [[MegaZeux|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 MZMs simply stored graphical data, while successive versions allowed for the storing of board parameters (such as whether an object was a customblock, a gem, a unit of ammo, etc.) and eventually stored robot code as well. 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.

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 <tt>copy (overlay) block</tt> and <tt>put</tt> commands have been co-opted with special syntax. To load an MZM, use the syntax <pre>put "@filename.mzm" Image_file pNN at X Y</pre> 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 <pre>copy (overlay) block X Y W H "@filename.mzm" N</pre> 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#VLayer Tutorial|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?)
[[Category:MegaZeux]]
{{stub}}

Wervyn: /* MZM Tutorial */ Added a couple paragraphs. Needs a good example, but most MZM applications are really just preloading graphics or robots, too simple.

2008-01-10T20:23:11Z

MZM Tutorial: Added a couple paragraphs. Needs a good example, but most MZM applications are really just preloading graphics or robots, too simple.

← Older revision		Revision as of 20:23, 10 January 2008
Line 8:		Line 8:
	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.		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 <tt>copy (overlay) block</tt> and <tt>put</tt> commands have been co-opted with special syntax. To load an MZM, use the syntax <pre>put "@filename.mzm" Image_file pNN at X Y</pre> 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 <pre>copy (overlay) block X Y W H "@filename.mzm" N</pre> 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#VLayer Tutorial\|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?)
	[[Category:MegaZeux]]		[[Category:MegaZeux]]
	{{stub}}		{{stub}}

Wervyn: /* MZM Tutorial */ Started writing some info on how to use MZMs effectively. More to come, there'll be a fun example later, too

2008-01-07T21:39:22Z

MZM Tutorial: Started writing some info on how to use MZMs effectively. More to come, there'll be a fun example later, too

← Older revision		Revision as of 21:39, 7 January 2008
Line 2:		Line 2:

	==MZM Tutorial==		==MZM Tutorial==
	(~~Someone~~ should ~~write~~ this)		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.

			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.

	[[Category:MegaZeux]]		[[Category:MegaZeux]]
	{{stub}}		{{stub}}

Wervyn: Reverted edits by 75.44.190.228 (Talk); changed back to last version by WNivek

2007-03-25T02:19:59Z

Reverted edits by 75.44.190.228 (Talk); changed back to last version by WNivek

← Older revision		Revision as of 02:19, 25 March 2007
Line 1:		Line 1:
	~~Fuck you flaming faggots~~. ~~I'll never stop vandalizing~~. ~~I can change my IP at will!~~ :)		'''MZMs''' are self-contained sections of [[MegaZeux\|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 MZMs simply stored graphical data, while successive versions allowed for the storing of board parameters (such as whether an object was a customblock, a gem, a unit of ammo, etc.) and eventually stored robot code as well. 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==
			(Someone should write this)

			[[Category:MegaZeux]]
			{{stub}}

75.44.190.228 at 10:34, 24 March 2007

2007-03-24T10:34:51Z

← Older revision		Revision as of 10:34, 24 March 2007
Line 1:		Line 1:
	'''MZMs''' are self-contained sections of [[MegaZeux\|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 MZMs simply stored graphical data, while successive versions allowed for the storing of board parameters (such as whether an object was a customblock, a gem, a unit of ammo, etc.) and eventually stored robot code as well. 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.		Fuck you flaming faggots. I'll never stop vandalizing. I can change my IP at will! :)

	~~==MZM Tutorial==~~
	~~(Someone should write this)~~

	~~[[Category:MegaZeux]]~~
	~~{{stub}}~~

WNivek: Reverted edits by 75.36.19.215

2007-01-21T15:33:34Z

Reverted edits by 75.36.19.215

← Older revision		Revision as of 15:33, 21 January 2007
Line 1:		Line 1:
	~~FUCKING FAGGOTS!!~~		'''MZMs''' are self-contained sections of [[MegaZeux\|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 MZMs simply stored graphical data, while successive versions allowed for the storing of board parameters (such as whether an object was a customblock, a gem, a unit of ammo, etc.) and eventually stored robot code as well. 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==
			(Someone should write this)

			[[Category:MegaZeux]]
			{{stub}}

75.36.19.215 at 11:05, 21 January 2007

2007-01-21T11:05:31Z

← Older revision		Revision as of 11:05, 21 January 2007
Line 1:		Line 1:
	'''MZMs''' are self-contained sections of [[MegaZeux\|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 MZMs simply stored graphical data, while successive versions allowed for the storing of board parameters (such as whether an object was a customblock, a gem, a unit of ammo, etc.) and eventually stored robot code as well. 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.		FUCKING FAGGOTS!!

	~~==MZM Tutorial==~~
	~~(Someone should write this)~~

	~~[[Category:MegaZeux]]~~
	~~{{stub}}~~

Terryn: Reverted edits by 75.40.24.41 (Talk); changed back to last version by Wervyn

2006-12-11T15:51:20Z

Reverted edits by 75.40.24.41 (Talk); changed back to last version by Wervyn

← Older revision		Revision as of 15:51, 11 December 2006
Line 1:		Line 1:
	~~mzx~~ is ~~for faggots~~		'''MZMs''' are self-contained sections of [[MegaZeux\|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 MZMs simply stored graphical data, while successive versions allowed for the storing of board parameters (such as whether an object was a customblock, a gem, a unit of ammo, etc.) and eventually stored robot code as well. 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==
			(Someone should write this)

			[[Category:MegaZeux]]
			{{stub}}

75.40.24.41 at 09:44, 11 December 2006

2006-12-11T09:44:48Z

← Older revision		Revision as of 09:44, 11 December 2006
Line 1:		Line 1:
	'''MZMs''' are self-contained sections of [[MegaZeux\|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 MZMs simply stored graphical data, while successive versions allowed for the storing of board parameters (such as whether an object was a customblock, a gem, a unit of ammo, etc.) and eventually stored robot code as well. 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.		mzx is for faggots

	~~==MZM Tutorial==~~
	~~(Someone should write this)~~

	~~[[Category:MegaZeux]]~~
	~~{{stub}}~~