I meant this:


Code:

You might not notice a huge difference with something so simple, but if you have other actions for other keys, it makes an improvement. (You would replace "While Ans" with "While Ans=34 or 2>abs(Ans-25")

No, actually I left out a getKey→K in the second loop, as in:


Code:


EDIT: Really? So the speed would be worth the extra memory if I used Ans for the getKey, then stored it to K? Either way, that is a lot faster than what I've been using. Thanks for the tip.

You probably want a DelVar K in there somewhere.

This is what came to me as a surprise as well.


EDIT@elfprince13 Maybe in place of the second getKey->K?

"Worth" is pretty subjective, but I would say that if you have a lot of different types of responses to keypresses (such as in some games), the speed is worth it. Do remember that if your action is not repetitive (as in, the user isn't expected to press the same type of key repeatedly for some time), doing this will actually slow down response time.

A good place to use multiple loops like that is in text editing, because when people type, there is very little time in between keypresses. In addition, when deleting/moving cursors, people tend to hold down keys.... so here is a string editor, for situations in which the user wants to edit an existing string, or if you want the UI to be completely graphscreen based.


Code:


Btw, whenever I use "!=", I mean "not equal to"

I have another question on a related topic:

This may seem strange, but remember how whenever you hold down a repeating key, it registers once, then pauses for about half a second, then starts repeating quickly? For example, in that simple movement program above, if you pressed the right arrow, the X would move right once, pause for a moment, then zoom toward the end. Well, when playing one of my games on any SE calculator, that little pause occasionally results in the program moving forward before the next keypress is registered. This is especially annoying when I'm trying to move from one platform to another, and my character falls an extra space because the calculator didn't have time to register the right arrow in time.

Is there any way to avoid that? I know there are assembly programs that reduce the amount of time between the first and second keypress registers, but I wanted to keep this program pure BASIC. Is there a way to fix this?[/url]

[Moved To New Topic]

I don't exactly know why it does this, but the same happens to me. Alike how in MirageOS, the first getKey is not recognized, you need to code in a backup in case the key isn't captured.

For example, instead of just "getKey", try


Code:


It's annoying, and takes up space, but it does make moving around smoother.

Btw, you can use Celtic3 to check if you're on a 84 or an 83, and adjust the limit on C (counter) accordingly.