I actually submitted it as a tutorial and it's in the tutorial section currently and in the tutorial section, it had code tags, just when I copied it over to this thread, they didn't copy. And no problem Qwerty, I'll flesh out some concepts.

That's pretty much why I'm still using Axe 0.5.3

NOTE:For this tutorial, I'm using Axe 1.0.2. Check the Commands.htm of your current version of Axe to make sure the commands are supported

So. There's this thing that you can use in Axe. It's called a Buffer, and it's basically a chunk of memory, and appvar, or some other form of an Array. By definition, it is 768 bytes in size. By using the appropriate commands in Axe Parser, buffers can be displayed on the screen of your calculator to output graphics in monochrome, 3, or 4 level grayscale.


Using the Default Buffers

In Axe, there is a location in saferam or freeram or whatever you want to call it, called L6. Check the commands list - L6 is 768 bytes in size! Perfect for a buffer. L6 (and also L3, for grayscale) are known as the Default Buffers.

Whenever you use a command such as Pt-On(X,Y,Pic1) or Pxl-On(44,36) or Drawinv or something like that, you are drawing to the Default Buffer.

Line(0,0,10,10) doesn't 'draw a Line' per se, it sets and edits data in L6, the default buffer (for more on how computers draw lines, you might want to read this). Then, when you call DispGraph, it looks at the data in L6, and displays it.

Check this out:


Repeat getkey(15)

.This command fills L6 with a bunch of zeros, 768 to be exact
ClrDraw

.Now let's edit the very first byte in L6

255->{L6}

.We set the first byte to 255, or FF in hexadecimal
.255 / 0xFF translates out to the following binary:
.11111111 (eight ones)
.So when we call DispGraph, it will display eight black pixels in the first byte of the buffer
.In other words, the top left corner

DispGraph

End


Try it! If you understand how sprites work, you can see that Pt-On just copies your sprite hex data into a buffer! Experiment with this -- you could even write your own Pt-On subroutine, completely in Axe! (not that it would be extremely useful, just fun to make)

Grayscale

So how does grayscale work in Axe? This is where the Back-Buffer comes in. L3 is referred to as the Back Buffer, or Secondary Buffer.

When you call commands such as Pt-On(X,Y,Pic1)^r, it does the exact same thing as without the little r, but it draws to the Back-Buffer instead of the Default Buffer. And when you call DispGraph^r, it displays all the data in L3 as gray, and all the data in L6 as black. For more on how grayscale works, I recommend reading this

And for four-level grayscale, L3 is displayed as light gray, L6 is used for dark gray, where they overlap is displayed as black, and where they are both blank is white. So to display four blocks right next to each other, progressively getting lighter, do this:


prgmEXAMPLE

.EXPROG
.Example program is an example.

[FFFFFFFFFFFFFFFF]->Pic1
.^this is just a solid block

Repeat getkey(15)

ClrDraw
ClrDraw[sup]r[/sup]

Pt-On(0,0,Pic1)
Pt-On(8,0,Pic1)
Pt-On(0,0,Pic1)[sup]r[/sup]
Pt-On(16,0,Pic1)[sup]r[/sup]

DispGraph[sup]rr[/sup]

End



Using Alternate Buffers

If you understand that Line(0,0,10,10) isn't technically drawing a line on the screen it's really just editing and setting data in a Buffer, then using Alternate Buffers should not be hard to understand. All that's different is a slight syntax change.

To initialize a buffer (let's call it GDB1, just for fun), we do the following:

Zeros(768)->GDB1

This creates an array in memory that is 768 bytes large and fills it with zeros. To clear the buffer, do the following:

ClrDraw(GDB1)

and other than that, it's really easy.

I'll just show you some code examples, instead of explaining in words.

Monochrome Buffers:

prgmMOVE
.MVMT A simple movement demo (with buffers)

0->X
0->Y

Zeros(768)->GDB1

[FFFFFFFFFFFFFFFF]->Pic1

Repeat getkey(15)

.(this input system does not react to walls)
getkey(3)+X-(getkey(2))->X
getkey(1)+Y-(getkey(4))->Y

ClrDraw(GDB1)

Pt-On(X,Y,Pic1,GDB1)

Dispgraph(GDB1)

End


The same code, with 3 level gray:


prgmMOVE
.MVMT A simple movement demo (with buffers)

0->X
0->Y

Zeros(768)->GDB1
Zeros(768)->GDB2

[FF000000000000FF]->Pic1
[00FFFFFFFFFFFF00]->Pic2

Repeat getkey(15)

.(this input system does not react to walls)
getkey(3)+X-(getkey(2))->X
getkey(1)+Y-(getkey(4))->Y

ClrDraw(GDB1)
ClrDraw(GDB2)

Pt-On(X,Y,Pic1,GDB1)
Pt-On(X,Y,Pic2,GDB2)

Dispgraph(GDB1,GDB2)

End


I'm not 100% sure on the syntax here (I use 0.5.3  ) but you get the idea.


Voila! You have successfully set up and used an alternate buffer system! Let me know if I was unclear on anything.

Is he staff on Cemetech?

I emailed him about this and he said

Quote

Nope, totally me.

Wait, he's proud of it? Yeah, an apology is a loooooong ways down the road.

Watch out for code sections like this:

If GetCalc(L1)->A
Disp "AN APPVAR EXISTS WITH THAT NAME"
Return
End

Because what it will do is display AN APPVAR EXISTS WITH THAT NAME really fast and then exit the program without you ever knowing. You can change that by adding this:


If GetCalc(L1)->A
Disp "AN APPVAR EXISTS WITH THAT NAME"
Repeat getkey(15)
End
Return
End


So it waits until they press clear, then returns.

Can you explain any more? Also, it's a pain, but it might be helpful to write your own input function. I think I have one somewhere I can dig up...

welcome and stuff. Like ztrumpet, I program exclusively for ti-83/84+(se) calcs except I only do Axe, not TI-Basic. And as for current projects, check the sig