Omnimaga
Calculator Community => Major Community Projects => The Axe Parser Project => Topic started by: BlakPilar on July 18, 2011, 11:40:39 pm
-
I'm writing my first major Axe program and I noticed that the speed isn't much faster than BASIC. Is this because my TI-84+ is too old? :(
-
I'm writing my first major Axe program and I noticed that the speed isn't much faster than BASIC. Is this because my TI-84+ is too old? :(
No it must be the way you are formatting your code. A 84+ runs at ~15MHz no matter how old it is.
Maybe post your code somewhere and people can help you optimize it to make it run faster.
-
I am actually having a similar problem. What is the command to set 15mhz mode, is it FULL?
-
Yes it is. Like eeems said, your code will only be fast if it's coded well.
-
Nevermind! I did it, thanks anyway guys! I was storing getKey to a variable, which I'm guessing is a no-no in Axe. Maybe that's your problem too, mrmprog?
-
Nevermind! I did it, thanks anyway guys! I was storing getKey to a variable, which I'm guessing is a no-no in Axe. Maybe that's your problem too, mrmprog?
This really shouldn't be a problem. In fact, I'd go as far as saying it's not the problem. getKey->K is perfectly legitimate code.
-
Well if you're doing something like (I'm only saying this because I did it before, because it's perfectly acceptable in TI-BASIC)
If getKey=54
Goto FCK
End
If getKey=9
Goto WTF
End
and so on it can massively slow down.
-
Hmm... Well, here was my original code:
Repeat getKey(15)
getKey->K
X-(K=...)+(K=...)->X
Y-(K=...)+(K=...)->Y
That ran almost at the same speed as BASIC. My new code is the same, but I don't store getKey to K and instead of (K=...), I use (getKey(...)). Now it runs extremely fast. ???
-
Hmm... Well, here was my original code:
Repeat getKey(15)
getKey->K
X-(K=...)+(K=...)->X
Y-(K=...)+(K=...)->Y
That ran almost at the same speed as BASIC. My new code is the same, but I don't store getKey to K and instead of (K=...), I use (getKey(...)). Now it runs extremely fast. ???
Then your issue was probably key debouncing. Direct input [getKey(xx)] will fire every frame. getKey->K and testing K will fire every few frames because of the way that input routine works...if I recall correctly. Don't quote me on that, tho.
Regardless, getKey->K and testing K shouldn't be itself particularly slower than getKey(K). That is to say, the instructions shouldn't take much longer.
-
I'm writing my first major Axe program and I noticed that the speed isn't much faster than BASIC. Is this because my TI-84+ is too old? :(
No it must be the way you are formatting your code. A 84+ runs at ~15MHz no matter how old it is.
Maybe
Er, no. The EOS kindly automatically reduces the CPU speed to 6 MHz before running assembly programs and applications so that any timing code runs the same. You're expected to explicitly set the CPU speed if you want to run at full speed. However, BASIC programs automatically run in fast mode.
-
Hmm... Well, here was my original code:
Repeat getKey(15)
getKey->K
X-(K=...)+(K=...)->X
Y-(K=...)+(K=...)->Y
That ran almost at the same speed as BASIC. My new code is the same, but I don't store getKey to K and instead of (K=...), I use (getKey(...)). Now it runs extremely fast. ???
Then your issue was probably key debouncing. Direct input [getKey(xx)] will fire every frame. getKey->K and testing K will fire every few frames because of the way that input routine works...if I recall correctly. Don't quote me on that, tho.
Regardless, getKey->K and testing K shouldn't be itself particularly slower than getKey(K). That is to say, the instructions shouldn't take much longer.
Wait... Could it possibly be different or help to know that I'm using sprites, not just a single pixel?
-
Hmm... Well, here was my original code:
Repeat getKey(15)
getKey->K
X-(K=...)+(K=...)->X
Y-(K=...)+(K=...)->Y
That ran almost at the same speed as BASIC. My new code is the same, but I don't store getKey to K and instead of (K=...), I use (getKey(...)). Now it runs extremely fast. ???
Then your issue was probably key debouncing. Direct input [getKey(xx)] will fire every frame. getKey->K and testing K will fire every few frames because of the way that input routine works...if I recall correctly. Don't quote me on that, tho.
Regardless, getKey->K and testing K shouldn't be itself particularly slower than getKey(K). That is to say, the instructions shouldn't take much longer.
Wait... Could it possibly be different or help to know that I'm using sprites, not just a single pixel?
Maybe I should clarify. Direct input goes off every frame. Testing getKey->K does not. This means that, if you're updating the position of ANYTHING, be it sprite, character or pixel, that thing will move every few frames if you're using getKey->K, and every frame if you're using direct input. I'm about 80% sure I know what I'm talking about. :P
-
Just as a tip, you don't have to store getkey to a var unless you want to save it. Something like X+(getKey(3))-(getKey(2))→X is valid as well ;)
inb4 someone pops up with some hyper-optimized routine... :P
-
Maybe I should clarify. Direct input goes off every frame. Testing getKey->K does not. This means that, if you're updating the position of ANYTHING, be it sprite, character or pixel, that thing will move every few frames if you're using getKey->K, and every frame if you're using direct input. I'm about 80% sure I know what I'm talking about. :P
I knew what you meant and I wasn't doubting your knowledge of Axe :P I was just asking lol.
-
I wasn't doubting your knowledge of Axe :P
Again, don't take my word for it. Test it yourself. 'S always the best way to learn.
(Especially when I doubt my knowledge of Axe)
-
Ahh, I have tested it myself! I made a copy and tested it with and without getKey->K. The one with ran slower.
-
Ahh, I have tested it myself! I made a copy and tested it with and without getKey->K. The one with ran slower.
Frame speed or movement speed? That's the important part.
-
Ahh, I have tested it myself! I made a copy and tested it with and without getKey->K. The one with ran slower.
Frame speed or movement speed? That's the important part.
Movement speed. I haven't developed it enough for frame speed quite yet.
-
I'm writing my first major Axe program and I noticed that the speed isn't much faster than BASIC. Is this because my TI-84+ is too old? :(
No it must be the way you are formatting your code. A 84+ runs at ~15MHz no matter how old it is.
Maybe
Er, no. The EOS kindly automatically reduces the CPU speed to 6 MHz before running assembly programs and applications so that any timing code runs the same. You're expected to explicitly set the CPU speed if you want to run at full speed. However, BASIC programs automatically run in fast mode.
Well true, but I was mainly talking about how his calculator is no slower then a newer one.
-
"getkey" has to test ALL the keys and return the one that's pressed. Its also an OS routine, which makes it even slower. In addition, the arrow keys repeat very slowly when held down.
getkey(KEY) only checks ONE key so its super super fast.
-
I changed to getkey(#) and mine runs faster also, thanks.
/offtopic Btw Quigibo, how do you pronounce your name?
-
I'm pretty sure the reason getKey->var is so much slower is because it's interrupt based, as is TI Basic's version.