Better Input Control in Games

[WILL]

What methods would you guys suggest as the best way of handling game controls using a component like TDXInput to determine when a control is to activate.

In my game's design I currently am using nothing more than a simple "if (GameClock mod 2 > 0) then" type statement to work as a delay for flipping targets on my targetting screen, which is rather sloppy. I want to improve the game controls so that it's less clunky. Does anyone have any suggestions on smooth game controls?

[WILL]

I am refering to realtime controls not turn based, if that helps.

[Alimonster]

Hey ho. Could you describe the problem in more detail, please, so we have a better idea of what you want to achieve? Why does your current method not satisfy you and what do you want the new system to achieve?

You use the term "smooth game controls in your post." As long as your game samples the input at a consistent rate, I'm not sure of what problem you'd encounter. If you samples too slowly then you'd have a problem ("laggy" controls). Sometimes, the Win32 key messages can be inconsistent (based on Windows' key repeat settings), so maybe DirectInput would fit the bill if you're not using it.

Anyway, let us know more details please.

[WILL]

Hmm... you're right, my question was a bit vague.

Well, I am using DelphiX's DXInput component to read the states of the keys and joystick and the method I'm using a lot of lag on the detection specifically in the menu controls. I use a DXTimer(from DelphiX, again) as my timer for the game and the onTimer event is where I stuck my update function for my DXInput component and controls procedure... I have the GameTimer.interval set so that it matches my wanted frame rate. I may cahnge to a better Timer component later, but for now this is what I'm using.

I hope this is enough to go on?

[Crisp_N_Dry]

Because you have based your controller (Keyboard/Joystick/Mouse whatever) update on the main framerate timer, you will definitely experience problems if your framerate timer is set to too large an interval. If the timer is set at 30 frames per second (33=1000/30 on the interval setting, I believe) then controllers such as the mouse and joystick will 'cause trouble because most people move these more in this space than you are checking, especially during twitch gaming such as arcade shooters and the suchlike. A possible solution may be to assign the controller update to another timer that is set to 0, so that it is checking the inputs as much as possible and then either queueing[?] the movements to be performed when the main game timer next clicks over, when the main game timer does click over, it checks this queue, performs the movements and clears the queue.
Or performing them instantly without drawing these actions onscreen.

Another option it to set the main game loop timer to 0 and perform the actions as soon as they come in but control the framerate by checking to see if an elapsed time has passed before redrawing the screen again. Hope it's not too long winded and confusing. let me know if you want me too explaing again.

[WILL]

Actaully thats a really smart idea... I don't know why I didn't think of this.

I'll give it a run and see how it improves my games control(especially the menu)...

[Almindor]

I don't know exactly hod delphiX input works but I've noticed a small thing with SDL keboard events(or events in general). If I just put them in a cycle or a 0 timer I get ~95% CPU killer. It's because the cpu tries to check as fast as possible even if the hardware isn't capable of such speeds. As soon as I added a delay of 1 millisecond it went back to nice 2%.

Oh and yes using a nicely built queue class is probably the best solution.