dMZX Forums: "WAIT for 1" vs. "CYCLE 1" - dMZX Forums

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

"WAIT for 1" vs. "CYCLE 1" What do I use?

#1 User is online   Lachesis 

  • the pinnacle of human emotion
  • Group: DigiStaff
  • Posts: 3,904
  • Joined: 17-July 04
  • Gender:Female
  • Location:Sealand

Posted 09 May 2012 - 02:21 AM

Alright, since there still seems to be some confusion about the nature of these commands, it's time to make a definitive guide about these two commands, what they do, why we need to use them, and the benefits of each.

WAIT 1 and CYCLE 1 each have their own sets of pros and cons, but it may take a little time to explain exactly what they are. If you don't care enough about MegaZeux's inner workings to read any further, this advice will probably be good enough for casual users:
Keep using WAIT 1.

That said, there are some useful things to be learned from this post that you might not already know.


WAIT 1 THEORY
In the olden ages, Gemini released a MegaZeux demonstration that was supposed to show the benefits of using WAIT 1 in Robotic code. It can be found here. Wait, 2 stars and bad ratings? I don't have to use WAIT 1, right? Nope, Gemini just didn't explain it particularly well, hence the bad reviews. WAIT 1 and CYCLE 1 will not make your Robotic code "faster". The reason why you need to use one of these commands is different, and needs a little more explanation.


THE CYCLE
A "cycle" is just MegaZeux's way of saying a "frame" or a division of run time in MegaZeux. Simply put (and incredibly oversimplified), during every cycle, everything on the board runs once or moves once per cycle. Take the default player or a built-in at its fastest speed: every time it moves is one cycle.

set "MZX_SPEED" 2

The MZX Speed affects how many of these "cycles" or "frames" are executed per second given this equation: 62.5 / (MZX_SPEED - 1) Speed 2 is twice as fast as speed 3 and three times as fast as Speed 4. Speed 1 is a special case -- it does not limit the number of frames executed per second, which can be a good thing in some cases but generally is undesirable. Running MZX at an unchecked framerate like this will have different results on different people's computers, for better or worse. MZX_SPEED defaults to 4. If you set MZX_SPEED to any value, it will disappear as an option from the F2 Menu unless you set MZX_SPEED to 0 after setting it to the desired value.


ROBOT EXECUTION
Every cycle, all of the robots and built-ins need to execute their code once. To fully understand how this works, you need to understand the way the board is executed.

  • First, the built-in player is handled, including all inputs and effects like wind.
  • The global robot is run; a cycle of the global robot's program is executed.
  • Next, something called the board scan is performed. MegaZeux goes over every char of the board (left-to-right, top-to-bottom), updating all of the built-in types like goblins and pushers. Robots are also executed during this scan; a cycle of each robot's program is executed when encountered.
  • The reverse send is handled (more on this later).

What constitutes a cycle of any particular robot's code? This is based on several factors.


CYCLE-ENDING COMMANDS
Several commands in MegaZeux will end a robot's cycle regardless of what code follows.

cycle 5

The cycle command alters how often the robot executes its code. Changing the robot's cycle value is similar to changing the speed of a built-in enemy -- if you change it to 2, the robot will only execute or move every other cycle. The cycle command itself ends a robot's cycle.

wait for 10
end

These commands allow a robot to receive sent labels with the Reverse Send, and I'll come back to these later. Some of these commands will take a certain number of cycles based on input values -- WAIT ends a number of cycles for that robot equal to the number given to it. END stops the robot from executing entirely.

go EAST 1
/ "n"
try NORTH else "noThanks"
move all c?? customblock p?? NORTH
move player to SOUTH
gotoxy 0 0
put player at 20 81
. "and several others I couldn't be bothered to list"

These all end the robot's cycle, but they aren't particularly special. As a guideline, anything that results in directly moving the robot itself, the player, or anything on the board will end a cycle.

shoot NORTH
shootmissile NORTH
shootseeker NORTH
spitfire NORTH

In MZX 2.83, these were cycle ending commands. This does not end the cycle in any other versions.

color fade in
color fade out

According to some documentation somewhere these used to end the cycle at some point in MZX's history, but they don't anymore. They will go into effect mid-cycle, causing a delay in processing robots and potentially showing the board mid-update.

: "loop"

See Lancer's post below


THE COMMANDS COUNTER
Alright, so if a robot doesn't have one of the cases above not in red, won't it just run forever? Not necessarily! The commands limit is meant to prevent this from happening. In earlier versions of MegaZeux, this limit was 40 commands per cycle, but a counter was added so the user can control its value.

set "COMMANDS" 4000

This means that the robot will execute up to 4000 lines of code if it doesn't run into a cycle ending command. When it reaches the 4000th line of code, it will stop so the next robot can execute its program. This counter defaults to 40. If you notice a robot of yours executing "slow" or something its supposed to be displaying lagging or flickering, you might need to increase the COMMANDS counter. Note that to set it any higher than 32767, you need to wrap the number in an expression:
set "COMMANDS" "(100000)"


set "COMMANDS" "(-1>>1)"

This might seem odd, but what it actually does is sets COMMANDS to the highest possible integer value in MegaZeux, 2 147 483 648. This causes your robot to run forever unless stopped by a cycle-ending command, essentially disabling the COMMANDS limit. In MegaZeux versions before 2.9X, this was dangerous as it would freeze MegaZeux if a coder accidentally put an infinite loop in their Robotic, but in MegaZeux 2.90, features were added so that users can break out of these loops. Using very high COMMANDS values like this is now safe.

In worlds developed in pre-2.9X versions, however, you should set your COMMANDS counter at a reasonable limit (like 10 million) so people playing with older MZX versions can still use Escape to exit from testing.


WHY SHOULD I USE WAIT 1 AND CYCLE 1 THEN
One of the test cases in Wait 1 Theory actually did show a benefit of using wait 1, which I will replicate here. Take this example:
set "COMMANDS" 32767
: "l"
copy block 0 0 10 10 10 0
goto "l"

This seems fine, right? I just want it to keep copying that block while the player is on the board... okay, now make 100 robots that copy this robot. MegaZeux is probably slow now, and if it isn't, it may be using up a decent portion of your computer's processing capabilities just to copy some block over and over again! If it still isn't, multiply commands by 100. Well, I don't need commands to be 32767 in this case, but maybe some other more complex engine on the board needs that many commands just to complete its code by the end of its cycle. This is where CYCLE 1 and WAIT 1 come in. Both of these commands will end a robot's cycle and usually nothing more, and are both ideal for ending the robot's cycle so it doesn't execute this copy block command 32767 times every cycle.
: "l"
copy block 0 0 10 10 10 0
wait for 1
goto "l"

There, that's better! Now that it's only running this command once per robot per cycle, it's not so bad!


WAIT 1 vs CYCLE 1

WAIT 1
+ Allows labels to be sent by the Reverse Send
+ Can wait for multiple cycles if you give it a bigger number.
+ Does not repeat when returning from externally sent subroutines (MegaZeux 2.90+ only)
- When returning from a subroutine sent from another robot, due to an MZX bug WAIT 1 is executed again, which will cause the robot to become stuck on that WAIT 1 if it is receiving a new subroutine every cycle. This is due to the robot's stack not storing the internal line position and affects other commands like GO DIR # and / "string". This only affects MZX versions prior to 2.90; in 2.90 and later, subroutine calls will properly store the internal line position.

CYCLE 1
+ Does not allow labels to be sent by the Reverse Send
+ Does not repeat when returning from externally sent subroutines
- Can't wait for multiple cycles without changing the cycle value.
- Different numbers need to be used if the robot is operating at another CYCLE value; this is mostly unused nowadays, but still something to keep in mind.


THE REVERSE SEND
Alright, here's a little bit of quirky MZX-behaviour that may be taken for granted or not even known about to most people. After every robot is executed initially, all robots are checked again in reverse. If a robot 1) is already ended, is waiting with the WAIT command, is waiting for its cycle (see: the CYCLE command with a value greater than one), or the first command it encounters for a given cycle is WAIT or END; and 2) was sent a label by a robot later in the list, the robot's program will begin execution AGAIN during the same cycle! For example:

  • Robot "Arf" is at 10,10. Robot "Barf" is at 80,80.
  • "Arf" ENDs immediately on the first cycle it it runs. "Barf" waits.
  • "Arf" is still ended. "Barf" sends "Arf" a label. "Barf" is further down on the board than "Arf" is, but "Arf" receives and executes the label on the very same cycle due to the reverse send.


Reverse send affects only the robots which ended their cycle in a way that allows the reverse send to occur. If "Arf" had ended the cycle with a CYCLE 1 when "Barf" sent the label, "Arf" would not have acted on it until the next cycle, because CYCLE 1 does not allow the reverse send to occur. Based on how your game works, the reverse send may be desirable behavior or it may actually break your engine.


CONCLUSION
So, from the pros/cons list, you probably noticed that WAIT 1 comes out ahead functionally for casual use, mostly for if you're using lots of robots on the body of the board that are sending labels back and forth. CYCLE 1 had some very important use cases when subroutines were in the mix before MegaZeux 2.90 -- multi-purpose robots that need to run every cycle, say, so animations don't skip, or something else that's very timing-intensive doesn't go unnoticed, but the robot still also needs to receive subroutines.

CYCLE 1 can also be used if you just want to avoid the reverse send altogether, which depending on your design, may be beneficial. If you have a robot using CYCLE 1, it will always wait on handling any label sent to it until the next cycle.

Due to the strict criteria for reverse send, it can not be used to get multiple executions per cycle out of a single robot.

Final note: the global robot is not eligible for receiving labels by reverse send, meaning WAIT 1 and CYCLE 1 are indistinguishable for it in MegaZeux 2.90 onward.

EDIT: updated terminology
EDIT: updated COMMANDS for 2.9X
EDIT: fixed reverse send info
"Let's just say I'm a GOOD hacker, AND virus maker. I'm sure you wouldn't like to pay for another PC would you?"

xx̊y (OST) - HELLQUEST (OST) - Zeux I: Labyrinth of Zeux (OST) (DOS OST)
w/ Lancer-X and/or asgromo: Pandora's Gate - Thanatos Insignia - no True(n) - For Elise OST
MegaZeux: Online Help File - Keycode Guide - Joystick Guide - Official GIT Repository
1

#2 User is offline   Dr Lancer-X 

  • 電波、届いた?
  • Group: DigiStaff
  • Posts: 8,938
  • Joined: 20-March 02
  • Location:ur mom nmiaow

Posted 09 May 2012 - 02:42 AM

Quote

Historically, this command used to only end the cycle if the next command was not another shoot command, I believe, but as of MZX 2.83 this command ends the current cycle. I believe it is also a Special Cycle-Ending Command.


Quote

In legacy versions of MegaZeux, this would end the cycle if the robot had already executed the label in question during the current cycle. This does not happen anymore. A compatibility fix will be implemented as of MegaZeux 2.84 to properly run old games that relied on this.


Not quite. The first behaviour stems from the second. Basically, the behaviour was that : "label" would be a cycle ending command if the following conditions are held:

- This label is also the last label encountered by the robot in the same cycle. This was stored based on locations in the robot, not the label name, so this code:
: "label"
: "label"
would not result in a cycle ending (otherwise old-style boss enemies with heaps of : "shot" labels would wait like twenty cycles each time they got hit at first.
- None of the following commands have been seen between now and the previous time that label was encountered:
set
inc
dec
double
half
give
take
trade
multiply
divide
modulo
loop for #


This behaviour has been reimplemented- I think in a versioned fashion, so you shouldn't have to worry about it for code you write today.
Posted Image
<Malwyn> Yes, yes. Don't worry I'd rather masturbate with broken glass than ask you for help again. :(
0

#3 User is online   Lachesis 

  • the pinnacle of human emotion
  • Group: DigiStaff
  • Posts: 3,904
  • Joined: 17-July 04
  • Gender:Female
  • Location:Sealand

Posted 09 May 2012 - 02:47 AM

That's even worse than I thought :( thanks for clarifying that. But yeah, nobody will have to worry about that anymore, and SHOOT is fixed as of 2.84 as well.
"Let's just say I'm a GOOD hacker, AND virus maker. I'm sure you wouldn't like to pay for another PC would you?"

xx̊y (OST) - HELLQUEST (OST) - Zeux I: Labyrinth of Zeux (OST) (DOS OST)
w/ Lancer-X and/or asgromo: Pandora's Gate - Thanatos Insignia - no True(n) - For Elise OST
MegaZeux: Online Help File - Keycode Guide - Joystick Guide - Official GIT Repository
0

#4 User is online   Lachesis 

  • the pinnacle of human emotion
  • Group: DigiStaff
  • Posts: 3,904
  • Joined: 17-July 04
  • Gender:Female
  • Location:Sealand

Posted 09 May 2012 - 04:38 AM

Test case:

: "l"
. "cycle ending command here"
wait for 1

inc "LOCAL" by 1
put "('LOCAL'%15)" '' overlay to "THISX" "('THISY'-1)"
goto "l"
: "#sub"
put "('LOCAL'%15)" '' overlay to "('THISX'+1)" "('THISY'-1)"
goto "#RETURN"


Put this robot below that one:
end
: "touch"
send NORTH "#sub"
end


When you touch the bottom one, any cycle ending command will either have the second bit of overlay one color behind the first one or they will stop on the same color. Ideally, there would be a command that has them display the same color at the same time without stopping, but o well.
"Let's just say I'm a GOOD hacker, AND virus maker. I'm sure you wouldn't like to pay for another PC would you?"

xx̊y (OST) - HELLQUEST (OST) - Zeux I: Labyrinth of Zeux (OST) (DOS OST)
w/ Lancer-X and/or asgromo: Pandora's Gate - Thanatos Insignia - no True(n) - For Elise OST
MegaZeux: Online Help File - Keycode Guide - Joystick Guide - Official GIT Repository
0

#5 User is offline   Baby Bonnie Hood 

  • Neatsome!
  • PipPipPipPip
  • Group: Members
  • Posts: 811
  • Joined: 16-August 00
  • Gender:Male
  • Location:Philippines

Posted 09 May 2012 - 04:45 AM

So... just keep using wait 1 like I always do anyway. Gotcha.
Posted Image
0

#6 User is online   Lachesis 

  • the pinnacle of human emotion
  • Group: DigiStaff
  • Posts: 3,904
  • Joined: 17-July 04
  • Gender:Female
  • Location:Sealand

Posted 09 May 2012 - 05:00 AM

Yes. This "article" (I guess) was dually aimed at people who still don't use either and those who switched to CYCLE 1 because of the subroutine benefits back when Wervyn originally proposed the switch, or just people interested in knowing how and why they should actually do this if they didn't already. I, personally, still use CYCLE 1 a lot because I have a lot of subroutines flying back and Forth in my more classic-styled games. Lancer-X discovered the reverse scan several months ago, which I felt really necessitated a new thread about it, but I never got around to writing it up until now.
"Let's just say I'm a GOOD hacker, AND virus maker. I'm sure you wouldn't like to pay for another PC would you?"

xx̊y (OST) - HELLQUEST (OST) - Zeux I: Labyrinth of Zeux (OST) (DOS OST)
w/ Lancer-X and/or asgromo: Pandora's Gate - Thanatos Insignia - no True(n) - For Elise OST
MegaZeux: Online Help File - Keycode Guide - Joystick Guide - Official GIT Repository
1

#7 User is offline   Dr Lancer-X 

  • 電波、届いた?
  • Group: DigiStaff
  • Posts: 8,938
  • Joined: 20-March 02
  • Location:ur mom nmiaow

Posted 09 May 2012 - 09:18 AM

I myself consider the reverse scan to be somewhat undesirable, mostly because if you're coding within the pipeline model you probably don't want it to happen. My current project acquired a nasty bug as a result of the reverse scan and it would probably have taken a looong time to determine the cause of it if I didn't already know about it. I ended up fixing it with a cycle 1 loop. For that reason it might be more worthwhile to use cycle 1 in the place of wait 1, not less, but it depends on what you're doing at the time.

Plus, the global robot isn't included in the reverse scan even though it would be the single most useful robot to be able to reverse send to, since it always runs first every cycle. Hence I don't see myself ever deliberately using reverse send, especially because any robot hit with a reverse send is probably responsible for its own part in the pipeline and is built to send labels to or otherwise set up data for other robots that appear after it. If I want a specific piece of functionality to be executed later in the pipeline, I'll put it in another robot or create a new robot to handle that.
Posted Image
<Malwyn> Yes, yes. Don't worry I'd rather masturbate with broken glass than ask you for help again. :(
0

#8 User is offline   Exophase 

  • Laughing on the inside.
  • Group: DigiStaff
  • Posts: 7,155
  • Joined: 23-October 00
  • Gender:Male
  • Location:Cleveland, OH

Posted 09 May 2012 - 02:43 PM

MZX is such a mess. Pretty much anyone looking in would be intimidated by this >_>

What old games are relying on the label-based yielding to work properly? It looked like something that predated the commands-per-cycle limit and trying to reproduce it with the new label code in 2.80 was a pretty major pain in the ass. I mean, if it wasn't obvious why I removed it.
~ ex0 has a kickass battle engine, without it you sux0rz! without it you sux0rz! ~

"The fact that I say I've one of the best, is called honesty." -Akwende
"Megazeux is not ment to be just ASCII, it is ANSI!" - T-bone6
"I hate it when you get all exo on me." - emalkay

Exophase can what Rubi-cant.
exoware is ware ur ware is exoware
ps. not loking 4 new membrs kthx
0

#9 User is offline   ThDPro 

  • Brontosaurus-Sea-slug; Gooey and phallic
  • PipPipPipPip
  • Group: Members
  • Posts: 718
  • Joined: 03-December 06
  • Gender:Male
  • Location:Portland, OR

Posted 09 May 2012 - 05:00 PM

I'm sure I played my part in this thread existing, and for that reason, I'm glad I was confused and made some huge mistakes with my latest release Lache beta-ed and about which she told me I was being stupid. (an idea to which I subscribe as well.) Now those issues are fixed and it yielded this explanation of the problem I was having trouble grasping, so at least something good came out of my stupidity.

Now... Time to fix DOMINATION...

This post has been edited by ThDPro: 09 May 2012 - 05:01 PM

original soundtracks
Better Than Nothing - DOMINATION - Commander Keen: Heroes Lost - Welkin - A Confectioner's Recipe - random ThDPro music stuff
<Risu21121> if you're not going to make a good game, you might as well make a blatantly racist one.
<Kuddy> Testicles.
"Where are my folder?" - KKairos
0

#10 User is online   Lachesis 

  • the pinnacle of human emotion
  • Group: DigiStaff
  • Posts: 3,904
  • Joined: 17-July 04
  • Gender:Female
  • Location:Sealand

Posted 09 May 2012 - 05:18 PM

I don't mind the reverse scan besides the fact that to my knowledge it's completely undocumented except in code and kinda sneaky. To me it just seems like an attempt to make the first board scan invisible to the casual or beginning user. Also, it falls apart when used in conjunction with subroutines: either you get the benefits of reverse scan at the cost of having your special cycle-ending command repeat over and over, or you receive subroutines a cycle after they're sent, which may or may not be what you'd like. I still plan on sticking with cycle 1 because of the subroutines benefit and not having to worry about whether something will happen on the reverse scan.

I don't know if there is anything actually broken by : "label" not ending the cycle, but I'm sure if there wasn't, the erroneous SHOOT "fix" wouldn't have been made.

I'd also like to note that replacing WAIT 1 with another special command (besides END) has the same effect and replacing CYCLE 1 with another non-special command has the same effect. Furthermore, most of those commands have conditions where they won't actually end the cycle (0 for WAIT and GO, failed movement for TRY, IDLE for TRY and MOVE PLAYER, empty string for /...).
"Let's just say I'm a GOOD hacker, AND virus maker. I'm sure you wouldn't like to pay for another PC would you?"

xx̊y (OST) - HELLQUEST (OST) - Zeux I: Labyrinth of Zeux (OST) (DOS OST)
w/ Lancer-X and/or asgromo: Pandora's Gate - Thanatos Insignia - no True(n) - For Elise OST
MegaZeux: Online Help File - Keycode Guide - Joystick Guide - Official GIT Repository
0

#11 User is offline   T-Bone 

  • Wastelander
  • PipPipPipPipPip
  • Group: Members
  • Posts: 2,487
  • Joined: 16-August 02
  • Gender:Male
  • Location:Canada

Posted 16 May 2012 - 07:25 AM

I used to use "?i" I believe in ZZT as wait 1. lol
Youtube - teabone3 - Twitter - teabone3 - Twitch - teabone3
0

#12 User is offline   Graham 

  • . "@Master Procrastinator"
  • PipPipPipPip
  • Group: Members
  • Posts: 625
  • Joined: 28-December 12
  • Gender:Male
  • Location:Oregon

Posted 24 July 2013 - 08:54 PM

CYCLES AND COMMANDS

https://github.com/a...nd_commands.txt

I feel like this should be added to this article. It is a complete list of commands and wether they cause a cycle to end. I can't remember where I got this from, but fortunately I bookmarked it.
Currently working on Servo for MegaZeux, I hope to complete it by the middle of 2015? Who knows...

"Before you criticize someone, you should walk a mile in their shoes. That way, when you criticize them, you’re a mile away and you have their shoes."
-Jack Handey
0

#13 User is offline   Wervyn 

  • I can see you
  • Group: DigiStaff
  • Posts: 1,855
  • Joined: 24-December 00
  • Gender:Male
  • Location:Caras Galadhon

Posted 27 February 2015 - 03:56 PM

Since Old-Skool just linked this thread again I was looking through it and realized I'd never actually weighed in. So I thought it might be fun to go through the history of why I raised the issue in the first place, and what I think of it now.

The main impetus for my original cycle 1 proposal (found here) was a bug I encountered during the Winter 2007 DoZ, dealing with inter-robot subroutines. The bug is already explained in the original post, but playing through the space shooter section of our game (86709 - Stan Dirtbike in Space Gold Is Where The Heart Used To Be) will hopefully illustrate its practical effects. Notably, once you get your ship's rate of fire and speed fully upgraded, hold down space to auto-fire and move forward at the same time, and then stop holding space while still moving forward. You should notice that the bullets lag behind while you're firing, and then start moving faster once you stop.

This happens because the engine divides the responsibilities for player input and drawing all the bullets into separate robots. When firing, the player robot sends #addBullet messages to the bullet robot, which then handles adding them to the current processing queue. (This is from memory, I haven't actually looked at my implementation so it may have slight differences, but that should be the gist.) Because of the subroutine bug though, it then doesn't get to execute its normal update routine that cycle. Since the max rate of fire lets you shoot every two cycles, the effect is that the bullets also only get to move every other cycle, hence the lag.

For this reason I still consider the wait 1 subroutine quirk to be a more serious issue than cycle 1's lack of reverse-send eligibility. It's rare for an engine to rely on same-cycle timing between two robots' execution, the 30ms or so of delay at speed 4 would be hardly noticeable. If anything, as Lancer and Lachesis pointed out in the past, reverse-send behavior is more likely to cause unexpected problems in complex engines that may expect each robot to only run once per cycle. By contrast, the subroutine sending issue isn't one of delay, but one of failure to execute. That is, it also causes the "run once per cycle" assumption to fail. "Cycle 1" behavior is locally deterministic in all cases, it unequivocally means "code execution will resume from this point on and ONLY on the next cycle."

With all that said, I still agree that wait 1 should be preferred to cycle 1, particularly when it comes to instructing new users in safe loops. Why? Because cycle 1 is a hack. It's an unintended use of an obscure piece of syntax that happily has a somewhat intuitive meaning (as opposed to something like gotoxy "thisx" "thisy"). Wait 1 means, from a program standpoint, exactly what it sounds like it means, "wait for 1 [cycle]". Cycle 1 DOESN'T mean "[wait for] 1 cycle", it just happens to have that side-effect. It's more accurate to think of it as a cycle ending NOOP. Teaching newbies to unquestioningly use it creates false assumptions about what the command actually does, and without clear and detailed instruction (and ain't nobody got time for that) will lead to confusing results if they try to use the command as a universal replacement for wait. Cycle 1 is a work-around for a very specific class of problem that generally isn't encountered until one is already pretty familiar with MZX. It should therefore be used only when you understand exactly what issue you're trying to work around.

"If all the threads are dead, thread necromancy means that the dead are at least doing something."
To lie is to change the truth.
..Ignorance is to be unaware of the truth.
....Incompetence is to be unable to grasp the truth.
......And escape is to run away from the truth.
It is useless to run, since the truth is right next to you.

-Wervyn
1

#14 User is online   Lachesis 

  • the pinnacle of human emotion
  • Group: DigiStaff
  • Posts: 3,904
  • Joined: 17-July 04
  • Gender:Female
  • Location:Sealand

Posted 27 February 2015 - 05:08 PM

I'm not sure I entirely knew what I was talking about when I wrote this. Now I mostly use sends in robots at the top of the board to halt/restart other robots at the top of the board; I don't know where I'd be without cycle 1 to stop the reverse send from breaking things. I shouldn't have played that up like a negative, because now it's the only reason my games work properly
"Let's just say I'm a GOOD hacker, AND virus maker. I'm sure you wouldn't like to pay for another PC would you?"

xx̊y (OST) - HELLQUEST (OST) - Zeux I: Labyrinth of Zeux (OST) (DOS OST)
w/ Lancer-X and/or asgromo: Pandora's Gate - Thanatos Insignia - no True(n) - For Elise OST
MegaZeux: Online Help File - Keycode Guide - Joystick Guide - Official GIT Repository
0

#15 User is offline   Dr Lancer-X 

  • 電波、届いた?
  • Group: DigiStaff
  • Posts: 8,938
  • Joined: 20-March 02
  • Location:ur mom nmiaow

Posted 27 February 2015 - 10:00 PM

View PostWervyn, on 28 February 2015 - 01:56 AM, said:

For this reason I still consider the wait 1 subroutine quirk to be a more serious issue than cycle 1's lack of reverse-send eligibility. It's rare for an engine to rely on same-cycle timing between two robots' execution, the 30ms or so of delay at speed 4 would be hardly noticeable. If anything, as Lancer and Lachesis pointed out in the past, reverse-send behavior is more likely to cause unexpected problems in complex engines that may expect each robot to only run once per cycle. By contrast, the subroutine sending issue isn't one of delay, but one of failure to execute. That is, it also causes the "run once per cycle" assumption to fail. "Cycle 1" behavior is locally deterministic in all cases, it unequivocally means "code execution will resume from this point on and ONLY on the next cycle."


that's way scarier though. at least when your subroutine stuff breaks you'll probably figure out it's due to subroutine sending pretty quickly, and possibly rewrite your code to send to a regular label or just use a counter to communicate instead. by contrast reverse send is super insidious and leads to obscure timing bugs that are very hard to pinpoint, probably hard to reproduce and if you don't know about reverse send odds are you'll never figure them out. this is why cycle 1 is a good sanity preserver, although i'll admit to using wait 1 right up until i send a robot to a subroutine or send to a robot that has already executed this cycle

that said, when people start using mzx they usually think of everything happening at once and the concept of one robot doing something to prepare things for another robot that's going to execute simultaneously with the first robot doesn't come up. mzx looks like a scary unpredictable multithreaded system, so from that perspective reverse send doesn't matter so much. but once you get past that stage and realise the power of pipelining reverse send becomes quite scary indeed.
Posted Image
<Malwyn> Yes, yes. Don't worry I'd rather masturbate with broken glass than ask you for help again. :(
0

#16 User is offline   Graham 

  • . "@Master Procrastinator"
  • PipPipPipPip
  • Group: Members
  • Posts: 625
  • Joined: 28-December 12
  • Gender:Male
  • Location:Oregon

Posted 01 March 2015 - 03:13 AM

View PostWervyn, on 27 February 2015 - 07:56 AM, said:

With all that said, I still agree that wait 1 should be preferred to cycle 1, particularly when it comes to instructing new users in safe loops.


Agreed. My inclusion of 'cycle' in the example code I gave Oneiros was purely a goof up on my part and not intentional.
Currently working on Servo for MegaZeux, I hope to complete it by the middle of 2015? Who knows...

"Before you criticize someone, you should walk a mile in their shoes. That way, when you criticize them, you’re a mile away and you have their shoes."
-Jack Handey
0

#17 User is offline   CJA 

  • «≡larch bucket≡»
  • PipPipPipPipPipPip
  • Group: Members
  • Posts: 3,262
  • Joined: 23-June 05
  • Gender:Male
  • Location:......@.c....

Posted 03 March 2015 - 02:24 AM

This is why Omnibot is the superior solution, why use an intuitive division of labor when you can make an awful amalgamated state machine!
Need a dispenser here.
0

#18 User is offline   Dr Lancer-X 

  • 電波、届いた?
  • Group: DigiStaff
  • Posts: 8,938
  • Joined: 20-March 02
  • Location:ur mom nmiaow

Posted 03 March 2015 - 04:30 AM

we should just throw the board scan out and let robots do what they want when they want. at least then we can multithread it, watch performance go through the roof even if all our existing games stop working.

it'll bring back 'army of robots' coding as a viable way of processing expensive tasks too!
Posted Image
<Malwyn> Yes, yes. Don't worry I'd rather masturbate with broken glass than ask you for help again. :(
2

#19 User is offline   CJA 

  • «≡larch bucket≡»
  • PipPipPipPipPipPip
  • Group: Members
  • Posts: 3,262
  • Joined: 23-June 05
  • Gender:Male
  • Location:......@.c....

Posted 03 March 2015 - 10:11 PM

I made two half-hearted attempts to program a simple battle engine recently, one by using my "proper" text-editor-only approach, another by trying to just use multiple robots and divide the tasks up. I found that having independent robots is not so good for anything relating to game logic; in other words, all the battle code should go in one robot, and all the other robots are there to be servants, positioning sprites and creating graphical effects based on what the Demibot does. Other robots have the task of drawing selected arrows over top of the proper sprites, making the enemies onscreen be in the right position, etc. I think I am going to hybridize my approach from now on; I'll probably be putting graphical code right into the game via the Robotic editor, and working on game logic from the outside.

Why's that? I dunno, but I think I've reached the point where using multiple Robots to split different mechanical things (for example, weapon effects, handling health and death, whatever) is much less important than the "security" of putting everything that coexists in one Robot. That way, they don't ever really conflict, you can control the order when things run, you can halt everything, yadda yadda. Also, using a variable for states between robots is a pain in the butt and I'm always afraid that two routines (or, even worse, zero!) will run at the same time. The Global robot for me now is generally a library-bot and contains persistent code like inc "cycles" 1 and quasi-persistent counters. I've sort of been so corrupted by "actual" coding (why can I not find better words for this?) that I can't even use MegaZeux as if it were MegaZeux anymore. Buhhh.
Need a dispenser here.
0

#20 User is offline   Dr Lancer-X 

  • 電波、届いた?
  • Group: DigiStaff
  • Posts: 8,938
  • Joined: 20-March 02
  • Location:ur mom nmiaow

Posted 03 March 2015 - 10:24 PM

battle engines normally have a few different 'concerns' that it can be valuable to split up, but honestly, the most important reason for doing so is that the 64k per-robot mem limit vanishes pretty quickly when coding battle engines. i like to, for example, split up the turn progression stuff, the move input, the enemy ai and the action execution (this robot is always the one that has trouble with the 64k limit) into separate robots. the main problem with splitting things up beyond truly separate concerns is that within these concerns there's no doubt a lot of functionality you'll want to use through subroutines or whatever and you can't do that properly when you split your code up. your choices at that point are pretty much to duplicate this code across robots (absolute hell when you have to alter it, and you will), do intra-robot sends (useless if you want to return in that same cycle. unless you use reverse send. and even that can only be done once per cycle) or mid-execution load_robot like taoyarin does (ugh)

making battle engines in mzx is hard.

EDIT: btw i still use the robot editor for everything :>
Posted Image
<Malwyn> Yes, yes. Don't worry I'd rather masturbate with broken glass than ask you for help again. :(
1

#21 User is online   Lachesis 

  • the pinnacle of human emotion
  • Group: DigiStaff
  • Posts: 3,904
  • Joined: 17-July 04
  • Gender:Female
  • Location:Sealand

Posted 03 March 2015 - 11:06 PM

i mostly use my global for scanning directories and loading all the files into strings :(

edit: oh yeah and script tokenization but i'll probably redo that in python because jfc
"Let's just say I'm a GOOD hacker, AND virus maker. I'm sure you wouldn't like to pay for another PC would you?"

xx̊y (OST) - HELLQUEST (OST) - Zeux I: Labyrinth of Zeux (OST) (DOS OST)
w/ Lancer-X and/or asgromo: Pandora's Gate - Thanatos Insignia - no True(n) - For Elise OST
MegaZeux: Online Help File - Keycode Guide - Joystick Guide - Official GIT Repository
0

Share this topic:


Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users