So, having your input loop wait 300 MS is good, and it certainly solves the problem. But it shouldn't be considered as a permanent fix. The reason is that what if someone presses the D-Pad while the loop is blocked in the wait code?
If you want them to be able to scroll by holding the D-Pad down, implement a wait of maybe 10 ms, and use a timestamp to control if the menu actually moves or not. Something like this:
let the constant timeBetweenScrolls = 300 ms
let lastScrollTime = 0
while user doesn't want to exit menu and user hasn't picked an option {
if user is not holding down on the D-Pad {
let lastScrollTime = 0
} else { // if the user is holding the down direction...
if (currentTime - lastScrollTime) >= timeBetweenScrolls {
scroll menu forward
let lastScrollTime = currentTime
} // If they've been holding down on the D-Pad long enough that we can scroll
} // if user is holding down the D-Pad
sleep 10 ms
} // loop
ivan_soto wrote:I would not call wait if I were you.
Yes, a wait of 300 milliseconds is dangerous because it blocks with no possibility of moving forward for a relatively long period of time. It's always a good idea to explain why you would discourage or encourage behaviors, so that we all can learn from one another. Just saying "don't do that" doesn't help a new software developer. The reason a 300 millisecond wait time is not good is because it will give choppy input. Humans are capable of perceiving 300 millisecond time gaps; it also means that when you press a key, you only have a 1 in three (roughly) chances of that key registering because the input loop is executing only 3 times per second.