Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: dinosteven on July 21, 2012, 03:38:27 pm
-
I've got a list defined in one of my games that stores coordinates. Like this:
Data(10,11,10,21,10,31,10,41,20,11,20,21,20,31
etc. .... 40,31,40,41)→GDB1
The coordinates are for parts of a map. So far I've only got 1, but I want to make more and store them in appvars. And I really don't understand appvars - at all. :'(
How do I define it with it's length? The list has 32 coordinates, meaning 64 numbers in it. What length is that? Can I do this:
GetCalc("appvAPPVAR",64)
to define it or is that completely wrong?
Once that's done, how do I store the list into it?
And more. Because when I checked the External Vars Tutorial, it just talks about numbers, not lists.
Essentially, can I either be told that it's not possible, or be told a step-by-step-super-detailed tutorial on how to do it?
-
It looks like you've pretty much got it, you just need to copy the data into the appvar once its created, like this:
Copy(GDB1,GetCalc("appvAPPVAR",64),64)
-
Well, when you create an appvar, you want to direct a pointer to it, like GetCalc("appvAPPVAR",64)→A. That will make it so that pointer A points to the appvar. Then you'd want to copy all the data from your GDB into the appvar. Copy(GDB1,A,64). That will copy 64 bytes from GDB1 into A. (A points to the appvar, so really you are copying it into the appvar) Also hi and welcome here. :)
EDIT: :ninja:
-
Thanks!
But shouldn't the size be larger? I don't think you can store a number like 41 in 1 bit. Or byte? EDIT: Byte
Don't you need 8 bits/2 bytes for numbers up to 256?
-
When you do GetCalc("appvAPPVAR",50), you are creating an appvar with 50 bytes, not bits. You can use the formula (2^#OfBits)-1 to see the range of numbers that a certain amount of bits can hold. Since a byte is 8 bits, it can hold 2^8 -1 = 255 numbers. :) The reason we have the -1 is because we start counting at zero, not 1, so the appvar can hold 256 different numbers, but one of those numbers is 0, so we have the range 0-255. Does that make sense?
-
Yeah, that makes sense. For some reason, I thought a byte was 4 bits.
So 1 byte is enough to hold all #s up to 255, right?
-
All whole numbers, yes. (You can't store something like 2.5 into 1 byte)
-
I tried it, but got an "ERR:MEMORY" even though I still have 9434 bytes of RAM left.
appvAPPVAR now has size 143.
???
-
Was this while compiling or while running?
-
While running.
-
hm, could you post your code? You may have done something wrong with the other part of the program.
-
:.A
:"appvAPPVAR"→Str1
:GetCalc(Str1,64)→A
:Data(10,11,10,21,10,31,10,41,20,11,20,21,20,31,20,41,30,11,30,21,30,31,30,41,40,11,40,21,40,31,40,41,50,11,50,21,50,31,50,41,60,11,60,21,60,31,60,41,70,11,70,21,70,31,70,41,80,11,80,21,80,31,80,41)→GDB1
:Copy(GDB1,A,64)
I've got Axe v 1.0.5
And I compiled it for NoShell, running it with BrandonW's Noshell.
But even though it says "ERR:MEMORY", appvAPPVAR appears in the Memory menu with size 79 now. What size is it for you?
-
It compiles/runs just fine for me... What version of Axe are you using/what shell are you running it from?
-
The same size. It still has 64 bytes of data in it, but the extra 15 are for the VAT entry and the name. :)
-
So it worked, and my calc's just trolling me by giving me the "ERR:MEMORY". Weird, but it works!
EDIT: No, it didn't. To access it in my game, I stored it to a variable S, since I couldn't use GDB1. After modifying my game to fit S, the map completely disappeared, except for the upper left corner. I assume that everything was changed to '0', and that it was mapping at 0,0
What to do?
-
Why did everything turn into a 0? It's probably because of the line
:Copy(GDB1,A,64)
But how can I fix this?
-
i'm not into axe, but it sound like S is only an integer (1 byte, 8 bits) zo that it can only hold one value at a time, and not an array of values.
by copying everything to S, you overflow it, and corrupt the data after the memory address of S
(that's what i think it is)
-
Before you do anything else, I'd recommend you clear your RAM then try again. Sounds like you've corrupted your RAM somewhere along the way (better get used to it ;D), so it'd be better to start again on a clean slate.
Your code works fine for me. Why not update Axe to the latest version (http://ourl.ca/1463/228625/) first? There are always lots of bugfixes between versions.
EDIT: Can you post your new code? I don't understand what you mean by replacing GDB1 with S.
-
In Axe 1.0.0, a new optimization system was added: a peephole optimizer. Unfortunately, with it came quite a few bugs in its initial and few following releases of Axe. Axe 1.0.5 is one version which has a few bugs, one of which affects any program that contains a Copy() command for which the third argument is a constant (in this case, 64).
The best way to fix this would be to upgrade to the latest version of Axe: 1.1.2 (http://ourl.ca/4060/282749). Alternatively, you can fix this temporarily by disabling the peephole optimizer when compiling by pressing ZOOM to compile your program from Axe's list of source programs to compile instead of pressing ENTER.
-
Yes! After an update to Axe v 1.1.2, RAM clearing, compiling, and running, the error message disappeared.
Thanks for all the help!
-
You know, I've been wondering why so many new members seem to start at Axe 1.0.5... Seems like that's the version at ticalc.org: http://www.ticalc.org/archives/files/fileinfo/428/42813.html
Someone needs to fix that D:
-
I would, but they rejected The Mighty Jill Off :P
-
What does that have to do with updating Axe? And I thought only the original author could update their programs?