2018-04-01 03:01:51

Subject says it all. Could someone fix the timer issue on this menux class, for joystick implementation. Without it the thing allows you to hold down the d-pad or axis to move through the menu.
https://ln.sync.com/dl/b30987950/63jb94 … z-huv7ahyf

2018-04-01 09:26:02 (edited by Munawar 2018-04-01 09:29:39)

You can do exactly what we've covered in the last thread on this subject. Sometimes with development it's a good idea to think outside the box.

Asking for tips is fine, but asking someone to do it for you won't help you learn.

What you have to do is think like a computer. Why is your menu scrolling continuously as you hold the joystick's D-Pad down? Because you're not telling it to stop.

Think of the code that fires when you press the D-Pad as code that's running over and over and over again. You have to control that code. Check post 12 on this topic: http://forum.audiogames.net/viewtopic.php?id=24559

I go into more detail there about how input is handled.

2018-04-01 19:44:01 (edited by jack 2018-04-01 19:45:38)

You're right about figuring things out rather than having them done, and I actually fixed the problem already. Wait(300); makes a world of difference. Lol. The timer implementation would've worked except for the fact that it's just easier to have it wait a predetermined amount of milliseconds anyway. Ironically that's exactly what I was trying to tell Garrett when he was revamping the enemy system by taking out the enemy system from Scrolling Battles and adapting it from Battle Zone. Firstly, two different games, two different variable sets, two different sets of code, and a code for a game inside of a game can lead to no good. And second, I don't see how that can be satisfying, I revamped the enemy system, sure, pretty much through someone else's entire code. I totally get improving an opensource project, that's the point of code-sharing anyway. But if you really want to revamp something and have such a dedication to it, you'll learn to write your own code. Or learn off of others' code and then adapt your game to it.

2018-04-01 23:40:21

I would not call wait if I were you.

Ivan M. Soto.
Feel free to check out my work and services.
http://ims-productions.com

2018-04-02 00:23:43 (edited by Munawar 2018-04-02 00:30:08)

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.

2018-04-02 03:23:45 (edited by jack 2018-04-02 03:27:08)

Good call. However I will say, it was actually 200ms not 300. 300 was actually the first thing I tried while calling wait, and that is exactly what happened, but as it happens I simply decreased the time when calling wait. My interpretation is that the time it will take someone to hear the option, in the case of a new player or someone voluntarily deciding to slowly scroll through the menu for whatever reason, has smooth performance, and 200ms was in that moment  a decent meet-in-the-middle when we consider deciding responsiveness vs having no wait whatsoever and the joystick moving through all 6 of the menu options before you can let go.

2018-04-02 03:48:09

I think even 200 milliseconds is too long. The idea is that you want your loop to spin fast enough to where it's virtually impossible for user input to not register. Even with 200 millisecond wait times, you're still only reading input five times a second.

If your loop spins every 10 milliseconds, then you're reading input 100 times every second and it becomes virtually impossible to miss input.

The reason in some games you have to press keys two or three times is because the wait times are too high. So, I would fix this now instead of letting it suffice for the moment as a middle ground. Because there will be people, like me, who won't hold the D-Pad down and will instead rapidly click it to move through the menu. It will interfere with usability and kill the user experience if we have to time in our heads when we need to press the D-Pad for the next input to register.

2018-04-02 04:00:59

yes, exactly. If it is missing inputs, it will degrade the experience for the controller users.

Facts with Tom MacDonald, Adam Calhoun, and Dax
End racism
End division
Become united

2018-04-02 15:54:17

keep in mind, wait is pausing the entire script. As many have said, bad news unless your operating on extremely small values. Anything above about 10 I would use timers for, and those timers to pause the specified operation. You've gotta think of every possibility.

2018-04-02 20:01:31

its also worth noting that anything in the sound object like play_wait does the same thing, it pauses the entire script, so unless its like an intro, outro or some cutscene or clip, I wouldn't use it often, certainly not during gameplay because your entire script pauses.

Facts with Tom MacDonald, Adam Calhoun, and Dax
End racism
End division
Become united