Alright, (x,y) at 0 it is!  I've finished that command.  Interestingly enough, "Output(" and "Disp" are nearly identical commands.  The only difference is that output first gets the coordinate position.  Then, after the second comma, the compiler treats whatever follows as if it were a Disp command.  Since my Disp command, unlike BASIC, does not have automatic line returns, they really are equivalent!  That also means that things like Output(x,y,Str1,"Hello",Str3) are valid.

Thanks for the feedback!

Woot!  So when is the next release coming around?  

* Builderboy is eager to start making primitive ASCII games in asm ^^ *

Haha yeah oops

Its an imprecise technology >.>

Mostly the error was due to attempting to interface with such a device such as the iTouch using remotely controlled gerbils.

Can't iTouch spellchecker be disabled? I personally would disable it if it was gonna do such typos

Back on topic...

I'm going to get to the sprite stuff soon, but I don't know quite how the user will define a sprite.  I think I will offer multiple methods for different purposes, but I'm not sure what they will be exactly.

My first idea was to do something like this:
StorePic 1A
[--****--]
[-******-]
[**-**-**]
[********]
[*-****-*]
[**----**]
[-******-]
[--****--]
It looks better on the calc.  This would store a happy face into Pic1A.  The problem with this, is that it uses a lot of space in the Source file, but the advantage is that you can make the entire program without needing any external tools and it becomes very easy to make sprites.

Another option is to store pictures using Hex code.
[3C7EDBFFBDC37E3C]->Pic1A
It uses less space in the source, but it would require you to run an external program to convert a pic into Hex code.

A third option is to save the sprites as tiles on one of the picture files.
GetCalc(Pic1,8,16)->Pic1A
The biggest problem with this is that the source is dependent on the extra picture files and it is difficult to draw the sprites on-calc (although I guess you can still use an external helper program).

Does anyone have any other ideas for how to define sprites?  Or a better syntax?

Whatever method you choose for sprites I would prefer if Axe did not have to rely on a seprate external program to implement sprites. However, if the most efficient way to handle sprites is by the use of an external program then I am all for it. Hmm... perhaps sprites could be stored in a user defined appvar and called from there?

Actually, now that I am thinking more about it, I think an external program would be the best way. It would be used to edit, view, and save sprites.

For usage in a program: Syntax: RecallPic Appvar name, sprite width(multiple of 8), sprite height, screen x coordinate, screen y coordinate.

Each appvar would be predefined to hold 768 bytes of data( i dont know if appvars themselves take up space), so you can either fill it with one full screen pic or several smaller sprites 8x8, 16x16 etc.

At compile time all the necessary data could be copied from the Appvar. If this is plausible, I don't know that the StorePic command would even be necessary in it's normal sense.

Actually now that you mention it, maybe the option of storing sprites to an external program might be an idea if the program is archived. That way games with a lot of sprites wouldn't be a big problem to be ran in 24 KB of RAM. The issue, though, is that running stuff from archive would be much slower