Exactly.  But if someone writes a library, odds are you aren't going to use every single command in that library.  And its a huge hassle to keep track of which ones you use and which ones you don't need.  And what if you delete one but it turns out you need it later on?  In addition, its more organized to have the programs and subroutines in separate files.  Also, it would be a real annoyance to have to do a [Rcl] with someone's code into your main program.  And yet another thing!  You might have several source files that use the same libraries so it could potentially save space and make source files even smaller.

Hmmmm Using the program name might be good, although it would be cool to have some sort of Method overwriting like in higher languages that way if you are just using external subs to make cleaner code it wont be adding all this extra memory into the source

oh and what about the little E for accessing bits?  Like:

AE2 would access the 2nd bit of A, and you could store the same way?  It makes a bit of sense, since E is powers of 10 in Basic, and Powers of 2 in Axe

Question, in the future, will there be a command to draw white lines?

(I guess an alternative for games where the entire gameplay screen is black could be to XOR the graph buffer, draw the lines then XOR it again, though )

mhmm invert might be cool too, actually

Cool ^^

And good thing I just checked the first post, I was gonna ask if circles/squares were for next release (or close)

One question, though:  what do you mean by binary support? Do you mean individual bit manipulation?

I'm also glad you're adding tilemap absorbing support. It will make it MUCH easier to insert tiles in a game.

lol. Well we could do this in BASIC, kinda

I would just totally disregard the last row of tiles. It's gonna cause more problems than anything else anyway since so few ppl will use xLIB to store pics (which allows the usage of the 64th row). When trying to display a sprite from last row using a pic that only has 63 rows stored results in garbage at the bottom of it.

I have a suggestion: could Horizontal be extended to allow scrolling 1 byte at a time instead of just 1 bit? I would think such code would be more optimized than 8 single-scrolls.