Ok so my code is probably very bad because even though Ive been doing this for a while, I do know much. Please correct me if im wrong or doing this wrong. Thanks!


Right now Im handling the X and Y values of a couple sprites in a GDB (they hold data like an array right?)
I then retrieve this data and edit it store it then later retrieve it and draw a sprite with it.
I have absolutely no problems when drawing one sprite, but when drawing 2 sprites with different X and Y data one of them will edit the first two digits of the sprite's hex code. Like when I move it right the hex code counts up by one and changes the sprite to match that.

Is this supposed to happen?

Oh ok, sorry abut that.
Here it's probably not perfect but It should do what I want to do right? (Unless I did something wrong.)

.test
1->X
1->Y

Fix 5

[01]->GDB1
[01]->GDB2

1->{GDB1}
1->{GDB2}
5->{GDB1+1}
1->{GDB2+1}

Repeat getKey(15)

If getKey(1)
Y+1->Y
End

If getKey(2)
X-1->X
End

If getKey(3)
X+1->X
End

If getKey(4)
Y-1->Y
End

X->{GDB1}
Y->{GDB2}
Y->{GDB1+1}
X->{GDB2+1}

ClrDraw

{GDB1}->A
{GDB2}->B
Pt-On(A/2,B/2,[FFFFFFFFFFFFFFFF])

{GDB1+1}->A
{GDB2+1}->B
Pt-On(A/2,B/2,[FFFFFFFFFFFFFFFF])
DispGraph
End

I see the problem in the code:

GDBs are pointers

Pointers must be the same size as the number of bytes that you want to modify/be in it because if you overextend the writing, you write to the next bytes, or in this case, the first byte of GDB2.

The fix:

[0000]->GDB1
[0000]->GDB2


EDIT: 'd

Using custom names for this might make your life easier, since your data is really just 1-byte variables and there's an easy way to access 1-byte variables: Nameʳ. Here's how it would look converted to use them, also with some other minor optimizations:

.TEST
1→X→Y

Fix 5

L₄→°X1+1→°Y1+1→°X2+1→°Y2
.Initialization of vars above not necessary, will be set in first loop iteration

ClrDraw

While 1

If getKey(1)
Y+1→Y
End

If getKey(2)
X-1→X
End

If getKey(3)
X+1→X
End

If getKey(4)
Y-1→Y
End

X→X1ʳ→Y2ʳ
Y→Y1ʳ→X2ʳ

Pt-On(X1ʳ/2,Y1ʳ/2,[FFFFFFFFFFFFFFFF])
Pt-On(X2ʳ/2,Y2ʳ/2,[FFFFFFFFFFFFFFFF])
DispGraphClrDraw  .for speeds!

EndIf getKey(15)


Also, it makes me cringe a bit inside when people refer to arbitrary data in Axe as "GDB's". The GDBX tokens are just a particular set of many equally allowable symbols in named pointers to any kind of data! You can call a pointer to any type of data whatever you want, whether it be GDB1, Str1XY, Pic789, °Stuff12345, or whatever.

i came here expecting a discussion about graphical debuggers for axe (although, that might not be the worst of ideas, and it wouldn't be all that hard to make as an axiom either...)


EDIT:

Is there anyway to change the size of the array after you make it like.

Code: [Select]

[01020405]->GDB1
[02030302]
[04050302]


Is there any way to change the size of this after I make it?

no, pointers set at compile time are static.

Well, "size of an array" doesn't mean anything in Axe.

When you define [060203]->GDB1, what you are doing is
[06]->GDB1
[02]->GDB1+1
[03]->GDB1+2
And since you don't define anything at GDB1+3, the program sets what it wants there. That doesn't mean you can't read what's in GDB1+3, there is a value there, it will just be a bit unpredictable. That also means that if you write in GDB1+3, your program (or your calc) will have a problem some time, but that doesn't mean you can't write there.

But as shmibs said, what you create at compile time is quite restricting. What you can do is copying your "array" in L1 (for example) and then you'll be able to "add" or "remove" bytes from your array (as long as you don't have more than 768 bytes).

I recommend that you use the free RAM areas. L1 for example, is 768 bytes. You can use it as you like.
Another solution if you need more space is to dynamically allocate user RAM with GetCalc.

[DATA -> L1

and just use L1 to call it.