I managed to come up with a feature request. The sprite routines seem somewhat incomplete, only including OR, XOR, and full clear followed by OR (Pt-On, Pt-Change, and Pt-Off, respectively).
My two suggestions are:
add something corresponding to AND, or add a command to use two layers specifying what is cleared followed by what is OR'd
The second, though somewhat less useful one is: Allow sprite commands (except for Pt-Change) to have an extra argument (not required) that would save what's about to be written over. Basically creates a back-copy for later restoration, presumably when the other sprite moves.

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.

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

My concern was more about grayscale. Where on the backbuffer and buffer do you store the area your sprite is gonna walk on to redraw it later after the sprite moved, since both buffer and back buffer are entirely used for the grayscale?

That said it is not a big hurry, though. Seeing how fast

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.

Sounds like a good deal. I think it's better to improve the parsing and stuff before adding too many other features, so that makes less features code to change later once you optimize. Also, this would make it less overhelming for people who will participate in the programming contest. Since the contest will most likely only last 3 and half a month (or 4), not having to change our code syntax everytime an Axe update comes out will be very appreciated. (people could just use an old Axe version if they don't want to update their code, but that slows down their development considerably)

Also seeing how much you worked on this despite school and stuff, I think if you want to take a break at one point, you deserve it a lot.

true, though it's more troublesome for greyscale, as DJ said. OR followed by XOR? Hmm... never realized that. Will use.
Yeah, the command freeze is a good idea. And as always, keep up the good work!

you can also do "pt-change(x,y,pic22)" with pic22 being [FFFFFFFFFFFFFFFF]  You don't have to use pic22, just an example.  I believe our dear friend made a routine that does this with out using another sprite, but it goes along the same lines of two for( loops...only different

If you want to actualy change the sprite data itself, you could run this:

Code: [Select]

For(F,0,15
{Pic0+F} xor 255->{Pic0+F}
End
and then the sprite will stay inverted forever after.

Just remember that will only work as expected for no-stub programs. If it's for a shell, the sprite will be inverted every other time you run the program, and for an App the sprite wouldn't invert at all.

The following is a list of all screen/buffer commands, with the size of the routine indicated in parentheses:

• ClrHome (6)
• ClrDraw (3)
• ClrDrawʳ (6)
• DispGraph (46)
• DispGraphʳ (63)
• StoreGDB  (6)
• StorePic  (11)
• RecallPic  (11)
• DrawInv  (17)
• DrawInv ʳ (20)
• Horizontal + (18)
• Horizontal - (18)
• Vertical + (13)
• Vertical - (13)
• Shade() (8)

The following is a list of the screen/buffer commands that do not utilize subroutines and the increase therefore in program size if the command is called 1, 2, 3, or n times compared to if it was called using subroutines:

• ClrHome (-4, -1, 2, 3n-7)
• ClrDraw (-4, -4, -4, -4)
• ClrDrawʳ (-4, -1, 2, 3n-7)
• StoreGDB  (-4, -1, 2, 3n-7)
• StorePic  (-4, 4, 12, 8n-12)
• RecallPic  (-4, 4, 12, 8n-12)
• Shade() (-4, 1, 6, 5n-9)

Perhaps you could add an optimization feature that counts the number of references to commands such as these? This would either include the routine inline or in a subroutine that is called multiple times depending upon which method is more size efficient based on the number of times the routine is called.