new (faster) getkey

Re: new (faster) getkey

Fri, 24 Jul 2009 02:08:11 +0000

One note: it makes little sense to optimize for speed when you have a loop that waits for a key. In that case, it's better to optimize for size.

exactly, so simply optimize for size and your golden! :)

Re: new (faster) getkey

Fri, 24 Jul 2009 00:02:52 +0000

That's probably the fastest way to do it, but, like you said, the fact that it checks for irrelevant keys is inconvenient and can be speed-costly, abusable, or glitchy in some cases (e.g., missing a button and slowing down the game)

Re: new (faster) getkey

Thu, 23 Jul 2009 23:54:11 +0000

One note: it makes little sense to optimize for speed when you have a loop that waits for a key. In that case, it's better to optimize for size.

I like to go with

:Repeat Ans :getKey→K :End

even if, later on, I'm only going to accept certain keys. Even if this makes something onscreen blink every time I press an absolutely unrelated key (I figure that's not too important, plus it lets the user know the program noticed the keypress)

Re: new (faster) getkey

Thu, 23 Jul 2009 23:50:06 +0000

Bearing in mind that not(while loop) is pretty much the same as repeat and that end parenthesis and brackets can be left off,
I recommend:

repeat sum(K={24,25,26,34
getkey→K
end

Re: new (faster) getkey

Thu, 23 Jul 2009 18:28:00 +0000

how about this routine?

while k≠24 and k≠25 and K≠26 and k≠34 getkey→ k end

while not(sum({24,25,26,34}=k)) getkey→ K end

i use those al the time, all the approachs above don't seem any more fast to me than the ones i just gave you. Perhaps i am wrong, we'll find out soon enough.

EDIT: i realize this is a nearly forgotten topic but i was just wandering around the site and came across this so…

Re: new (faster) getkey

Sun, 09 Nov 2008 02:59:16 +0000

Ah, true forgot about that, might have to incorporate it after I get all the other getkey calls done.

Re: new (faster) getkey

Sun, 09 Nov 2008 02:48:00 +0000

A 34 element list will take up 318 bytes of memory. You could cut 414 bytes (207 for each list) out with

SetUpEditor L1 SetUpEditor L2 DelVar L1 DelVar L2 11→dim(L1 11→dim(L2 -1→L1(1 1→L2(2 1→L1(3 -1→L2(11 Repeat K=22 getKey-23→K If max(K={1,2,3,11 Then X+L1(K)→X Y+L2(K)→Y End End

Re: new (faster) getkey

Sun, 09 Nov 2008 02:22:43 +0000

Just speaking of alternate getKey's for movement Im using this for a loop of mine.

SetUpEditor L1 SetUpEditor L2 DelVar L1 DelVar L2 34→dim(L1 34→dim(L2 -1→L1(24 1→L2(25 1→L1(26 -1→L2(34 Repeat K=45 getKey→K If max(K={24,25,26,34 Then X+L1(K)→X Y+L2(K)→Y End End

Thats it, very shortened.
This isnt the fastest by itself but useful for an extensive game.

Re: new (faster) getkey

Sat, 25 Oct 2008 08:27:00 +0000

yep

try downloading xsnake from ticalc.org

Re: new (faster) getkey

Sat, 25 Oct 2008 05:05:42 +0000

Use a seperate loop for each direction.

Re: new (faster) getkey

Fri, 24 Oct 2008 23:14:05 +0000

So what's the fastest way to handle movement on the home screen? In my game, you can't stop moving and you bounce off the edge of the screen. Speed is more important than size.

Re: new (faster) getkey

Thu, 31 Jul 2008 21:52:42 +0000

That's something you could do for any routine, though, so it's not really an improvement in any specific case.

Re: new (faster) getkey

Thu, 31 Jul 2008 21:40:49 +0000

I just thought of this, but if you replaced the Letter variables with the finance variables, you
could speed it up even more, since the finance variables are faster than even Ans.

Re: new (faster) getkey

Tue, 17 Jun 2008 15:03:39 +0000

about 5 months ^^

Re: new (faster) getkey

Tue, 17 Jun 2008 14:31:17 +0000

sorry…..:D

Re: new (faster) getkey

Tue, 17 Jun 2008 11:23:28 +0000

WOW darkstone knight? How long have you been programming TI-basic? I saw you are only a member of this wiki since 6 days ago? Or do you have more experience?

Re: new (faster) getkey

Mon, 16 Jun 2008 20:27:05 +0000

damn, you liar
:D

Re: new (faster) getkey

Mon, 16 Jun 2008 17:35:51 +0000

sorry guys. I forgot about the scientific method there for a second and changed more than just the routine. the actual timings are 103 pixels for the ipart/fpart method and 104 for the original. I'm not so sure one pixel faster over 200 iterations, which turns out to be about 1/500th of a second per iteration, is worth 14 bytes of size. I accidentally used a alternate display method I devised, which turns out to be quite slow, in only one of the routines.

Re: new (faster) getkey

Mon, 16 Jun 2008 16:33:05 +0000

seems my routine is even faster than i thougth
yay

Re: new (faster) getkey

Mon, 16 Jun 2008 16:25:33 +0000

It would definitely be good to document these findings.

Re: new (faster) getkey

Mon, 16 Jun 2008 16:05:17 +0000

Ok, so lets recap. The alternate routine for graphscreen movement with one variable and ipart/fpart is much faster but larger, and you can use △list(K={24,26 to make your code smaller, but then setting boundaries is no longer possible without making the code larger again. (has anyone other than me noticed that?)
To be exact, I implemented the alternate routine onto the homescreen (yah, it took a while to figure things out), and the alternate routine was this fast at a for loop with 200 iterations. 12 bars, seven pixels, or 103 pixels. the original routine is 16 bars, 5 five pixels, or 133 pixels. that's 23% faster. I'll post these timings on the code timings page for reference.

Re: new (faster) getkey

Sun, 15 Jun 2008 19:26:21 +0000

yes, but large lists are faster than multiple and/or commands

Re: new (faster) getkey

Sun, 15 Jun 2008 19:20:53 +0000

I don't think so. If you check the timings page, I believe implied multiplication is actually faster than explicit multiplication, and unclosed parentheses take the same amount of time as normal parentheses. You're right about the lists. The lists and the extra operations are the main reason its slower.

Re: new (faster) getkey

Sun, 15 Jun 2008 18:32:09 +0000

The reason that it is slower is that the less things you make the calculator imply (brackets/parenthesis, multiplication, etc.) the less work it has to do. because △list(K={24,26 uses lists and involves more overall operations than the common formula, it is slower.
posted to the DYK page also.

Re: new (faster) getkey

Sun, 15 Jun 2008 17:51:10 +0000

yep

should be included in the "did you know" page

Re: new (faster) getkey

Sun, 15 Jun 2008 17:41:11 +0000

Actually, since user created menus don't need much speed, that would be a good application for it.

Re: new (faster) getkey

Sun, 15 Jun 2008 16:46:05 +0000

it might be usefull in those games that dont require speed

Re: new (faster) getkey

Sun, 15 Jun 2008 12:41:07 +0000

That was a good thought, though.

Re: new (faster) getkey

Sun, 15 Jun 2008 10:23:04 +0000

OMFG cant belive this
X+(K=26)-(K=24→X
16 bytes

X+△list(K={24,26→X
13 bytes?
14 bytes, △list is 2 bytes

revolution starts in: 0 seconds
:D

edit: actualy its slower LOL

Re: new (faster) getkey

Sun, 15 Jun 2008 09:31:01 +0000

Okey Dokey, I was able to shrink your routine after all. Look,

Instead of this:
:A+(K=26)-(K=24)+.001((K=25)-(K=34→A

You can do this:
:A+(K=26)-(K=24)+E‾3((K=25)-(K=34→A

By using that really cool E, you will save a glorious byte.

Cheers ~ James Kanjo

Re: new (faster) getkey

Sat, 14 Jun 2008 21:11:26 +0000

thanks

now we need to wait for programers that are clever enoufh to (correctly) use this new routine

Re: new (faster) getkey

Sat, 14 Jun 2008 21:06:25 +0000

reply to your edit: notice I did use Ans, it's just that you can't use it as much if you want your routine to actually work on the right boundary. The routines I suggested were designed to work in all situations and be as small as possible.

Re: new (faster) getkey

Sat, 14 Jun 2008 21:02:00 +0000

for the first thing, I optimize for size, so I don't do that crazy negative thing that makes text coordinates the same as regular ones. It's slower and larger and hard to understand.
for the second, the problem isn't necessarily the last row. It's the last pixel to the right of the screen that the user is aloud to move onto. Thus, a boundary of A for the thing where using lists might optimize it more, things are only slightly better. I made a version of Daleks (look at the forum page for it) with 1 list instead of two and it was 25 bytes larger and a tad bit slower. you could argue that because of the list (minimum 57 bytes) being gone it's actually smaller, but that's not permanent size, that's size during the game. I think with lists which method is better is determined by how large the lists are and how often they are used.
Overall, I say that your method works well in situations with lots of lists full of coordinates and is a bit counterintuitive in normal getkey situations. Thanks for all the suggestions on it though.

Re: new (faster) getkey

Sat, 14 Jun 2008 20:35:24 +0000

_{^{2: I made a new getkey program with the idea, except that I realized something. because the calculator considers X.Y to be outside the screen when X=94 and Y is nonzero with a boundary of X<94, the last row will never be displayed with the optimized Pt-on(A,fpart(A. It must be Pt-on(ipart(A),fpart(A for it to work correctly on the outer boundary. Thus, it is of no use to add the extra zero on the screen dimensions for the Y coordinate.}}
you are correct, never releazed that
how about a window setting of 0,-.062?

also, if you ignore the last pixel (that is rarely used in most games, except for line( commands)
the routine can be smaller

GridOff AxesOff FnOff PlotsOff 0→Xmin 1→ΔX 0→Ymin 1%→ΔY or .62→Ymax DelVar AClrDraw Repeat 0 getKey→G fpart(A Line(A,Ans,A,Ans,not(G A+(G=26 and B<94)-(G=24 and B)+(% or .01, whichever works)(G=25 and Ans<.62)-(G=34 and Ans→A End

5 less bytes

if you gime me a few days, i will make 2 snake games and compare the speed

edit: notice you are not using ans, which is the major factor in its speed

Re: new (faster) getkey

Sat, 14 Jun 2008 20:04:07 +0000

1: We need to make a page about this called Alternate Getkey Routines.
2: I made a new getkey program with the idea, except that I realized something. because the calculator considers X.Y to be outside the screen when X=94 and Y is nonzero with a boundary of X<94, the last row will never be displayed with the optimized Pt-on(A,fpart(A. It must be Pt-on(ipart(A),fpart(A for it to work correctly on the outer boundary. Thus, it is of no use to add the extra zero on the screen dimensions for the Y coordinate.
3: Sorry to be a party pooper, but the regular routine for movement and this alternate routine are the exact same speed over 500 iterations, 32 bars 6 pixels, or 262 pixels. The alternate routine is also larger. The reason for this is that the required fpart and ipart commands take up so much space that it is counterintuitive, because you save space by putting ipart(A and fpart(A on their own line. Thus you are actually using more variables than you were originally, and lose space.
4:how do you access the percent symbol on a calculator? it might make the alternate routine slightly better.
5: Here is what the programs look like in a complete form (regular getKey program 119 bytes)

GridOff AxesOff FnOff PlotsOff 0→Xmin 1→ΔX 0→Ymin 1→ΔY DelVar ADelVar BClrDraw Repeat 0 getKey→G Line(A,B,A,B,not(Ans A+(Ans=26 and A<94)-(Ans=24 and A→A B+(G=25 and B<62)-(G=34 and B→B End

And here is the Alternate routine suggested by Darkstone Knight with some adjustments. 129 bytes.

GridOff AxesOff FnOff PlotsOff 0→Xmin 1→ΔX 0→Ymin 1%→ΔY or .62→Ymax DelVar AClrDraw Repeat 0 getKey→G ipart(A→B fpart(A Line(B,Ans,B,Ans,not(G A+(G=26 and B<94)-(G=24 and B)+(% or .01, whichever works)(G=25 and Ans<.62)-(G=34 and Ans→A End

Re: new (faster) getkey

Sat, 14 Jun 2008 10:00:13 +0000

^{Also, what if you had the window variables (0, 94, 0, .64) ? Then your code could be even smaller:}

this is false, because you need to use ipart( to get the x var

edit: nvm… wasnt paying atention

Re: new (faster) getkey

Sat, 14 Jun 2008 09:27:40 +0000

thats kinda genius.
:D have you made this up your self or did you find it some where else?

james kanjo is right, but you've just switch the up-button (25) with the down-button (34). Thats no big deal

Re: new (faster) getkey

Sat, 14 Jun 2008 08:56:55 +0000

What do you mean by no it is not? Are you saying your routine is not clever?

That is also clever how you take the X factor being rounded up into consideration!

But did you notice the first thing I said?

Cheers ~ James Kanjo

Re: new (faster) getkey

Sat, 14 Jun 2008 07:44:21 +0000

no it is not
if x is 50.64, x rounds up
so you need ipart(
if you use .001, X will always round down

so no need to use Ipart( when getting the x coord

Re: new (faster) getkey

Sat, 14 Jun 2008 02:08:23 +0000

this routine could be incredibly revolutionary. Think of the possibilities! now we only need one list for coordinates! now we only need use of 1 variable in all getkey routines! It's only drawback is the size increase because of the decimal point.

Re: new (faster) getkey

Fri, 13 Jun 2008 23:35:47 +0000

Your code doesn't work for me, the y axis seems to be inverted (up is down, and down is up). I find that this can be fixed in two ways:

A+(K=26)-(K=24)-.001((K=34)-(K=25→A or A+(K=26)-(K=24)+.001((K=25)-(K=34→A

Also, what if you had the window variables (0, 94, 0, .64) ? Then your code could be even smaller:

A+(K=26)-(K=24)+.01((K=25)-(K=34→A

Otherwise, you have a pretty clever routine there!

Cheers ~ James Kanjo

Re: new (faster) getkey

Fri, 13 Jun 2008 21:28:20 +0000

you can disp X coord whitout ipart(

Re: new (faster) getkey

Fri, 13 Jun 2008 19:02:30 +0000

But you loose speed when you need to separate the single coordinate into x and y to display it.

new (faster) getkey

Fri, 13 Jun 2008 17:11:11 +0000

we used to do this
X+(K=26)-(K=24→X
Y+(K=34)-(K=25→Y

but, whit window setting (0,94,0, 0.064
the folowing is TWO secs faster (@ 500 executes)

A+(K=26)-(K=24)+.001((K=34)-(K=25→A

now, lets asume you are making a snake game, you store both coordinates in a list
X→∟X(I
Y→∟Y(I

or?

A→∟A(I

at this point, you are FIVE (<——yes, this is correct) seconds faster

also, becus you use only ONE coordinate, say hello to this command:
hi, my name is ans, and im fast

brilliant, isn,t it?