Woo, Ultraviolet Voodoo! Oh, mnemonics... Also: Ruler, we learned integration in the second half of AB, but then didn't learn things like integration by parts till BC.  So maybe you're talking about college courses, but AP-wise, integration definitely does NOT necessarily mean you are in BC.  In fact, if you didn't learn to integrate at all, you'd be pretty much screwed on the AP test... =P

Make sure you are clearing the back buffer between each usage (ClrDraw^r), otherwise you will get 2 pixel tall blocks left behind as it inverts it.  (Also: shouldnt the first be solid and the second inverted?)

As for displaying both buffers, im not sure exactly what you are asking.  Are you trying to mask them of something?  if you want to just draw them both together, doing DispGraph:DispGraph(L₃) will draw them one on top of the other.  if you just want to be able to pxl-test the back buffer though, you dont actually have to draw it, just use pxl-Test()^r.  Maybe i'm missing something, what are you actually trying to do?

A+B+C+D+E+F+G+H+I+J->K (21 bytes) compiles to 71 bytes.  Pt-On(A,B,C) (7 bytes) compiles to 146 bytes.  Some routines are bigger than others when compiled, using a couple larger routines can make the compiled program huge, even if your source seems small, while using a ton of smaller routines can keep the size down.

To be fair, it is a topic titled "A"... But whatever.

Yep, that's Drak for you... haha.  But actually, that's not even most of the downvotes... Wonder what topic it actually is that has him at 11...

Okay, because you're coming from Basic, I'm going to make sure you understand a concept then.  When you do something like [01]->A, you are making the compiler put the number 01 somewhere at the end of your program, then giving you a POINTER to that, or a number that tells you where that number is stored.  The "variable" doesn't actually hold the data itself, it just tells you where to go to find the data.  So storing the picture is exactly the same as storing a sprite except for two things, the length of the actual data stored, and the format of the data stored.  If you import a picture, (And yes, it is whatever it is when you compile it, because it literally copies the picture data into the code at the end of your program) it will be 768 (i think, somewhere around there =P) bytes, while sprites are 8.  Also, if you tried to just use an imported picture with the sprite command, it would be not what you would expect, as it would read the first 8 bytes of data (each 8 pixels is stored in a single byte, one pixel per bit) which would be the first 64 pixels in the first row, and write it as an 8x8 sprite.  You can use [picvar^r] to import it as a spritemap, which is probably what you want, which will actually make sure the data is imported in the correct format for being used with the Pt- commands.  Just remember if you use that, each sprite is 8 bytes long.  Back to pointers, remember how they only tell you where the data is, not what it is?  You can do math with pointers too, for some very useful results. Say you do [010203]->A, then ask it what {A} (The value stored at A) is.  What would it tell you? 01, because A points to the start of that data!  Now what if you did {A+1}, what would it give you?  Now it's 02 instead, because that is the data in the byte after 01!  {A+2}? 03!  So now think of when you import that picture into your program as sprites.  It will import them in by rows, each row having 12 bytes (96/8=12) and there will be 8 rows (64/8=8).  There aren't any actual "rows" of course, because remember, the data is all layed out linearly, like [row1][row2][etc.], but knowing everything we know, it's easy to find a specific sprite!  If Pic1 is a pointer to our data (Also, the pic vars really arent variables, but that's a whole 'nother story!) we could pass Pic1 to a Pt- routine to have it draw the first sprite for us.  Cool, but what about the other ones?  So, remembering that each sprite is 8 bytes long, we can simply give it an 8 byte offset to the data to have it start reading there instead! If we give a Pt- routine Pic1+8 instead, it will draw the second sprite!  In fact, we can generalize this, and so every sprite can be accessed at {S-1*8+Pic1} (Don't forget Axe's fun order of operations; all left to right!) where S is the sprite number.  Okay, so that should probably tide you over for a bit, ask if you need more ;P

Sorry if this was all a bit gratuitous or pedestrian for you, you said complete nub, so I assumed very minimal knowledge =P  Hope this helps!

Okay, so since this is in the Axe subforum, I'm going to assume you are talking about Axe even though the way you discuss the concepts it sounds like Basic.  Yes you can include pictures, try adding "[Pic1]->GDB1" and it will import all the data from Pic1 into the program when you compile it, as long as Pic1 exists, then GDB1 will point to it.  I don't know what "overwriting variables" you talking about, but if you wanted to clarify, maybe I can help.  And about sprites... I don't know how you are trying to define sprites, but typically you write something like "[001122334455667788]->Pic1001", I don't know where you are seeing this funky u (which i would guess you are talking about [2ND]+[7])  Hope this helps! =)

EDIT: =( Okay, why did the necro warning not yell at me D=  So where did you mean to post it then?
EDIT2: So it is axe, you just put it in the wrong axe subforum? Confusion! =P Haha, w/e

Haha, if you wrote WorldEdit...  But a fly plugin?  What would that actually do, considering that flying is already a thing? =P