Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


Processing game input


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
5 replies to this topic

#1 CdrTomalak   Members   -  Reputation: 272

Like
0Likes
Like

Posted 26 August 2012 - 02:12 PM

So my basic 2d game framework in SlimDX is going well. I've created a custom Sprite object, and have some rudimentary mastery of rendering sprites. I just need to move them now.

I have a basic game loop set up, which is based on an old C# game prorgramming book. Having set up all the graphics device bits and bobs, and drawn my sprite on screen, I enter a method in my Game class called Run(). This has the following content:
[source lang="csharp"] public void Run() { while( this.Created ) { // Process one frame of the game ProcessFrame(); Render(); // Handle all events Application.DoEvents(); } }[/source]
ProcessFrame() is supposed to have all the game logic in it, in response to events. Whilst I have a simple event handler (based on an override of OnKeyDown) set up to detect keypresses, I'm wondering how to collect keypresses such that I can process the responses to them in the ProcessFrame() method.

Some initial research on this subject suggests creating a HashSet<Keys>. I've never done this before, so I'm not sure how I would go about it.

There are probably many ways to do this, so I thought I'd see what people would recommend before jumping right in there. Posted Image

Sponsor:

#2 NightCreature83   Crossbones+   -  Reputation: 3034

Like
1Likes
Like

Posted 26 August 2012 - 02:25 PM

You would have to store the input state of the input device and pass that to ProcessFrame. Have a look at XNAs GamepadState and KeyboardState structures they are a good example of what you want to do. They also present a fairly nice interface towards gamepads and keyboards.

The best thing to do is to only capture the input state once per update and do all you update logic with that state. The next step to take is to write keybindings so you are never checking hard coded keys or buttons, but you check against actions which the user can then define the associated button for.

Edited by NightCreature83, 26 August 2012 - 02:27 PM.

Worked on titles: CMR:DiRT2, DiRT 3, DiRT: Showdown, GRID 2, Mad Max

#3 CdrTomalak   Members   -  Reputation: 272

Like
0Likes
Like

Posted 26 August 2012 - 02:32 PM

Thanks for the speedy reponse NC! I've been checking out this tutorial: http://www.riemers.net/eng/Tutorials/XNA/Csharp/Series2D/Keyboard_input.php

This uses the KeyboardState structure as you suggest, and would give me an easy way to update sprite locations etc upon keypresses. I think I would have a ProcessKeyboard() method in the while loop of the Run() method - which might mean I wouldn't need ProcessFrame(), since all I'm doing is processing responses to keypresses, and nothing complicated - for now.

#4 NightCreature83   Crossbones+   -  Reputation: 3034

Like
1Likes
Like

Posted 26 August 2012 - 03:11 PM

Yeah that sounds reasonable. The later action is just when you continue on an you are starting to realise you need more flexibility actionmaps is what will give that to you.
Worked on titles: CMR:DiRT2, DiRT 3, DiRT: Showdown, GRID 2, Mad Max

#5 zfvesoljc   Members   -  Reputation: 443

Like
1Likes
Like

Posted 27 August 2012 - 02:21 AM

As mentioned, a good way is to pull current state from the input devices once per frame and do logic based on that. However, usually only current state is not enough, for example if you are reading raw input or analog values from gamepad. Here, keeping an input state from previous frame(s) with time stamps can help a lot. Based on previous states one can determine how the value changed (slow vs fast) you can even manually catch double clicks (press).

#6 CdrTomalak   Members   -  Reputation: 272

Like
0Likes
Like

Posted 27 August 2012 - 01:51 PM

Thanks for the replies. I'm going with checking the keyboard state once every frame. Fingers crossed! Posted Image




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