with the pt-Mask(x,y,sprite) command, you can take a masked spritee and draw it on the screen so that certain parts are white, certain parts are transparent.

How a masked sprite works:  there are two parts; the normal sprite and it's back buffer sprite.  the front sprite defines what is black and what is white; then the back buffer decides what is filled white, and what is transparent.  a black dot on the front buffer is always black (in monochrome mode, no grayscale) if a dot is blank in the front buffer sprite, then if there s a pixel behind it that is black it will show up filled with the pt-mask() command.

a sprite data like this (in binary -- easier to visualize)

11000000
00001100

if the first byte is front buffer and the second is back buffer, then the first two pixels drawn will be black, the next two transparent, the next two filled white, he last two transparent.

if you still don't understand, look in the axe parser documentation for a better idea.

Actually the Pt-Mask() command (accessible as the Plot1() token) has different logic, as it was designed for 3-level grayscale masked sprites. Each sprite would have 2 8-byte buffers of data. The bits in each byte in the buffers would correspond to a pixel color as follows:

            Second buffer
            1       0   
First   1   Black   Gray
Buffer  0   White   Transparent

Cool, I now have access to the forums again.

Anyways, the routines I had were a pair of deadly accurate sine and cosine routines. And by deadly accurate I mean percent errors in the hundredths or thousandths of a percent. Whereas the built-in routines accept integer inputs and give signed 8-bit integer outputs, these routines accept 8.8 fixed point inputs and give signed 8.8 fixed point outputs. That means it accepts inputs with 256 times the precision, and gives outputs with 256 times the precision as well!


The first file (TRIGLIB.8xp) is the library you probably want to use in most situations, as it's slower than the second library but over 300 bytes smaller. This is because, whereas the first library uses a 128-byte LUT for one quarter of the period and makes use of the symmetry of the sine wave to do extra calculations for values anywhere in the period, the second uses a 512-byte LUT for the full period.


EDIT: Oh right, I forgot to say: use sub(SIN,value) and sub(COS,value) to use them. And to properly insert a library like this into your program, put a line saying prgmTRIGLIB in the subroutine section of your code.

L₁. In that area of safe RAM (the 54 bytes before where L₁ points) is where the built-in 27 variables reside, too.

EDIT: Mega ninja'd.

.S=Score (or any other number to align right)
.T=Temp
.X=x position of text
.Y=y position of text
91→X
S→T
While T/10→T
X-4→X
End
Text(Y,X,S▸Dec)

A 12-frame rotation for the captured ship sprite made by SirCmpwn.



EDIT: By the way, perhaps these may be of use:

Galaga for arcade

Galaga for Gameboy Advance

EDIT 2: I was just watching a video on youtube of Galaga, and I noticed something... The "captured fighter" never rotates, it only rotates when it's being captured or being released, in which case it's colored like the normal fighter. Should I modify my animation to instead rotate SirCmpwn's other ship sprite? Or do you just want to flip his definitions?

What about pictures, strings, and lists?  Those have a _E00-_E09 byte built into their name and could incorrectly be read as a valid NL.  I'm not saying its impossible to do, I'm saying its impossible to do and have it work correctly in every possible situation.  I'm sure someone could have some kind of hacked variable or something that would break your system.

Well I know pictures are stored in the other section of the VAT, and although I'm not sure about strings, I believe they are also stored in the other section. However, lists are in the section we're concerned with, which is the point of the {P+2} check. If the name is a two-byte token for L₁-L₆ and {P} is detected as the byte in the token less than or equal to 8 (the byte of the name found earlier in RAM), then {P+2} will always be NL, which can never be greater than or equal to 0x40. If {P} is the NL byte, though, then {P+2} will be DAH, which is always greater than or equal to 0x40, so this will be positively identified.

And yes, if someone has hacked, invalid VAT entries, that could potentially break my system, but there's really no reason that should ever happen. Unless they were mucking around with the VAT themself, in which case it's their fault anyways if VAT reading code fails.


EDIT: Speaking of hacked VAT entries, I just remembered that DCS makes programs called "%FLDn" to handle its folders, where n can be any byte, so could be less than or equal to 8. However, this would be avoided in the initial skip over the first byte, which I originally had only in case it was a formula byte for a list. Now it looks like the skip performs double duty