So surprise surprise, I added a switch statement last minute, it took me under an hour to have it fully functional.  Its also probably the only new feature this version that needs a tiny bit of explaining.

So basically, Z-Test() is a command to built what's called a "jump-table", or if you prefer, a "goto-table".  It basically creates an array of places to "jump" to and then jumps to the Nth item in that list.  That's about it.  The reason this is useful is that otherwise, you have to do something like:

:If A=0:
:<code>
:ElseIf A=1:
:<code>
:ElseIf A=2:
:...and so on...
So when you have a lot of consecutive comparisons, it saves a lot of space in the program.  But the best part is the speed savings.  Normally, you would have to make N comparisons (or log(N) if you're smart ) in order to figure out which of N pieces of code to execute.  This method however, makes a single comparison!  So no matter how large your jump table is, it always takes the same amount of time to get to the code you want to run.

All of this fun is overhead though, and I will say you should only switch over to a Z-Test() if you have 4 or more cases to check against, otherwise it could be larger and slower.

If you want this to be a call table instead of a jump table, simply put it in a subroutine and call it:

:MyTbl(A)
:
:Lbl MyTbl
:  Z-Test(r1,A,B,C,...)
:  <handle errors>
The error handling is for when the number you're testing is outside the range of the table.  This isn't necessarily an error if you're going to use that  to your advantage, but its a good sanity check to have if you're expecting the number to be in the range of your labels.  If you are absolutely positively sure your number is in this range (like you just read a nibble which is always in the 0-15 range and you have 16 labels) then you don't need any code there.

Also as I was typing this, I just realized I forgot to show an error when you try to use this in a For(expr) loop.  DO NOT USE Z-TEST HERE!  You will get a memory leak and eventually a ram clear.

Oh wait, you're right.  You just have to change the sprite beforehand to map transparent to 0,0 on the sprite+mask and white to 0,1 which is easy because you don't have to do that at runtime, just import your sprites in this format.

Quote from: BlakPilar on December 16, 2011, 07:57:43 pm

Is there any way to "re-declare" an array? For example, doing "Data(0,0,0)->GDB0" at one point, then doing "Data(6,3,5)->GDB0" later? Or, after the array has been declared, would I need to do something like "6->{GDB0+0}:3->{GDB0+1}:5->{GDB0+2}" to change values?

If your program doesn't writeback, then this is okay. It would be much easier to store values to a free RAM space, then alter them there.

Alternatively, you can store data to a variable instead of a constant and then your can re-assign pointers all you want.

I had a quick question about editing programs in archive.  I assume that what it does is make a copy in RAM and then copy it back if changes were made.  But what happens if there's not enough room in RAM to hold the copy?  Are other programs temporarily archived to make space or will it not let you edit the program?

You mentioned you had an entry point in zStart so Axe errors could be shown in archived programs, but the routine sounds like it could be small enough to just include it in the app since I still have a lot of space.  But I don't know how you're implementing it so maybe I'm wrong or there are other advantages to calling it through zStart that I'm forgetting.

Bounds checking is not built into the routine anyway.  In fact, it uses modular checking meaning that pxl-Test(300,10) will test the same pixel as pxl-Test(44,10).  Technically, behavior outside the screen is considered undefined and could change in future versions.  But due to the way it optimizes, I'm 99% sure it will stay the same as it is now.

I can't elaborate much because I don't know the exact specifications for it yet since its still in planning stages.  But basically a table is a data structure with objects.  There will be a special iterator loop structure, probably something similar in syntax to "For([A])".  You can add, remove, access, and modify only the current object from the iteration.  Order cannot matter during the iteration because the positions might change around during these operations.  You can access the Nth data byte of your custom objects, but you cannot access the Nth object because this would be unstable during the above operations and it requires a multiply.

This is all speculation so far.  I might also have to introduce the concept of "binders" to make this nestable.

Drawing 9 sprites in a for loop is about 20% faster than using the bitmap command, so only slightly.  However, this is the first version of that command, so there are likely to be optimizations in the future.

Well, I need to find another way for 24x24s

Putting them into a pic and uploading to calc distorts it
Jacobly converted one of my big sprites but I don't want to bother him with another
Or if I write down the binary for the 576 pixels then use a hex converter, but 576 seems like a lot

You know... its not that hard to write a converter program yourself in Axe.  Say you had 8 24x24 sprites drawn to a pic on your calculator side by side.  Let's convert the Nth picture to a 148 digit hex string in the OS Str1:

:.CONVERT
:.This number can be 0-7 to distinguish the pictures
:0→N
:
:.Read from Pic1 and create the string variable Str1
:Return!If GetCalc("Pic1")→P
:Return!If GetCalc("Str1",148)→S
:
:.Add the size bytes to the bitmap
:Copy(_E1818>Hex,S,4)
:S+4→S
:
:.Use N to find the first byte of the picture
:N^4*3+(N/4*288)+P→P
:
:.Iterate through all the rows of the sprite
:For(24)
:  .Copy the 6 hex digits of 1 row to the string
:  Copy({P}^rr>Hex,S,4)
:  Copy({P+2}^rr>Hex,S+4,2)
:
:  .Increment the position in the picture and the string
:  S+6→S
:  P+12→P
:End