Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: GreenFreak on July 03, 2011, 11:11:33 am
-
Hi! :D
I've another problem: I store my data in L1
I tried to store zeros in it:
Zeros(36)->{L1}but it only stores zero in {L1+0}, but not in {L1+1}, {L1+2}, ... , {L1+36} :-\
My walkaround is:
For(X,0,36)
0->{L1+X}
End
Question: is there a better solution??
Thanks for your help! ;)
-
Fill() should work. If I'm not mistaken, this would be the correct code:
Fill(0->{L1},36)
-
0->{L1}
Fill(L1,35)
That should work. It may be 36, though, I'm not to sure on that. I'm pretty sure it's 35, though.
Zeros(36) stores 36 bytes of zero in the program and then whatever you store it to is a pointer to that. So Zeros(36)->A would cause A to point to the first byte of that section of 36 zeros in your program.
-
Aaaahh!
Thanks for the very fast answer ;)
0->{L1}
Fill(L1,35)works fine ;)
-
I know I've been majorly ninja'd and you already have a working solution, but I'll post this anyways. I tried to go a lot more in depth of explaining how objects and data work in Axe, and how to properly manipulate them.
An important thing to remember about Axe is that the only data type it directly operates on is a 16-bit integer. In languages like TI-BASIC, something like :"HELLO" actually makes the last entry that string. However, in Axe, :"HELLO" will make the last entry a pointer to that string, which is stored inside of your program. This is because it cannot fit the whole string into its 16-bit data type, so it instead stores a 16-bit reference that tells where the real string is stored.
This means a few things. Most importantly for you, it means that Zeros(36)→{L₁} isn't actually storing the 36-byte object to {L₁}, it's storing a pointer to the object to {L₁}. And because there is no 2-byte r modifier after the closing brace, it's actually only storing the low byte (8 bits) of the pointer to {L₁}. But this is relatively unimportant, since either 8 or 16 bits of the pointer is not what you want.
Because using → to store objects doesn't cut it, we want to use some commands specific to blocks of data. If you wanted to put a block of data at L₁, you would first need to define the data in your program. Then, you can move that data from your program to L₁ using the Copy() command. This is found under MATH ► CPX ► 1. Here is how you would create 36 bytes of zeros in your program and then move them to L₁:
Zeros(36)→GDB0Z .Add 36 bytes of zeros to the program and store a pointer to it in GDB0Z
Copy(GDB0Z,L₁,36) .Copy 36 bytes of data starting at GDB0Z to L1
In most circumstances when you want to move data to an external location, the code above is the way to go. However, when you want to fill a location with one value, there's a slightly better way to go: the Fill() command. This is found under LIST ► OPS ► 4.You feed this a pointer and a size, and then it copies the byte pointed to ahead [size] times. Take note that because it copies the already existing byte [size] times, you'll be left with [size]+1 bytes. So as graphmastur posted, you would want to do this:
0→{L₁} .Give the fill a seed value of 0 to copy forwards
Fill(L₁,35) .Copy the value pointed to by L₁ (which is 0) ahead for 35 bytes
Finally, the optimized code! :evillaugh: It uses some tricks that I've picked up from extensive experience with Axe and is 2 bytes smaller and a tiny bit faster. You don't need to know these tricks, but after enough practice with Axe you may pick up such tricks on your own.
and 0→{L₁}ʳ .Give the fill a seed value of 0 to copy forwards
Fill(L₁,35) .Copy the value pointed to by L₁ (which is 0) ahead for 35 bytes
-
wow...
thats a text :D
Thanks a lot for the explanation! ;)
-
Can I store 8-bit data and 16-bit data both in {L1}?
My sprite x/y coordinates are stored as 8-bit numbers (because 16-bit aren't necessary for that^^) and I what to store the score in {L1+37}, but as a 16-bit number... ( {L1+37^r} )
is that possible?
I would say yes, or isn't that possible?
-
Can I store 8-bit data and 16-bit data both in {L1}?
My sprite x/y coordinates are stored as 8-bit numbers (because 16-bit aren't necessary for that^^) and I what to store the score in {L1+37}, but as a 16-bit number... ( {L1+37^r} )
is that possible?
I would say yes, or isn't that possible?
Yes, you store 8 bit data by doing 0->{L1}, 16 bit little endian by doing 0->{L1}r.
Also, please don't double post, just edit your first post to include the contents of your last post.
-
I can't help but wonder why storing to two bytes is smaller than storing to one byte (as in, 0→{L1}r being smaller than 0→{L1} ). Is it because it doesn't have to limit or something?
-
Well, I think it is due to having to only parse the expression that determines the place in memory to be pointed to, and then do a ld (place),hl since hl is the primary expression register for axe; I bet that for 8 bit storing it has to add an extra ld a,l and then do a ld (place),a.
-
and 0→{L₁}ʳ .Give the fill a seed value of 0 to copy forwards
Fill(L₁,35) .Copy the value pointed to by L₁ (which is 0) ahead for 35 bytes
What's and for? O.O
EDIT: Whoa, loading 0 to L ... brilliant.
Can I store 8-bit data and 16-bit data both in {L1}?
My sprite x/y coordinates are stored as 8-bit numbers (because 16-bit aren't necessary for that^^) and I what to store the score in {L1+37}, but as a 16-bit number... ( {L1+37^r} )
is that possible?
I would say yes, or isn't that possible?
Of course, data is what you make of it. Even when you store something in {L₁+37}ʳ as 16 bits you can take it out the lower eight bits with {L₁+37}. If the value is less than 256, {L₁+37}ʳ and {L₁+37} are the same thing (just slightly more optimized to do it the first way).
But if you have the room, you don't need to keep x- and y-values as 8 bits. If you're dealing with constant pointers (something like {L₁+2} as opposed to {B+L₁}), it's faster and smaller to just use the full 16-bits. That's because when Axe gets an 8-bit value it extends it to 16 bits anyway, because all math operations are done in 16 bits.
EDIT2: Ninja'd.
I can't help but wonder why storing to two bytes is smaller than storing to one byte (as in, 0→{L1}r being smaller than 0→{L1} ). Is it because it doesn't have to limit or something?
It's because when you load an 8-bit value from a constant pointer, Axe actually loads 16 bits, then masks off the higher eight. It's the most optimized way to load eight bits, but slower and more bloated than just loading the full sixteen bits.
Note that this doesn't apply to non-constant pointers. At all.
-
What does that mean?
EDIT: ok! thanks everyone! ;)
EDIT2: sorry... one last question :D should I store everything as 16-bit, because it's faster?
-
What does that mean?
Which (at whose explanation)?
-
I added in my game everywhere the ^r..
but I did a mistake and I don't know where..
My problem is, that I don't want to publish the code :-X
Is there something, that I could have done wrong? (except forgetting one ^r)
I need your help :P again ;D
-
Could we have a screenie so we can better tell what's going wrong with this?
Does it freeze, does something display at the wrong place, etc.
-
I don't know how to create a screenie...
It doesn't freeze, but it does strange things (the main sprite)
-
You make a screenie by making a rom (if you don't have one) with something like rom8x and using wabbitemu (backspace) but that's kind of a long process...
Anyway...
What's the line of code that displays the pic? Do you happen to be using any of the flipping or rotating commands?
-
Anyway...
What's the line of code that displays the pic? Do you happen to be using any of the flipping or rotating commands?
yeah.. I'm using one flipH( ...
Could that be the problem?! ???
I think it's the comparision or the "and".. because everything was working fine before...
-
Sometimes the flipping commands are broken...I'm assuming it's displaying an 8*8 bunch of random garbage instead of a sprite.
try this: put +8 at the end of the line where the flipH() is (but inside the parenthesis, like flipH(Pic1+8) ) and if that doesn't work, try -8
If that fixes it, it's just another temporary axe bug :P
-
no no...
The sprite is okay... but not how it moves...
I found one problem while trying to find the problem...
I think, I could post the code, of the menu, which don't work properly...
Wait a moment..
removed
It's just the menu...
It's the actual state...
And i must go now..
see you tomorrow..
Thanks for your help! ;)
-
I noticed that, if I leave out the ^r in the code above, everything works properly... But I don't know why...
I'm sorry, but I can't edit posts with my mobile.
-
16-bit variables take 2 bytes, so you shouldn't store two such variables 1 byte apart.
-
ok.. that makes sense ;D
ok it works, but I now have to fix that in my whole code :-/
Thank you for finding the issue ;)