Cycle: Difference between revisions

From MZXWiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 3: Line 3:
There is also a command in MZX called "cycle", which sets the number of cycles between execution for the given robot.  For a long time, [[MZXers]] considered this command largely useless, since it is almost never desirable to have a robot that doesn't execute every cycle (cycle 1), and that is the default behavior.  (The same command exists in [[ZZT]], but the default there is #cycle 3, where an object executes code every three cycles.)  However, [[Wervyn]] pointed out that a side-effect of the command is to end the current cycle, and to do so without invoking a command that could span multiple cycles.  This makes "cycle 1" a better candidate for a busyloop terminator than the previous standard of "wait 1", because it avoids a peculiar edge case that can arise when sending [[subroutines]] to robots.  Since then, "cycle 1" has become the recommended terminating instruction for busyloops, since it is similar enough in syntax to "wait 1", and also suggests its function: to end the current cycle and wait X cycles before resuming execution.
There is also a command in MZX called "cycle", which sets the number of cycles between execution for the given robot.  For a long time, [[MZXers]] considered this command largely useless, since it is almost never desirable to have a robot that doesn't execute every cycle (cycle 1), and that is the default behavior.  (The same command exists in [[ZZT]], but the default there is #cycle 3, where an object executes code every three cycles.)  However, [[Wervyn]] pointed out that a side-effect of the command is to end the current cycle, and to do so without invoking a command that could span multiple cycles.  This makes "cycle 1" a better candidate for a busyloop terminator than the previous standard of "wait 1", because it avoids a peculiar edge case that can arise when sending [[subroutines]] to robots.  Since then, "cycle 1" has become the recommended terminating instruction for busyloops, since it is similar enough in syntax to "wait 1", and also suggests its function: to end the current cycle and wait X cycles before resuming execution.


[[Category:MegaZeux]][[Category:Megazeux Commands]]
[[Category:MegaZeux]][[Category:MegaZeux Commands]]

Revision as of 01:07, 26 January 2011

A MegaZeux cycle is essentially one frame of MZX execution, in which all robots on the board may execute some code, all objects on the board that move can move one space, and some amount of time passes according to the current MZX speed. MZX programmers most often think about cycles as they relate to robot execution, particularly in the areas of busyloops and commands. In the past, most people didn't worry about this, because the only way it really showed up in games was a hard limit of how much a robot could do in a certain amount of time. Since the advent of the "commands" counter, which allows the number of commands a robot CAN execute per cycle to be set in the billions, MZXers have paid much more attention to ensuring that robots only execute as many commands per cycle as they need to, so that all robots get a chance to execute their programs within a reasonable amount of time.

There is also a command in MZX called "cycle", which sets the number of cycles between execution for the given robot. For a long time, MZXers considered this command largely useless, since it is almost never desirable to have a robot that doesn't execute every cycle (cycle 1), and that is the default behavior. (The same command exists in ZZT, but the default there is #cycle 3, where an object executes code every three cycles.) However, Wervyn pointed out that a side-effect of the command is to end the current cycle, and to do so without invoking a command that could span multiple cycles. This makes "cycle 1" a better candidate for a busyloop terminator than the previous standard of "wait 1", because it avoids a peculiar edge case that can arise when sending subroutines to robots. Since then, "cycle 1" has become the recommended terminating instruction for busyloops, since it is similar enough in syntax to "wait 1", and also suggests its function: to end the current cycle and wait X cycles before resuming execution.