Well the demo that I downloaded was a program.  Its still available to download on his website I think.

I've been really busy this week so far and I'm leaving for school soon so I'll try to get a new version up soon, but not much new stuff will be added.  The one thing I have had time for though is a complete example game which I'm about halfway though, it will be the final example program and downloadable individually as well.  It's based on another game from Warioware that no one's heard of and its coming along very nicely.

Initially, I though I would have the final release nearly complete around this time, but I've decided instead to continue working on this a little more instead of compromising features.  Updates will be more sparse though since college is starting again but I plan to finish around the time of the contest deadline or shortly after.  There will still be updates after that, but I want a very stable, safe, and bug-free version out by then which will be 1.0.0

That could be easily written in Axe itself i would think, just send the 2 bytes of the 2 byte number.  However, it would be nice to automate the process

The second one, I don't think would work.  Actually, I don't think the first one would, either.  I haven't played with this yet, but you can only muck around with the two available bits, if I remember correctly.

ok. No, what happens if I run send on sender but don't do Get on reciever. Will reciever still recieve data?

Note to Quigbo: Can we try for a command to send 2 byte data?

Also can someone give me the HEX for an asm subroutine that emulates Basic's Input command? And tell me where it saves the input so that I can access it using Axe coding?

I forgot to address the break and continue idea.  Those are both definitely possible, it could even be used in If and Switch statements which would be cool.  Finding a token in a convenient menu might be a challenge though.

Sending multiple bytes is simple, I tested a program that sent the entire graph buffer from one calculator to the other and it took less than half a second.  In fact, it is easier and more reliable to send a section of ram than to send individual values so I would recommend that you store all your sending values in consecutive ram addresses to make it easier.

Pixel swap might be nice, but I don't have a good token for that.  Maybe I can put it in the same place as Pt-Mask.

I can see that as being very confusing, I'd much rather use the C syntax for that so at least its more intuitive.

By the way, that reminds me of a completely unrelated point.  Does anyone mind if I change a few of the tokens by simply changing the case of the first letter or removing the trailing space?  I'm trying to be consistent with my command namings so that commands that start with an uppercase letter must be used first on a line and commands that start with a lowercase letter can be used in expressions.  The trailing space has annoyed me on some commands like the DrawInv command since I'm not using the original syntax the extra space makes it awkward when you add the r modifier.  Would anyone be against changes like this?  As always, it only affects Axe source code.

Cagliano, what sort of input are you looking for? there's a topic under the axe parser subforum i made that has some code that accepts numbers 0-65535, unless you need string and list support.

I'm looking for string input actually. I want a user input string which i can then use in Axe's GetCalc( command.

I can see that as being very confusing, I'd much rather use the C syntax for that so at least its more intuitive.

By the way, that reminds me of a completely unrelated point.  Does anyone mind if I change a few of the tokens by simply changing the case of the first letter or removing the trailing space?  I'm trying to be consistent with my command namings so that commands that start with an uppercase letter must be used first on a line and commands that start with a lowercase letter can be used in expressions.  The trailing space has annoyed me on some commands like the DrawInv command since I'm not using the original syntax the extra space makes it awkward when you add the r modifier.  Would anyone be against changes like this?  As always, it only affects Axe source code.

That would be fine as long as those changes aren't too drastic. Example: no massive command changes making it even harder to search for commands in the CATALOG (like Rect() and RectI())