Speed

[BlakPilar]

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?

[Eeems]

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.

[mrmprog]

I am actually having a similar problem. What is the command to set 15mhz mode, is it FULL?

[Darl181]

Yes it is.  Like eeems said, your code will only be fast if it's coded well.

[BlakPilar]

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?

[JustCause]

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.

[leafy]

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.

[BlakPilar]

Hmm... Well, here was my original code:

Code: Select All | Copy To Clipboard

1 2 3 4 5

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.

[JustCause]

Hmm... Well, here was my original code:

Code: Select All | Copy To Clipboard

1 2 3 4 5

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.

[DrDnar]

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.

[BlakPilar]

Hmm... Well, here was my original code:

Code: Select All | Copy To Clipboard

1 2 3 4 5

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?

[JustCause]

Hmm... Well, here was my original code:

Code: Select All | Copy To Clipboard

1 2 3 4 5

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.

[Darl181]

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

[BlakPilar]

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.

I knew what you meant and I wasn't doubting your knowledge of Axe I was just asking lol.

[JustCause]

I wasn't doubting your knowledge of Axe

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)