Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


When to check input in fixed step game loop


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 NetrickPL   Members   -  Reputation: 116

Like
0Likes
Like

Posted 25 December 2012 - 07:41 AM

Hey! I have a question about fixes step game loop. Is it better to check input (mouse, keyboard and packets) in fixed step loop or in render loop?

I mean #1:
while (true) //main loop
{
    while(fixed step loop) //ie 50/100 times a second
     {
       check input
       do logic
      }
      render
}

or rather #2:

while (true) //main loop
{
      check input
    while(fixed step loop) //ie 50/100 times a second
     {
       do logic
      }
      render
}

I think the approach #1 is better especially for lower framerates (you check input whenever you need for logic, and in case #2 @5fps you could press a key for a short moment and it could be processed 20 times by logic loop).

Could you advice me what's better? Because I'm not sure. Which one is used in games?

Thanks



Sponsor:

#2 m41q   Members   -  Reputation: 151

Like
1Likes
Like

Posted 25 December 2012 - 10:43 AM

Yeah, it looks like version 1 is the better approach to get fast responses when pressing a key or something.

But usually, if the game runs with 5 fps, no one will like to play it anyway ^^

Don´t think to much over something that simple. If you run into problems with the time the game needs to react, you are still able to change your code...



#3 NiteLordz   Members   -  Reputation: 440

Like
0Likes
Like

Posted 25 December 2012 - 11:25 AM

I handle my input like case #2 and I queue up the input commands. This allows the user to keep interacting, without losing any input.

Then in the logic step I apply, then render. The fixed step in my scenario is only for physics
Code makes the man

#4 Matias Goldberg   Crossbones+   -  Reputation: 3564

Like
0Likes
Like

Posted 25 December 2012 - 11:51 AM

I think the approach #1 is better especially for lower framerates (you check input whenever you need for logic, and in case #2 @5fps you could press a key for a short moment and it could be processed 20 times by logic loop).

Could you advice me what's better? Because I'm not sure. Which one is used in games?

Thanks

In many cases you will actually be limited by your OS in which advanced key input handling is tied to Window management, and if you go multithreading the OS will tend you to move input handling to the Graphics rendering thread. It's not impossible to overcome, but gives a lot more work.

 

Doing it in logic should be best. But take in mind you have to split your thinking of input into logic and graphics. Depending on your game, there may be some input that must be handled deterministically, affecting logic; while there's some other input that is graphics related and non-deterministic (i.e. a GUI)






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS