This is just a general warning because I didn't realize how badly I screwed up the text command in the past.

I completely rewrote all of the Text( commands.  They now have the exact same syntax as Output( meaning you can display more than one thing per use like Text(2,3,"Hello"," World:",A>Dec) for instance.  It also means you can define just the coordinates Text(2,3) or a compressed coordinate Text(3*256+2).  The only problem is that I had to redefine the existing "draw text here" command because that was formatted the same way, but it was a relatively new command so hopefully no one has gotten too comfortable with it.  To replace it, I will add a new command called "Text " with a space and it will act exactly like "Disp " but for small text.  So to reiterate;

Disp     <=> Text
Output() <=> Text()

They can be used interchangeably and have exactly the same syntax.

The thing I was talking about when I said the old text routines were screwed up is that they were very inefficient and I had 2 sets of routines, one for text anywhere and one for text at the current pen location.  Also, the actual coding of the text parsing was quite messy.  I combined everything to a single, smaller routine and organized the code and commands to make it more readable.  I was using ztrumpet's spider game as an example and it shrunk by almost 100 bytes and text wasn't even a part of that game.

Hopefully I will get one more major optimization before the next release because I had a revelation yesterday.  I got to thinking, what's the difference between data and subroutines?  There isn't any!  So I can mix in all the subroutines with the data as if it was data without having to make a 3rd pass which can save a lot of bytes in the executable.  The only side effect to this is that if you are defining 2 blocks of data that are split by a command that uses a subroutine, then the 2 pieces of data are no longer consecutive in memory.  I doubt anyone will have a problem with this though because its always good practice to define consecutive data together without interruptions and I've never seen anyone do it wrong in their code.

Anyway, this will be the first Axe release since the 0.2.x versions that features major optimizations that will reduce the size of just about ALL programs.

Well the first one for sure I will add since it can be used for monochrome masking as well, but I'm still not so sure about the other ones since the 2nd one can be written in Axe and the 3rd one seems like a bad idea.  They won't be a priority right now or in a near release.

I guess I'll keep the single line coordinate method for Output() and Text() just in case.  Also, there is no reason to have a separate 8.8 routine for sin because you can do basically the same thing with this: sin(A/256)*2 The only advantage of a separate routine is to use a little bit of the decimal part to get slightly higher accuracy, but its not going to be that much better.

In other news, I've got archive reading completed and I'm rewriting the tutorial about it because there is a lot of new information to learn about, but lucky no new commands.

Oh yeah, I'm phasing out the single argument syntax of Output() because the compiler will automatically optimize that for you if the first 2 arguments are constants.  I haven't implemented the optimization yet but apparently I must have accidentally cut it out of 0.3.3, it was supposed to be a 0.4.0 change, my bad.

Awesome game though!  This is very enjoyable to play.  Can't believe you made it all in 24 hours

Great tutorial Nemo!  

Here it is in as a full TI-BASIC program.
EDIT: Also, I uploaded a converter to go the other way.

There actually is a way to decompress RLE on the fly for gigantic maps.  It's not as efficient as the original RLE, but it allows random access (well random-er at least) to the data in the structure.  Its a little complicated, but here is what I am thinking:

First of all, for this to be worth it, each row has to save more than 2 bytes on average, or 4 tiles if you're using this as an alternative to half byte encoding.  The way this works, is you only compress each row or column with RLE instead of the entire data.  You then keep a list of pointers that each point to the individual rows of the data.  The rows themselves are small compared to the whole thing so they can be decompressed on the fly.

Here are some phony numbers:
Maps size: 100x100
Tiles: 10,000
Half Byte compression size: 5,000 bytes
Each row given RLE compression: 3,000 bytes
List of pointers: 200 bytes
Combined total size: 3,200 bytes

Average bytes in a row: 30
Average worst case number of operations to get to intended data: 30
^ This is definitely fast enough for on the fly decompression.

This is valid syntax when defined in this order:

[RLE row 1]->Str0
[RLE row 2]->Str1
[RLE row 3]->Str2
...
[RLE row 100]->Str99
{Str0^r,Str1^r,...,Str99^r}->GDB1


Unfortunately, that list already uses 100 out of the 150 names you're allowed so it might be better to keep track of the cumulative size and use Str0+Offset so that you're only using one name.

Its not really something high on my priority list to fix and its not really a bug.  The problem is that it requires a lot of extra code to figure out where to start printing from the top of the screen and its much simpler to go just start with the same line.  I think the DCS instant goto does this as well if I'm not mistaken.  The only easy way to have the scrolling end up looking like it does in TI-BASIC is well... to actually scroll, but I think the convenience of instant goto is more favorable than bottom line error highlighting.

@Darl That would be a huge inefficiency, but you did remind me of the fix extender idea that I forgot about.  You can reset all the fix modes at once by chaining them together like "Fix 0246" for instance to set modes 0,2,4, and 6 in a single line of code for convenience.  I might have time to add that next release.

Also another feature I will be adding is "Temporary Pointers" which are similar to static pointers.  For times when you only need to use some data exactly once, you will be allowed to do things like Pt-On(X,Y,[0123456789ABCDEF]) to both create the data in memory and return the pointer to that data in a single line.  Its just as efficient as regular static pointers but has the advantage of not taking up any extra pointer names so you are less limited by the 150 name limit.  This also will apply to Strings, Data(), and the Zeros() commands which can also be used to return temporary pointers.

No, they disable them fine on their own, you only need to re-enable them after the command.  Adding that extra FnOn is only an extra byte so not a big deal really.