Game loop

Android
1

Hi

Just a simple question. I’m trying to seperate input processing from update within the game loop. There doesn’t seem to be any obvious way to do this.

Any ideas?

2

Separate in what way? You still have to check the inputs at some time. Where would you do it if it wasn’t in the update function (or in a function called directly/indirectly by the update function)?

3

just before the update function

Input()
Update()
Draw()

4

You could make a seperate thread, or look into async functions in .net

5

I usually create a HandleInput method that I call at the start of Update. You can do that just in your Game1 class and call the input handling methods from other components from there, just like you do with Update and Draw. I.e. in your Game1 class

public void Update(GameTime gt)
{
    HandleInput();
    
    // regular update stuff
    // e.g. ScreenManager.Update(gt);
}

public void Draw(GameTime gt)
{
    // draw stuff
    // e.g. ScreenManager.Draw(gt);
}

public void HandleInput()
{
    // handle input here or call HandleInput on child components
    // e.g. ScreenManager.HandleInput();
}

Then treat HandleInput in your other classes like you treat a Draw or Update call.

6

Anything wrong with

Update()
{
    Input()
    ...
}

Draw()
7

I can see an issue with input being handled badly with it being decoupled, and lag being barely the tip off the iceberg…

That being said, Input should always be the first thing to have data pulled from on any update…

I agree with @KonajuGames 's route… as you would want data updated as soon as possible after input and then draw visual updates…

Imagine if update was handled alternatively after Draw… in VR, this would be vomit inducing…

Anyway, take a look here:

http://gameprogrammingpatterns.com/game-loop.html

Adding that to the UMGRL thread…

8

so there’s nothing wrong with having input processed more than once between draw calls if draw is slowed for whatever reason?

In the context of a fixed timestep update?

9

It makes a lot more sense to have input synced with update than draw really. It’s possible to completely seperate game logic from drawing and handling input is a part of game logic. Why would you want to tie input processing to draw calls?

1 Like
10

You can play with draw calls, even delay them on a threshold type thing [relating to V-Sync etc. or such]

But input, you should never allow it to feel weird…

1 Like
11

i do it just like jjag i even name it handle input as well lol.

If i wanted it to update input slower id wrap it with a if and a timer.

so there’s nothing wrong with having input processed more than once between draw calls if draw is slowed for whatever reason?

If draw is being slowed this bad were you put your input at is the least of your problems.

Though putting it in draw will make it so that typing and moving the mouse if your game does lag for someone including you.

Is absolutely infuriating… :rage: