Omnimaga

Calculator Community => TI Calculators => Axe => Topic started by: Masinini on December 06, 2010, 10:22:50 pm

Title: New to Axe.
Post by: Masinini on December 06, 2010, 10:22:50 pm
Okay, so I loosely understand most of the syntax, with some exceptions. I figure that experimenting will help me learn more.

What I am confused with is Pics and such. I read the read me's and stuff included, and don't get the syntax.
I don't get the pointers, and how I will be able to use them.

Furthermore, I am confused as to what the back buffer and what the buffer is, and how they are different.
Title: Re: New to Axe.
Post by: jnesselr on December 06, 2010, 10:35:40 pm
Yo, welcome to omnimaga. If you make an introduction topic, we can give you peanuts. ;-)

Now then, I'm glad you choose axe for your development needs.  Pointers are both the most complex and yet the most beneficial part of any programming language.  First, let me explain pointers. A "pointer" is a variable that points to something else. See, that wasn't that hard.  In the example of pics, it is fairly easy. (Everything after ; is a comment)
Code: [Select]
[pic1]->Pic2 ; Absorb the 756 bytes that make up the pic1 variable on the calc into the program.  Pic2 is now the pointer to the first byte of the data for pic1 inside the program.  Pic2 does not mean Picture 2 as in the calculator.
det(12) ; Adds 12 more bytes (all zeros) in order to make the total length 768, as that is the byte-size of the calculator screen.
for(A,0,767) ; A goes from 0 to 767.
{Pic2+A}->{L6+A} ; Since Pic2 is pointing to the first byte of the picture, {Pic2} gets the actual first byte. So, {Pic2+A} gets the first byte, plus some offset. So, {Pic2+1} gets the second byte. This is why we went from 0 to 767 and not 1 to 768.
end ; End to the for loop
DispGraph ; Display the buffer on the screen.
If you had replaced L6 with L3 above, it would have been to the back buffer.  Now then, imagine 3 different things. A screen, and two buffers. One is what is being displayed. One is the buffer, and as soon as dispgraph is run, the buffer becomes the screen.  The backbuffer is essentially another buffer, just used in case you need two buffers.

Note that the above code should work, but isn't tested. Don't have a calc to really test it.
Title: Re: New to Axe.
Post by: Masinini on December 06, 2010, 11:34:05 pm
So basically, it points to the byte where the pic is being stored?
Title: Re: New to Axe.
Post by: Builderboy on December 06, 2010, 11:38:06 pm
So basically, it points to the byte where the pic is being stored?

You have it precisely right :)
Title: Re: New to Axe.
Post by: Masinini on December 06, 2010, 11:39:43 pm
Okay. So if I wanted to display a pic. I would have to draw it, store it, and then recall it based on the bytes?
Title: Re: New to Axe.
Post by: Builderboy on December 06, 2010, 11:51:57 pm
If you wanted to display a pic, the best way would be to draw it on the graph screen normally (outside of Axe), and then store it to a TiOS picture file.  Then inside the program you would do something like this:

Code: [Select]
[Pic1]->Str1
the [Pic1] tells axe that we want the data inside the TiOS Picture variable 1.  We then store it into the pointer Str1 (note that Str1 is just a name, its not a string).  To Display it on the screen we could do one of 2 things.

Code: [Select]
Str1->DispGraph
Or

Code: [Select]
Copy(Str1,L6,768
Dispgraph

The first routine tells Axe to take the data dirrectly at Str1 and put it on the screen.  The second routine uses a copy function to take 768 bytes (the same size of the screen) and put it at L6 (which is the location of the Main Buffer).  All dispGraph does is take the data at L6 and put it onto the screen.  Most commands deal directly with L6, and not the screen itself, since it is faster.
Title: Re: New to Axe.
Post by: DJ Omnimaga on December 07, 2010, 12:37:30 am
By the way welcome on the forums and happy birthday, noticing the board index event notifications and your profile. :P
Title: Re: New to Axe.
Post by: Michael_Lee on December 07, 2010, 01:34:30 am
Well, the main time I use pointers is when I want a list of some sort.
While Axe may have variables built in, it doesn't exactly come with a 'list' variable like TI-Basic does.

Therefore, pointers are most commonly used (by me, at least) for when I want a list.

I access a portion of free ram by using L1, which when compiled, returns an address to the start of a portion of free ram (710 bytes in a row that isn't used by anybody but YOU).

So if I do {L1+5}, that would return the 5th byte (counting up from zero) after wherever L1 is.  So I could do
Code: [Select]
For(A,0,5)
    A+9->{L1+A}
End
And that would be sort of like a list with six elements
('L1+0' is an address, and the value stored at that address would be nine; 'L1+1' is an address, and the value stored at that location is 10, etc.)

Pointers can also be used for things like linked lists (http://en.wikipedia.org/wiki/Linked_list), although I've never used them, nor do I really know what I would use them for.
Title: Re: New to Axe.
Post by: Masinini on December 09, 2010, 03:53:31 pm
So the buffer and back buffer are extra screens. And when you draw stuff to them, it doesn't appear on the screen until you use dispgraph^r?


And I was reading a guide by sircpm, and it said when I see something like

[0a3ff0457f-pic1, its using hexadecimal? And is that making pic1 point somewhere, or is storing bytes to the area that pic1 already points to?
Title: Re: New to Axe.
Post by: ztrumpet on December 09, 2010, 04:12:55 pm
So the buffer and back buffer are extra screens. And when you draw stuff to them, it doesn't appear on the screen until you use dispgraph^r?
Not quite.  They're two seperate buffers.  Normally you only want to display the front one, so you'd use Dispgraph (r and rr are for Greyscale).  Normally the Back Buffer is for storing stuff you don't want changed while you change something on the front buffer.  If you want to ever display the back buffer, you can just do L3->DispGraph. :)

And I was reading a guide by sircpm, and it said when I see something like

[0a3ff0457f-pic1, its using hexadecimal? And is that making pic1 point somewhere, or is storing bytes to the area that pic1 already points to?
It creates a new 4 bite (8 nibble) section of data at the bottom of your code.  So it would look like this:
Code: [Select]
<code here>
Return (Don't actually put this in your code - It's automatically added at the bottom of each program.)
[0A3FF0457F]

I hope this helped, and welcome here! ;D
Title: Re: New to Axe.
Post by: AngelFish on December 09, 2010, 04:18:32 pm
So the buffer and back buffer are extra screens. And when you draw stuff to them, it doesn't appear on the screen until you use dispgraph^r?
Not quite.  They're two seperate buffers.  Normally you only want to display the front one, so you'd use Dispgraph (r and rr are for Greyscale).  Normally the Back Buffer is for storing stuff you don't want changed while you change something on the front buffer.

I prefer to think of them as two different screens that the calculator rapidly switches between when using greyscale.
Title: Re: New to Axe.
Post by: Masinini on December 09, 2010, 04:20:50 pm
...I just feel more confused now. XD

So the back buffer holds a background perchance, that you don't want changed, while the regular buffer holds a character that changes as you press buttons?

And I am still conffuzled by the whole 8-bit nibble thing. How is that useful when creating graphics, for example.
Title: Re: New to Axe.
Post by: AngelFish on December 09, 2010, 04:24:47 pm
Let's say you used the Sprite command Pt-on(X,Y,[0123456789ABCDEF]. This draws the sprite data to an 8x8 section in L6. If you were to do Pt-on(X,Y,[0123456789ABCDEF])r instead, the data would be drawn to the same location, but this time in L3. When you use the Dispgraph command, it takes all of the data in L6 and it draws it to the screen (the LCD RAM if you want to be technical). When you do L3->Dispgraph though, it takes the data in L3 and it writes that to the screen instead.

The 8 bit thing is just a function of how the calculator's memory was designed. It turns out that the calculator was built so that 8 bits fit into something known as a "byte." Since the calculator automatically addresses everything in terms of bytes rather than individual bits, it makes it easier to use 8 bits instead of another system.

PS: Nibbles are half of a byte or four bits. I'd recommend staying away from them until you get a little more familiar with the language.
Title: Re: New to Axe.
Post by: Masinini on December 09, 2010, 04:27:04 pm
That helps. A lot.

So in An example program from the Axe download, called starship demo or something.

I was messing around and the creator used hexadecimal to draw graphics. How.
Title: Re: New to Axe.
Post by: AngelFish on December 09, 2010, 04:35:09 pm
Hexadecimal is just a short way to encode binary. For example, let's say that you wanted a sprite that looked like this:

Code: [Select]
0110
1001
1001
0110

where the 1's are pixels that are turned on, you would be able to turn that image into the hex sequence 6996, where every row is a hex number. With Axe, sprites are 8x8, so you need four such images like this:

Code: [Select]
01100110
10011001
10011001
01100110
01100110
10011001
10011001
01100110

Notice how I just tiled the image four times. So, reading the hex across would be 66 99 99 66 66 99 99 66, where every pair of numbers is a full byte and a row.
Title: Re: New to Axe.
Post by: Masinini on December 09, 2010, 04:53:00 pm
Thanks! Now I get it. I had understood the use of binary in assembly a while ago, but didn't make the connection. So when he stores a hexidecimal list to a picture, and then uses X,Y,Pic1 later, it turns on the specific points at x'y to match the hexidecimal?

And did you do the hexidecimal in your head? I'm not sure how the rows each equal, 66 per say.
Title: Re: New to Axe.
Post by: AngelFish on December 09, 2010, 04:57:30 pm
Windows 7 includes a calculator that can convert Binary to Hex  :P

If you don't have that, then Wikipedia (http://en.wikipedia.org/wiki/Hexadecimal) has a Binary-Hex conversion chart.

To convert the binary to Hex, all I did was take each sequence of four bits and replace it with the corresponding Hex number. For example, the top row was 0110 0110. Looking at the chart, this converts to the Hex numbers 6 and 6, which I grouped together to form a byte.

So, 66 99 99 66 66 99 99 66 is the image.

Also, yes, using Pt-on OR's each of the points already in the buffer. If either the bit in the picture or the bit in the buffer are on, the screen will turn that pixel on when Dispgraph is used. Pt-Change XOR's the Sprite with the buffer.
Title: Re: New to Axe.
Post by: yunhua98 on December 09, 2010, 05:28:09 pm
You can use Hexpic, included in Axe Parser Tools folder, and draw 8x8 sprites, then it will convert the sprite to Hex.  or alternativly you can use ione of the many sprite editors made by our community members.  ;)
Title: Re: New to Axe.
Post by: Masinini on December 09, 2010, 05:53:17 pm
Thanks for your help all. All I need to do now is experiment and practice, making sure I get the codes down.
Title: Re: New to Axe.
Post by: Munchor on December 09, 2010, 06:30:18 pm
Thanks for your help all. All I need to do now is experiment and practice, making sure I get the codes down.

Check the open source programs in Omnimaga, that's how I learnt.

Also, Axe's examples are pretty good to learn.
Title: Re: New to Axe.
Post by: Masinini on December 09, 2010, 06:51:11 pm
New Question.

So, If I wanted to draw an X, I could make an 8x8 sprite like

01000010
01000010
00100100
00011000
00100100
01000010
01000010
00000000   But say i wanted to make a box that could only fit in an 24x6 spreite sized box. Would I have to use 3 8x8 sprites and just leave off part?

That X in hexadecimal is 42, 42, 24, 18, 24, 42, 42, 00
Title: Re: New to Axe.
Post by: squidgetx on December 09, 2010, 08:14:25 pm
Yeah, you could either use 3 8x8 sprites or the bitmap command. But the bitmap command is slow and rather confusing, so you're probably better off with 3 8x8 sprites that have 2 blank columns at the end
Title: Re: New to Axe.
Post by: AngelFish on December 09, 2010, 08:17:28 pm
New Question.

So, If I wanted to draw an X, I could make an 8x8 sprite like

01000010
01000010
00100100
00011000
00100100
01000010
01000010
00000000   But say i wanted to make a box that could only fit in an 24x6 spreite sized box. Would I have to use 3 8x8 sprites and just leave off part?

That X in hexadecimal is 42, 42, 24, 18, 24, 42, 42, 00

You can't leave off part. You have to designate the full data for Pt-On, I believe. You can use the Bitmap command by doing

Code: [Select]
Data(rows,columns)->Pic1
[Hex]
...
Bitmap(X,Y,Pic1

 The problem is that Bitmap takes approximately 15 times longer than Pt-on.
Title: Re: New to Axe.
Post by: Masinini on December 09, 2010, 08:19:22 pm
When I say leave off part, i mean just make the Hexidecimal code for that area 00.
Title: Re: New to Axe.
Post by: AngelFish on December 09, 2010, 08:20:08 pm
Then it'll work. Setting blank bytes to 00 simply doesn't draw them.
Title: Re: New to Axe.
Post by: Deep Toaster on December 09, 2010, 08:20:23 pm
^ What Qwerty said. Plus, storing six bits (pixels) per row would get really nasty to deal with because all of it's in bytes of 8.
Title: Re: New to Axe.
Post by: DJ Omnimaga on December 09, 2010, 08:23:19 pm
Didn't Bitmap use the Overwrite logic, though? (erasing everything behind)
Title: Re: New to Axe.
Post by: AngelFish on December 09, 2010, 08:24:47 pm
It does, but then again so does Pt-Off
Title: Re: New to Axe.
Post by: DJ Omnimaga on December 10, 2010, 02:27:25 am
Ok, because you said the following:
Then it'll work. Setting blank bytes to 00 simply doesn't draw them.
It should actually draw them, right? (in white)
Title: Re: New to Axe.
Post by: AngelFish on December 10, 2010, 02:28:40 am
No, 00 with the Pt-On command is transparent because the routine uses OR logic to map the pixels.
Title: Re: New to Axe.
Post by: DJ Omnimaga on December 10, 2010, 02:37:50 am
I thought the quote above was directed at Bitmap, not Pt-on? ???
Title: Re: New to Axe.
Post by: Builderboy on December 10, 2010, 02:39:55 am
No, 00 with the Pt-On command is transparent because the routine uses OR logic to map the pixels.

I think we are talking about bitmaps here

EDIT: yeah :P
Title: Re: New to Axe.
Post by: AngelFish on December 10, 2010, 02:42:12 am
Oh, then 00 does overwrite the bytes.