Author Topic: Speed  (Read 5131 times)

0 Members and 1 Guest are viewing this topic.

Offline BlakPilar

  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 734
  • Rating: +44/-1
    • View Profile
Speed
« 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? :(

Offline Eeems

  • Mr. Dictator
  • Administrator
  • LV13 Extreme Addict (Next: 9001)
  • *************
  • Posts: 6245
  • Rating: +318/-36
  • little oof
    • View Profile
    • Eeems
Re: Speed
« Reply #1 on: July 18, 2011, 11:43:25 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? :(
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.
/e

Offline mrmprog

  • LV7 Elite (Next: 700)
  • *******
  • Posts: 559
  • Rating: +35/-1
    • View Profile
Re: Speed
« Reply #2 on: July 18, 2011, 11:50:14 pm »
I am actually having a similar problem. What is the command to set 15mhz mode, is it FULL?

Offline Darl181

  • «Yo buddy, you still alive?»
  • CoT Emeritus
  • LV12 Extreme Poster (Next: 5000)
  • *
  • Posts: 3408
  • Rating: +305/-13
  • VGhlIEdhbWU=
    • View Profile
    • darl181.webuda.com
Re: Speed
« Reply #3 on: July 19, 2011, 12:01:50 am »
Yes it is.  Like eeems said, your code will only be fast if it's coded well.
« Last Edit: July 19, 2011, 12:02:04 am by Darl181 »
Vy'o'us pleorsdti thl'e gjaemue

Offline BlakPilar

  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 734
  • Rating: +44/-1
    • View Profile
Re: Speed
« Reply #4 on: July 19, 2011, 12:02:48 am »
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?
« Last Edit: July 19, 2011, 12:07:15 am by BlakPilar »

Offline JustCause

  • CoT Emeritus
  • LV8 Addict (Next: 1000)
  • *
  • Posts: 810
  • Rating: +115/-5
    • View Profile
Re: Speed
« Reply #5 on: July 19, 2011, 12:30:46 am »
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.
« Last Edit: July 19, 2011, 12:31:04 am by JustCause »
See you, space cowboy...

Offline leafy

  • CoT Emeritus
  • LV10 31337 u53r (Next: 2000)
  • *
  • Posts: 1554
  • Rating: +475/-97
  • Seizon senryakuuuu!
    • View Profile
    • keff.me
Re: Speed
« Reply #6 on: July 19, 2011, 12:31:57 am »
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.
In-progress: Graviter (...)

Offline BlakPilar

  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 734
  • Rating: +44/-1
    • View Profile
Re: Speed
« Reply #7 on: July 19, 2011, 12:46:35 am »
Hmm... Well, here was my original code:
Code: [Select]
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. ???
« Last Edit: July 19, 2011, 12:48:03 am by BlakPilar »

Offline JustCause

  • CoT Emeritus
  • LV8 Addict (Next: 1000)
  • *
  • Posts: 810
  • Rating: +115/-5
    • View Profile
Re: Speed
« Reply #8 on: July 19, 2011, 12:51:08 am »
Hmm... Well, here was my original code:
Code: [Select]
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.
« Last Edit: July 19, 2011, 12:51:48 am by JustCause »
See you, space cowboy...

Offline DrDnar

  • LV7 Elite (Next: 700)
  • *******
  • Posts: 546
  • Rating: +97/-1
    • View Profile
Re: Speed
« Reply #9 on: July 19, 2011, 12:59:08 am »
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.
"No tools will make a man a skilled workman, or master of defense, nor be of any use to him who has not learned how to handle them, and has never bestowed any attention upon them. . . . Yes, [] the tools which would teach men their own use would be beyond price."—Plato's The Republic, circa 380 BC

Offline BlakPilar

  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 734
  • Rating: +44/-1
    • View Profile
Re: Speed
« Reply #10 on: July 19, 2011, 01:03:01 am »
Hmm... Well, here was my original code:
Code: [Select]
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?

Offline JustCause

  • CoT Emeritus
  • LV8 Addict (Next: 1000)
  • *
  • Posts: 810
  • Rating: +115/-5
    • View Profile
Re: Speed
« Reply #11 on: July 19, 2011, 01:06:38 am »
Hmm... Well, here was my original code:
Code: [Select]
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
« Last Edit: July 19, 2011, 01:06:49 am by JustCause »
See you, space cowboy...

Offline Darl181

  • «Yo buddy, you still alive?»
  • CoT Emeritus
  • LV12 Extreme Poster (Next: 5000)
  • *
  • Posts: 3408
  • Rating: +305/-13
  • VGhlIEdhbWU=
    • View Profile
    • darl181.webuda.com
Re: Speed
« Reply #12 on: July 19, 2011, 01:06:54 am »
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
« Last Edit: July 19, 2011, 01:07:06 am by Darl181 »
Vy'o'us pleorsdti thl'e gjaemue

Offline BlakPilar

  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 734
  • Rating: +44/-1
    • View Profile
Re: Speed
« Reply #13 on: July 19, 2011, 01:09:44 am »
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.

Offline JustCause

  • CoT Emeritus
  • LV8 Addict (Next: 1000)
  • *
  • Posts: 810
  • Rating: +115/-5
    • View Profile
Re: Speed
« Reply #14 on: July 19, 2011, 01:20:36 am »
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)
« Last Edit: July 19, 2011, 01:20:53 am by JustCause »
See you, space cowboy...