Omnimaga

Calculator Community => TI Calculators => Axe => Topic started by: Deep Toaster on June 26, 2010, 12:41:43 am

Title: Braces
Post by: Deep Toaster on June 26, 2010, 12:41:43 am
I don't really understand Axe's indirection function yet. {L1} and {L1+12} compile to the same amount of memory, so I'm guessing the compiler substitutes the actual value of L1 or L1+12, but that's all I can figure out. Can anyone answer these questions for me?

1. Can I use a variable inside the braces (e.g. {L1+Z*4+12})?
2. If the answer to #1 is YES, would it be more optimized to do {Z*4+L1+12} instead?
3. Can I use braces within braces (e.g. {L1+{L1+12}+24})?
4. If the answer to #3 is YES, do the nested braces act as parentheses (i.e., it's read as {L1+({L1+12})+24})?

Thanks.

EDIT: Just realized that I should have titled this topic "Braces".
Title: Re: Brackets
Post by: nemo on June 26, 2010, 12:46:07 am
{} gets the byte the pointer points to.  0->{L1}:Disp {L1}>Dec. 0 would be displayed.
1. yes.
2. depends on your order of operations.
3. i think so, yes.
4. i think so, yes
Title: Re: Brackets
Post by: DJ Omnimaga on June 26, 2010, 12:47:22 am
I personally am more used to brackets for that stuff. I guess people might get the idea providing they check in which section the topic was posted in
Title: Re: Brackets
Post by: _player1537 on June 26, 2010, 12:50:15 am
1. yes, but its not the same size as {L1+12}
2. depends on order of operations, the example in one would do this: {((L1+Z)*4)+12}, the second one would do {((Z*4)+L1)+12}
3. yes
4. yes

also, {L1+1} is the exact same size as A, as in, these two examples will be the exact same size when compiled
{L1+1}+2->{L1+1}
A+2->A
Title: Re: Brackets
Post by: nemo on June 26, 2010, 12:52:35 am
wait.. i'm lost by what you guys mean by "size". all expressions within braces ({}) are one byte... and {}r is two bytes..
Title: Re: Brackets
Post by: _player1537 on June 26, 2010, 12:54:54 am
that's not what we mean by size, we mean size when compiled.  umm... not sure how to explain it...

like the larger the size, the larger the executable is
Title: Re: Brackets
Post by: nemo on June 26, 2010, 12:57:27 am
ohhh i got you. yeah i think it's because each paranthesis/brackets/braces counts as a certain amount of memory in the stack. so {L1} and {L1+12} take up the same amount of memory in the stack and therefore are equal in size.
Title: Re: Brackets
Post by: Deep Toaster on June 26, 2010, 12:59:46 am
2. depends on order of operations, the example in one would do this: {((L1+Z)*4)+12}, the second one would do

Order of operations ... forgot about that ... again :o That's why my program didn't work ... it has nothing to do with nested braces....

Thanks!
Title: Re: Brackets
Post by: _player1537 on June 26, 2010, 01:01:38 am
umm... not so much.  They take up the same size because... well, look at this
say L1 is equal to 1337
if you say {L1} you are really saying {1337}
so, if you say {L1+1} you are really saying {1338}
that said, the compiler auto detects that you are saying {1338} and changes it to that.  That is why {L1} and {L1+1} are the same size.
Title: Re: Brackets
Post by: Quigibo on June 26, 2010, 01:02:40 am
It sounds like you have the right idea.  Since L1-L6 are just numbers, it makes sense for the compiler to add/subtract/multiply/divide etc. to create a single number BEFORE parsing so that the program doesn't have to do it during runtime.  However, if you have any variables or non-constants then the compiler can not make this optimization and the size will increase.

Your 2 examples {L1+Z*4+12} and {Z*4+L1+12} would return different values as some people have said due to strict left-to-right order of operations.  However, I assume you are asking about the difference between {L1+(Z*4)+12} and {Z*4+L1+12} and in that case, YES, the second one is more optimized since L1 and 12 are combined to form a single number that will get added to the variable part.

You can use as many braces inside of braces as the stack can handle and yes, they act like parenthesis when you use them that way.  You can read from expressions with nested braces and store to them.  But of course, the less parenthesis you need, the more optimized it is.  If its possible try to put all that stuff at the front. {{L1+12}+L1+24} is more optimized than {L1+{L1+12}+24} for the reason above in addition to the fewer acting "parenthesis".
Title: Re: Brackets
Post by: Deep Toaster on June 26, 2010, 01:03:50 am
Oh, so Axe detects whether or not there's external data within the brackets. That's pretty smart.
Title: Re: Brackets
Post by: DJ Omnimaga on June 26, 2010, 01:06:28 am
Yup. It can be rather useful for some complicated RPGs. In TI-BASIC, I often did stuff like L3(A+L3(Z)), for example. If I remember, ROL2 required a lot of those

Keep in mind it can eventually make your code hard to read, though, especially if you decide to put a project on hold for a while.
Title: Re: Brackets
Post by: Deep Toaster on June 26, 2010, 01:13:06 am
That's exactly what's happening now. I'm afraid that in two months, my code will be completely illegible to myself (I've used statements containing 16 or more L1's.
Title: Re: Brackets
Post by: Quigibo on June 26, 2010, 01:15:21 am
That's what comments are for ;D  You should see Runer's Sprite Editor source, more than half of the size of the program was indents and comments.  That's another paradigm that BASIC programmers are too used to, commenting in the code doesn't affect the final executable at all since they are all ignored when compiling.  In BASIC however, its seen as wasteful since it becomes part of the program.
Title: Re: Brackets
Post by: DJ Omnimaga on June 26, 2010, 01:18:43 am
True, altough when you got several KB of data, you need to tone down on the comments a lot D:

I guess one advantage of TI-BASIC programming is that we learn to code without commenting ;D but in more complex languages, this could be a bad practice x.x (like ASM)
Title: Re: Brackets
Post by: Deep Toaster on June 26, 2010, 01:25:25 am
True, I could use comments ... too late, anyway. I'm not used to commenting my code, like most people who started with BASIC.
Title: Re: Brackets
Post by: jnesselr on June 26, 2010, 11:24:49 am
The only reason I somestimes commentmy code is because of java.  The pointers are the hardest part about axe. If you understand them, and understand the math, you are practically an axe expert.
Title: Re: Brackets
Post by: DJ Omnimaga on June 26, 2010, 01:06:16 pm
I personally found stuff like dealing with storing stuff to half-bytes and dealing with negative values in comparisons to be harder. Pointers were hard to get at first, but not as much it seems. Learning to deal with negative values is easier, but dealing with them is rather tricky, especially when you do a program with physics and collision detection.
Title: Re: Brackets
Post by: nemo on June 26, 2010, 05:05:30 pm
i think negative values are easy to understand, just tough to implement. also, getting sin cos and tan are difficult. i still don't understand bitmap(). but i don't use it either.
Title: Re: Brackets
Post by: LordConiupiter on June 26, 2010, 05:56:59 pm
I really like the bitmap() command. I haven't used it jet, but that's because I'm also programming in c#, which has a little priority right now for me for this week. next week I'll start to code intensively in Axe. But the bitmap command is just like the sprite command, except the first two bytes: they are the height and width. After them comes the data in bits, so a little smiley of 9 x 9 would look like this:

10011001
000111000
011000110
100101001
101010101
100000001
101000101
100111001
011000110
000111000
in bytes, which is in hex: 09091C31A535580D1672C61C0

I thougt. please correct me if I'm wrong!
Title: Re: Brackets
Post by: nemo on June 26, 2010, 05:59:10 pm
i think that's wrong, but i'm not completely sure. it's 9x9 so wouldn't 0909 be the first two bytes in the hex?
Title: Re: Brackets
Post by: LordConiupiter on June 26, 2010, 06:00:36 pm
yes, ure right, I'll correct that!
Title: Re: Braces
Post by: Quigibo on June 26, 2010, 06:16:14 pm
Also, you're going to have to pad to the nearest byte.  Which means that your sprite will look something like this:

0909
Row1: xxxxxxxx x0000000
Row2: xxxxxxxx x0000000
...
Row9: xxxxxxxx x0000000
So in total, the sprite will be 20 bytes.  2 for the size parameters and 18 for the sprite itself.
Title: Re: Braces
Post by: nemo on June 26, 2010, 06:30:07 pm
000110010
000111000
011000110
100101001
101010101
100000001
101000101
100111001
011000110
000111000

is [090919001C0063009480AA808080A2809C8063001C00]
i just tried it on calc and it works.
Title: Re: Braces
Post by: DJ Omnimaga on June 26, 2010, 11:37:41 pm
So does the width have to be a multiple of 8 like most sprite routines?
Title: Re: Braces
Post by: nemo on June 27, 2010, 01:07:11 am
no the width does not have to be specified as a multiple of eight, but when converting the sprite to hex you have to pretend that the width is a multiple of 8. so if you had a 9x9 black square:
111111111
111111111
111111111
111111111
111111111
111111111
111111111
111111111
111111111
you would specify the dimensions as 0909 in the first two bytes. however, the sprite you convert to hex would look like so:
1111111110000000
1111111110000000
1111111110000000
1111111110000000
1111111110000000
1111111110000000
1111111110000000
1111111110000000
1111111110000000
because you have to pad to the nearest byte, or multiple of eight.
the hex for a 9x9 square would thus be:
[0909FF80FF80FF80FF80FF80FF80FF80FF80FF80]
Title: Re: Braces
Post by: DJ Omnimaga on June 27, 2010, 01:09:14 am
Aaah ok, so it's kinda like when you make sprites with xLIB, then. To draw a 14x8 sprite, you need to draw a 16x8 one with the last two columns of pixels being turned OFF.
Title: Re: Braces
Post by: Deep Toaster on June 27, 2010, 07:50:03 pm
Do they have to be turned off, or are they simply ignored?
Title: Re: Braces
Post by: Quigibo on June 27, 2010, 07:51:18 pm
I'm almost certain that they're ignored, but I haven't actually tried that yet.
Title: Re: Braces
Post by: FinaleTI on June 27, 2010, 07:53:39 pm
They have to be off in your sprite, since xLib accepts sprite width in bytes.
The sprite would only be drawn to be 14 pixels wide, but you would have to space it 2 pixels away from the next sprite, then when you called real(1, you would give it a sprite width of 2 bytes. This would draw a 16 pixel wide sprite, but since 2 of the columns were white, or the pixels were turned off, it would appear to be a 14x8 sprite.
Title: Re: Braces
Post by: Deep Toaster on June 27, 2010, 08:24:09 pm
What about in Axe? It wouldn't matter if they were on or off, right?

And just curious: How does Axe draw bitmaps, anyway? Does it plot it bit by bit?
Title: Re: Braces
Post by: Runer112 on June 28, 2010, 01:02:33 am
The Bitmap() command uses a TI-OS bcall, it's not an actual Axe routine.
Title: Re: Braces
Post by: Builderboy on June 28, 2010, 01:22:08 am
Is there any documentation to how much slower it runs compared to the regular sprite commands?
Title: Re: Braces
Post by: calc84maniac on June 28, 2010, 01:23:23 am
You can always For( loop and see for yourself ;D
Title: Re: Braces
Post by: Builderboy on June 28, 2010, 01:25:21 am
Haha thats true :D I wish axe had timer support :P Then i could calculate the times for everything and write them all down for extreme optimizations >:D
Title: Re: Braces
Post by: Quigibo on June 28, 2010, 02:03:02 am
You can do that with the interrupt feature coming soon.  You just have to be aware that some commands disable interrupts for their duration which could throw off the measurements.  Specifically, any command which draws directly to the LCD most likely has them disabled.  Although if you were running tests with Bitmap(), you would have both of them draw to the buffer to make it even anyway.