There is a really amazing algorithm for finding the area of ANY closed shape, not just triangles, if you know the coordinates of all the verticies.  For instance, take any pentagon with verticies (X1,Y1) through (X5,Y5).  You can find the area by listing the pairs clockwise and making the first point appear at the end too:

X1 Y1
X2 Y2
X3 Y3
X4 Y4
X5 Y5
X1 Y1

Then you multiply diagonally down on each side and find the sums of those 2 columns:

       X1 Y1
Y1*X2 / X2 Y2 \ X1*Y2
Y2*X3 / X3 Y3 \ X2*Y3
Y3*X4 / X4 Y4 \ X3*Y4
Y4*X5 / X5 Y5 \ X4*Y5
Y5*X1 / X1 Y1 \ X5*Y1
______         ______
SumLeft        SumRight

The area of the shape is simply the difference of these 2 sums divided by 2:  |SumLeft - SumRight|/2

It even works if the lines pass through each other or the shape has holes in it.

EDIT: Oops, forgot the /2 hehe

That only works for static pointers becasue those don't take up any memory.  I only have a limited number of variables because I want to leave users with enough free ram to play around with.  If you need more variables, you can always use these ram locations manually: {L1+10}^r for instance will act exactly the same as a regular variable (make that 10 any constant you want as long as it fits in ram)

The app length bug was fixed in 0.4.8

Also, this is fairly random and unreproducible, but sometimes I will run into random BAD SYMBOL errors while compiling (usually an archived program).

That bug was supposed to be fixed in 0.4.7  Have you had that problem in the later versions?

Sometimes when I unarchive it the compile goes smoothly and error free. More rarely, it will throw another BAD SYMBOL, and upon pressing prgm to goto, the entire program after a certain point seems to be corrupted (lots of random tokens, etc.) I remember that the goto-prgm thing used to be unstable with large programs. What constitutes a large program: one with lots of library files whose compiled code comes out to 16kb count? (The main program is 5 kb and the largest library is 3kb...and the corruption will usually happen to any of them, not just the main program)

This is a problem I still can't figure out.  The OS must be handling large files differently than small ones for some reason because I pass control to the OS before the actual scroll.  If anyone knows more information about the BASIC editor context variables, I could definitely use your help!

Oops, you're right, I forgot to update that.  Fixed.

If the subroutine is at the end of your code, it can't kick those calls out of the table until it finally encounters the label.  Putting the subroutines at the start of the program can fix that if you use them often enough.  Just make the first line of code a goto to skip over your subroutines.

Or better yet, put them in an include library so they don't crowd as much.

Axe Parser
Delta 0.4.8

---

Just a little patch before the stable release.

New Features:

• A few more optimizations
• Multi-line comments!
• Axiom SDK updated and probably finalized

Changed:

• Fixed 3 Level grayscale routine hopefully
• Fixed reading protected programs from archive
• Fixed application size field
• Line drawing off-screen does not draw the line.
• A few other minor bug fixes.

No... but you can add the zero yourself with [00] when you aren't using the store.  Also, the store should be on the first line of text, not the last one.