TI-86 Programming For The Weak Of Finger: Tips and Tricks
Created | Updated Jan 28, 2002
:\\Code up to the loop |
OK, here's the problem with this code: performance. Even if no keys were pressed and the GETKY returns a 0, the program still checks it to every keycode in the book. If you really do check it to all 51 keycodes, then you could probably solve the problem more quickly with pencil and scrap paper. The user wil become confused when you have to wait 15 seconds for the program to see that you hit EXIT. Whoops, too late, it exited too slowly, you can't hid the game you were playing from your teacher. This code is much faster, better, and more responsive at left:
:Lbl Wharple \\Look disgustingly familliar? It gets better. |
Note how many fewer lines are actually IN the loop. The keychecking code (about 54.8957983794753 IF-THENs) is not run inless you pressed a key, and we only used 1 if-then in the loop instead of 54.8957983794753 checks. This code does the same thing in much less effort, code, and time. It is optimised, but if you think it works far too well, go back to the old way.
OK, that's all well and good for a thinking puzzle where it waits for the Slowpoke human to finish, but in a game line Nibbles, Mario, or Hard Hat Mack Gets A Big Gun5, waiting for the human to move just won't do. Yes, it sure makes sense for the baddies to just sit there while Mario is stopped, instead of attacking while he's vulnerable. Riiiiight.
:Lbl Wharple \\You still need something to goto to. Otherwise, the program would get hopelessly lost and your calc would blow up if you told it to GOTO where there was no LBL... or maybe you'd just get an ERR 22 LABEL. I wouldn't know. |
On the code at left, the mistake that gives sleeping controls that don't respond well was made in Nibbles Arcade, and the blunder is something that ISN'T there. There is ONE line of code missing that would fix that. Just before the Lostalife test, insert the following line of code:
:Getky
Not too impressive, hmm? Here's what it does: Your controlls, in the unchanged loop, will not get cleared from the Getky buffer until one cycle AFTER you release them- remember, Getky looks at the last button pressed since a prompt, pause, or Getky, and doesn't care if it's being pushed right now or not, so trying to not push any keys willl, for one possibly fatal cycle, repeat the last press. So that's another miracle repair from I, the researcher, SmartGamer, the TI-MASTER!
More coming soon- I'm really just saving my work for another day.