Jump to content
  • Advertisement
Sign in to follow this  
Musikai

Moving with delta time.

This topic is 1852 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

So im making a pong clone and i have a silly problem.

 

I have a Paddle class with HandleInput(), Update(), and Draw() functions. The HandleIput and Update functions look like this at the moment.

 

void Paddle::HandleInput( Keyboard& keyboard )
{
    if( keyboard.KeyIsHeld( m_upKey ) )
	m_position.y -= m_moveSpeed;

    if( keyboard.KeyIsHeld( m_downKey ) )
	m_position.y += m_moveSpeed;
}

void Paddle::Update( float deltaTime )
{

}

 

The problem is that i want the position to be changed over time but at the moment the "Update" function is the one who is passed the delta time. It's a stupid problem but i can't figure out a nice way around it.

 

I want to avoid passing the delta time to the "HandleInput" function because it wouldn't really make sense, and also these function are actually an interface to a game object so it would mean passing it to every "HandleInput" function, whether it needed it or not. I could add a couple booleans to track whether either of the keys were pressed during "HandleInput" but that is essentially testing the same thing twice. I'm leaning towards the idea of adding a "delta position" variable to track the change in position, so the code would look something like this.

 

void Paddle::HandleInput( Keyboard& keyboard )
{
    if( keyboard.KeyIsHeld( m_upKey ) )
	m_deltaY -= m_moveSpeed;

    if( keyboard.KeyIsHeld( m_downKey ) )
	m_deltaY += m_moveSpeed;
}

void Paddle::Update( float deltaTime )
{
    m_position.y += (m_deltaY * deltaTime);
    m_deltaY = 0;
}

 

What do you guys think is the best solution?

Edited by Musikai

Share this post


Link to post
Share on other sites
Advertisement
It isn't really handling the same thing twice. They are similar, certainly, but not identical.

Let the HandleInput function mark flags inside the object. Your paddle object shouldn't know or care if the instruction to move is coming from the keyboard, or is coming from an AI of any particular skill, or is coming over a network. HandleInput is just one of many ways you could indicate the need for motion. I anticipate you will want to add an AI player, and that AI player will need a way to mark those same flags. You might consider rather than giving the whole keyboard to the paddle, having an input system pass an event such as up/down/stop to the paddle instead. This would be generic to any input source, human or AI.

In the other place the position is being updated at a regular interval. It tests if there is a need to move and attempts to make the move. This place can do other tests, such as ensuring the new position is within bounds.

Share this post


Link to post
Share on other sites

I never thought about the AI, thats a good point. It just seemed like it was testing the key press boolean only to store it and test it again, but yeah the AI has to know to move somehow.

 

Thanks frob.

Share this post


Link to post
Share on other sites

Your second idea is better.  I would advise setting the velocity of the paddle in the HandleInput() function, then updating the position in Update().  Obviously, the velocity (pixels/second for example) * seconds = number of pixels to move per Update.

 

You could then, of course, handle having the paddle be faster (via an upgrade) or slower (via a debuff).

Share this post


Link to post
Share on other sites

Your second idea is better.  I would advise setting the velocity of the paddle in the HandleInput() function, then updating the position in Update().

I have to disagree—both ideas are flawed (the second is just slightly less flawed). Input should change nothing but flags at most, and that in itself is still only a “patch” for the most correct approach, which is to buffer the input inside of HandleInput(), doing absolutely nothing else but keeping a log of what happened, and then reading and interpreting that input in the logical update of the game for later processing within that same logical update. The processing that would happen would be to set a bunch of flags as frob mentioned and latet the later game logic handle those flags and do what is necessary, again allowing the same game logic to be applied to AI’s as well.

Keeping a log of inputs and parsing them out later might be a bit much for the original poster, so the next best thing would be to do as frob suggested and just set the flags there in HandleInput().


L. Spiro

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!