Right. That is exactly how I did it on the calculator. Token for token, hex for hex, and number for number

edit: Ok, I added the same [xxxxxxxxx]->pic1 right after pause 100, and it worked... I guess it forgot that pic1 was stored? 
edit: I put the diagnostic off after the sprite, and it worked. I think thats what did it

That shouldn't be happening, I'll look into it.

I hate little endian!  It was so confusing when I was learning assembly and caused all sorts of errors.  But you kinda grow to like it eventually because it makes some things simpler.  Fortunately you never have to deal with that directly in Axe unless you actually go to look at the data you wrote in some non-conventional way.

Welcome here!

By the way, the code for the game pack itself, not including title screen stuff, would be much less than the size of the individual games.  That's becasue they can all share the same routines like the sprite drawing commands, Dispgraph, rand, multiplication, modulus, etc. all taken care of by the parser.   I'm guessing it would likely save about 200-300 bytes for each program after the first one.

Pointers (page 9)
Actually, there's no such thing as "the zeroth item"; the correct way to say this would be "the first byte has address zero, the second byte has address one". Not exactly intuitive, I know. If you don't want to change this I can understand.

Actually, in computer science, you really DO start counting at zero so you can have a 0th element as part of a list.  I even put a comic in there that mentions something about that.  Thanks for pointing out the other error though.

It might be easier to understand to write "GDB1+A" (assuming that Axe understands this; I didn't check, but assume it does). I understand the current notation is not so much wrong, but it could be unclear for beginning programmers.
Since you are very consistent about this notation, I assume there's a reason for it... performance? Can Axe optimize "A+GDB1" better than it optimizes "GDB1+A"? If so, maybe you should explicitely state both are valid, but "A+GDB1" is slightly faster.

"We use the curly brackets to indicate that we want the byte that's at the address of the pointer, not the the value of the pointer itself."
From reading your code samples:
Disp Str1        Displays the contents of the (probably zero-terminated) string starting at the address in Str1.
Disp {A+GDB1}    Displays the value of the single byte at base address GDB1 incremented with offset A.
That's quite a difference from what you're saying in the documentation...

To answer your first question, sometimes.  If you are adding an arbitrary number like A+492 or some pointer it won't generally make a difference.  But, certain numbers get automatically optimized (smaller size, faster speed) like A+1 or A-256, there is a big list of these "auto-ops" in the zip file.  My intention is to get the programmer in this habit so they don't have to think about it when optimizing their code.  Maybe I'll mention the reason somewhere there, I do mention it at the end in the optimization section.

About your other point, the first one takes a pointer as an argument, which is why it doesn't need the brackets.  The second one is supposed to have a ▶Dec that I forgot to add, fixed than now thanks.  That takes a number as an argument which is why you need the brackets.

Data & Arrays (page 11)

The comments for one of the pieces of sample code say "BAISC", oops...

An Example Program (page 14)

You're already using the "optimized dual-store":
0->S-1->D
This hasn't been explained yet and is hardly standard notation. Putting a note "see page 17 for details" would be helpful.

Optimization tricks (page 17)

"Evaluate all constant expressions before compiling."
It would be very awesome if you could teach Axe to recognize expressions working on two constants and automatically decide to pre-compute them...

I'm not sure what you're talking about with the "BASIC" thing... EDIT: Nevermind, just noticed the spelling

Thanks for the other tips though.  I'll try to add some more stuff.  And the precompile constants I've actually been working on all this week, it will be in the next release.

"If the last line of your program is Return, then remove it. Even if it was part of a subroutine, the return is automatically added at the end for you so there's no need to have 2 returns at the end. Saves 1 byte."
Uhm, that saves 1 byte in the source, not in the executable, right?

Nope, executable  Although eventually I'll remove it automatically when compiling so the programmer doesn't have to bother with it.

And about commands.htm:
Fix CODE: Changes how text is drawn. Code must be a constant.
Wouldn't it make more sense to make CODE consist of flags? That way you can set multiple values at once. Especially useful if you want to reset everything at the end of your code.

ReturnIf EXP
Is there a special reason to include this? It seems to be equivalent to If EXP Return End.

That's actually a really cool suggestion!  Are you suggesting that saying Fix 135 would behave the same as Fix 1:Fix 3:Fix 5 ?  That could work, I like the idea!

The special reason is that its convenient for the programmer and its more optimized in the executable than doing an if statement.

Horray!    I hope they get all their members back too!

Hey thanks! I just noticed it now   Its especially cool they put the tribute video up there too.

That's what backbuffers are for so you don't have to save it every time you draw the sprite.

The AND thing I guess I can see how it would be used... but then you have to use AND followed by an OR to actually get masking.  That's the same amount of steps as doing an OR followed by an XOR (another way of doing masking) so it doesn't really add anything new, just more convenience.  Also, I'm all out of tokens for that.

Coming Soon:
I'm thinking of having a "command freeze" very soon.  I'm a little overwhelmed right now with fixing the stuff I already have and I think I want to start working more on the parser itself to make it more efficient and add all those cool features like app compiling, error scrolling, long names for labels/static pointers, making the syntax more loose, many more optimizations, safety modes, on breaks; you get the point, the list goes on for a while and these are things I've been avoiding becasue I wanted to make the parser more functional first.  Right now, I think its pretty decent, so its time I start working on those other features until I get a good chunk of them done.  There might still be some new commands, but not very many between updates.  These will be the 0.3.x updates.

I want to request a feature...
How about jumping to the address in a variable?  Such as Goto {A}, for instance, would jump to A.
And you could have something like [LB]->A to store the address of Lbl LB to A.  This would be useful for jump tables, which is something I really want

Also, user access to the stack would be nice as well.  I would really like to be able to push a variable onto the stack, then pop it off later.

Both of these things are features I am purposely not adding.  The variable goto isn't really used that much in regular assembly and has very limited application.  Its also very easy to screw things up by accidentally jumping to the wrong place and completely messing up the calculator.  I am trying to make it as safe to use as possible, and this is really just an unnecessary danger.  You can do this with a 2 byte assembly code if you really need it.

Pushing and popping into the stack has the same problem.  If you push a variable in a subroutine for instance, then the subroutine cannot return and the program crashes becasue it jumps to the wrong location.  Also, forgetting to pop can lead to stack overflows which are also not good.


The instant goto I'd like to add, but I don't even have the regular goto error working yet so I don't even know how it would be done.  I can do a similar "faking it" sort of thing where it just displays the error instead of going into the editor I guess.

Oh yeah, you're right, I forgot to check if its archived    Thanks for helping me find that problem!