Hi!  

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!  

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.

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! 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


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?

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?

Code: (Optimized data filling method) [Select]

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?

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?

Which (at whose explanation)?

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.