I just want to be clear about how sprite rotation and flipping will work because I don't want people thinking its something that its not.  The commands take 1 argument; the pointer to the 8x8 sprite and the return argument is a pointer to an 8 byte buffer in an unused safe ram area outside of L₁-L₆.  This area holds a copy of the "new" sprite after the transformation.

Pt-On(X,Y,FlipH(Pic1))
I was originally thinking of having a second argument allowing you to specify what area of ram to use as the temporary buffer, but then I realized that it would be easier to use, smaller faster code, and take up no extra visible memory with the single argument instead.  The only problem though is that you cannot  nest these routines together, maybe with an exception of the flip horizontal.  Like for instance RotCC(FlipV(Str1)) will fail because the input and output buffer are the same.  Therefore, I might still have the second argument, but it would be optional.

Also, the subroutines themselves that do the flipping are around 2 sprites in size and it costs an extra 3 bytes each time you call them and is obviously slower than just using a regular pointer so you'd have to be really desperate for space with massive amounts of sprites to even consider using this.

You can always try these: http://ourl.ca/35290  A lot of good sprites in there.

Let me explain the new masked sprite routine because its really cool.  The first layer is the sprite and the second layer is the mask.  The way it works is that anything drawn on the first layer is going to be black or gray and any bit that is neither in the sprite layer nor the mask layer becomes transparent.  So the codes are 11 for black, 10 for gray, 01 for white, and 00 for transparent.  Think of it like a controlled Pt-Off() that also draws gray since you can control which pixels to see through when drawing.  The routine is slower than the normal sprite drawing but much faster than trying to draw to both layers individually.  Also, due to the choice of color codes, you can use this for monochrome masking as well with the first layer being the sprite you want to draw and the second layer is black in the areas you want to draw over.  However keep in mind that the routine still draws to both buffers so make sure you aren't storing anything there first.  Here is an example

Layer1:
    ████████
  ██        ██
██            ██
██    ████    ██
██    ████    ██
██            ██
  ██        ██
    ████████

Layer2:
    ████████
  ████████████
████████████████
██████    ██████
██████    ██████
████████████████
  ████████████
    ████████

Result:
░░░░████████░░░░
░░██        ██░░
██            ██
██    ████    ██
██    ████    ██
██            ██
░░██        ██░░
░░░░████████░░░░

The crosshatched color means those pixels don't change when drawing the sprite (transparent).

Also, please let me know if you are still getting errors that you were getting before.  I tried to fix as much as I could but since I still can't figure out the problem, that means I'm just guessing so I need your help to see if anything actually got fixed.

You don't need to be a judge to see the entries.  Everyone will post their entries when the contest expires.  And no, no one who has an entry in the contest can be a judge because that's completely biased.

Alright!  Alright!  I'll include it in 0.4.1 since you're helping me debug that other problem and since I need things to add and this is extremely easy.  The syntax will be Pt-On(X,Y,Pic1)→BUFF.  I can also use a similar technique with ClrDraw and DrawInv, but I'm not sure if I'll have time for that right now.

Yeah, I'm looking into it.  I'm working on the masked sprite routine right now so at least I can add something new to 0.4.1 instead of just a bunch of bug fixes.  Hopefully I will find and fix them all so I can update late tonight or tomorrow.

Lists and other floating point stuff is really complicated and I don't know it well myself.  You'll have to refer to the TI-Developer's guide to see how floats are formatted.  The only thing I know is that they're 9 bytes each and the last 7 bytes are the number itself in BCD.  Its way too complicated I think to work with them now in Axe, it will be easier when I get floating point conversions working.  For now, just stick with programs, appvars, pics, and strings is my advice.

Also, Runer112 I can't seem to simulate that problem and I don't see anything obvious in the parser that would cause that.  Would you mind emailing me an example that I can debug?

Each one is half way right, you just have to combine the 2.

"vPBWMAP1"->Str0
Getcalc(Str0,16)->P
If P
 For(A,0,15)
  1->{P+A}
 End
End