How to deal with Input Sequences?

Started by
14 comments, last by ferrous 10 years, 2 months ago


Why do you remove some item, but not the others?

The vector is also supposed to keep the "history" of relevant inputs, so the game code could call:


if(input.IsMatch("MOVE_DOWN", "MOVE_DOWN_LEFT", "MOVE_LEFT"))
{
   //Do something knowing this sequence has been pressed, such as a special move for fighting games
}

So I check if it's time to remove the input from the history or not, and process the ones for the next update (because my code might've lagged out, so I'm only queueing the ones in between a certain time frame).

And well, regarding the names, it's still a queue... it's just not the std::queue.

When I think queue, I think "ah, something that will be dealt with later on" (and when the order is important). And also I never knew about the std::queue before this topic ahahaha

Though it wouldn't fit in this example since the vector is doing more than just a queue.

Advertisement

However if you have a mouse cursor thats independent of the display (like what happens in an RTS) if the frame rate slow down, theres not a good reason why the cursor should lag behind the rest of the frame.

But if the frame rate slows down, usually the mouse will be rendered at that same slow frame rate. I see no advantages on keeping the mouse refreshing while the user can't see where it is at.

Isn't it possible to have the mouse be drawn over the scene, even if the scene isn't completed rendering yet?

This would involve moving the SwapBuffers or whatever the equivalent is outside of the rendering loop, but I think it should be possible.

Sounds like people are getting hung up on your input queue. =)

As someone else mentioned, lowering the rate at which you sample the mouse would probably help.

And as the OP mentioned, instead of doing a new/delete, moving that to non-dynamic memory would help as well. One way to do it would be to move to a memory pool. Though unless you did the reduced mouse sampling, all this would do is push out all the other samples. (or put the mouse sampling in it's own pool, so you have all the possible keyboard/button inputs, and then like the last 30 mouse moves)

EDIT:

A crap example of a memory pool:

MAX_INPUTS=32

Queue<int> m_InputQueue; // holds indices into the array of input samples

InputEvent m_inputEvents[MAX_INPUTS];

int inputmapping; //each bit represents an index, if the bit is set, the index is in use

Isn't it possible to have the mouse be drawn over the scene, even if the scene isn't completed rendering yet?

This would involve moving the SwapBuffers or whatever the equivalent is outside of the rendering loop, but I think it should be possible.

Possible, it is. Still, when you update the UI, with the "game layer" frozen, your cursor would leave a "clone trail" behind it. Even if this is done, I don't see how it would be of use. It would probably make frame rate drops worse.


The vector is also supposed to keep the "history" of relevant inputs, so the game code could call:

if(input.IsMatch("MOVE_DOWN", "MOVE_DOWN_LEFT", "MOVE_LEFT"))
{
//Do something knowing this sequence has been pressed, such as a special move for fighting games
}

So I check if it's time to remove the input from the history or not, and process the ones for the next update (because my code might've lagged out, so I'm only queueing the ones in between a certain time frame).



And well, regarding the names, it's still a queue... it's just not the std::queue.

When I think queue, I think "ah, something that will be dealt with later on" (and when the order is important). And also I never knew about the std::queue before this topic ahahaha

Though it wouldn't fit in this example since the vector is doing more than just a queue.

Ahh I get you. In that case, std::list should be perfect for this job, because of the O(1) removal of items. In theory, std::vector's erase is relatively slow near the beginning of the vector because you have a whole array to shift to the left. In practice though, you'll be fine until you notice significant slowdown caused by the vector.

Indeed, I was too hung up on the queue.

Isn't it possible to have the mouse be drawn over the scene, even if the scene isn't completed rendering yet?

This would involve moving the SwapBuffers or whatever the equivalent is outside of the rendering loop, but I think it should be possible.

Possible, it is. Still, when you update the UI, with the "game layer" frozen, your cursor would leave a "clone trail" behind it. Even if this is done, I don't see how it would be of use. It would probably make frame rate drops worse.

For those concerned about the mouse graphically, look into Hardware Mouse Cursor

This topic is closed to new replies.

Advertisement