ahh i see. i knew about how posts in randomness work but didn't realize aboute introduce yourself. thanks!

i find it easiest to have this bookmarked/favorited.

hmm, i see what you mean. i don't think i will though, because then i need to store more information in the appvar. especially with 4-level grayscale. right now with monochrome, each tile is 8 bytes. with 4-level grayscale, each tile is 24 bytes (8 bytes for the black layer, 8 for the light gray layer and 8 for the dark gray layer). so even if you just wanted 15 tiles in a tileset, that's already 360 bytes that has to be stored in the appvar. although i like the feature idea, it'd be more memory efficient to keep the tiles monochrome, and let the programmer add in shades of gray.

Hey guys, so i've been messing around with the **  command in axe parser to help anyone who may want to figure out how to use it, or at least understand it primitively. so here are 90 minutes worth of observations i've made by testing dozens of axe programs, and then PM'd to quigibo to make sure they're correct observations, which was OK'd.

The ** Command

the documentation reads: "The signed multiplication is performed using the high byte as the integer part and the low byte as the decimal part returning a number in the same format."
here's a quick way to transfer a decimal number into something axe parser will understand. say you wanted to multiply 2.5 and 3.5. That's 8.75, you say, being superb at arithmetic. well, let's see how we can get axe to do it for us: first, break this down starting with the number 2 and one half. second, we take one half. since this is the first 8 bits, which holds the values 0-255, after that point it overflows into the next byte which holds the integer part two. this is better represented in binary:

  0    0    0     0     0      0    0     0    | 0     0     0     0     0    0    0    0
32768 16384 8192  4096  2048  1024  512    256 | 128   64    32    16    8    4    2    1  
                                                          
the line separates the high and low bytes. since we want to display one half in the lower byte to the right, we need one half of it. since the lower byte can represent 0-255, or 256 values, to get one half we'll have to divide 256 by two. so we end up with 128. then we need to represent 2 in the higher byte. you'll notice if we divide all the values of the higher byte by 256, they become identical to the lower byte. (32768/256=128, 16384/256=64, etc.) therefore, if we look at the lower byte, figure out what number we're trying to represent (in this case, it's two) and multiply it by 256, we'll get the higher-byte equivalent. which is 2 * 256 so 512. 512+128 = 640. great. we have one number, 2.5. now we need to multiply it by 3.5 do the same thing. what's .5 on our lower-byte scale? 128. and now we add that to 3 * 256, which is 768. total, that's 896. great. now try out this program:
.EXAMPLE
640->A  . 2 and a half
896->B  . 3 and a half
Disp A**B>Dec
What does it give? it gives 2240. look back at the commands list. it says it will give a number in the same format. therefore, to decode it, all you need to do is divide by 256. you'll notice you get 8.75. which is.. 3.5 * 2.5 (:
so you have a number x, and a number y. and you want to use this program without thinking in binary. here's the quick way, assuming x and y are in base 10 with decimal parts, just multiply them by 256 to get numbers that the ** command understands. 2.5 * 256 = 640, and 3.5 * 256 = 896.

Quigibo also gave me a quick BASIC program that will convert a number from -128 through 128 into 8.8 form (the form Axe reads in).
with the number in Ans:
If Ans<-128 or Ans>128:Then
Disp "OUT OF RANGE
Return
End
Ans+256(Ans<0
256iPart(Ans)+iPart(256fPart(Ans

and Quigibo's way to go from 8.8 back to decimal:
ClrHome
Input "8.8:",A
If A>=2^16
Then
Disp "OUT OF RANGE!"
Stop
End
If A>=2^15:Then
Disp -(2^16-A)/256    . this is a negative, not a minus sign
Else
Disp A/256
End

it looks great! i would suggest adding in scrolling and enhancing the graphics with the nspire's greater resolution. part of the difficulty of the puzzles were the fact you could only see so much of the screen at a time. wonderful job!

i modified the star to fit what i meant, i'm still debating on whether to use it or the clear one.
as for the explosion, that will work wonderful. thank you again, magic banana!

no, the axe parser contest entry is definitely not on hold. in fact, the contest entry is mostly done. so i thought i'd start something new (and : if this is entertaining enough i may just switch it out for my contest entry).
and yes, by 3-D i simply mean some shading and detail.

yeah i am. it's originally why i requested the sprites. mine isn't going to be very graphically detailed, in hopes that it'll run at a decent speed on 6 Mhz calculators.