Yeah, I've basically wrapped the GLFW stuff up to a) throw events around like you have and b) provide async input.

Quote:Original post by evolutional
provide async input.

Since you are the second one to mention that in this thread, is async input the most preferred method for games? Is it because it's more on demand or what?

While I am at it, I was also going to ask what you guys think aout joystick support? I mean it's always there, but rarely do I see people use it. Is it good to just have it there in case, or should developers not bother and let the user add it in if they wanted to? For my engine at least, joystick support is already there and all, so I've decided to add it in.

I don't know if I'm a special case, but I've found it useful to have both.

For example, my game input is managed with IInputHandlers, which are registered to receive input events. This is all well and good when it comes to checking for 'up, down, left, right, etc' presses and releases, but short of buffering the events locally for each object, how will you say "three keys are pressed at once"?

The thing is though, by doing it event based, as long as you track it that is, you will achieve the same thing. Right now, as my input system is, the On_XXX are for those events that happen the first time, so they are like callbacks as Promit mentioned, but they aren't themsevles callbacks. They are functions that are just called on an event (which is done though the update function after all the events have been buffered). Basically, that is for functionality that the WM_CHAR provides. You can just process key by key if you need to. Otherwise, everything is as what the so called async functions provide, even though my system is event based. So I can have something like:

if( inputClass->IsKeyDown( SDLK_a ) && inputClass->IsKeyDown( SDLK_s ) && inputClass->IsKeyDown( SDLK_d ) )   abort();

And it works as expected. Does the fact that I store all the buffered input and process thatt way, to which I have a means similar to async input make those functions async? Not that it matters, just something to think about [wink]. In the class I do have:

std::vector<bool> mouseButtonStates;std::vector<bool> keyStates;

that store the information so I guess I do have both means employed in my system, just though buffered events.

Hey guys, I'm writing the input class for an open source game I'm working on called Epiar ( www.epiar.net ) and I'm looking for your input on my methods for handling the whole input system. I'm attaching the same cInput class proposal that I sent to the other developers.

Because the current cInput needs to be reworked to make more extensible and easier to add actions, etc. My newly proposed cInput class I think does the job and also gets rid of keys.cpp. It uses Drew Benton's SDL Input Library found at http://www.gamedev.net/community/forums/topic.asp?topic_id=328994

Now I want your comments and feedback on how you think it will work and don't be nice. I'm just figuring this stuff out as I go so I'm sure theres room for improvement. Since I'm a bit of a programming n00b theres probably a bunch of syntactical errors and I'm not totally sure if I used enum right, but those are minor details that I can work out when I get the compile errors. I'm really interested in the over all method of doing this.

keys.xml has declarations like:<controlsFlyMode>	<fire1>		<device>mou</device>		<value>1</value>	</fire1>	<orbit>		<device>key</device>		<value>9</device>	</orbit></controlsFlyMode><controlsSelectMode>	<select>		<device>mou</device>		<value>1</value>	</select>	<fire1>		<device>key</device>		<value>64</value>	</fire1></controlsSelectMode>There are two different control modes because we (or at least I?) were/was talking about being able to toggle between flying mode where you'd use the mouse to point the ship and the mouse1 button would be fire, etc. But then you could hit tab to select other ships, interact with the HUD, open the right click menu, etc. Many of the controls would be the same,but it can pretty easily be taken out.The value for the keyboard is the int value of SDL_a or KMOD_CTRL or whatever. They're just plain and simple ints. The SDL documentation has these values in a table somewhere. The values for the mouse are simply the button numbers.LoadConfig() fills the following arrays with values from the keys config file. Of course the index matches the enumed action values like ACT_FIRE1 and ACT_ORBIT.int flyModeDevices[numberOfKeys];int flyModeValues[numberOfKeys];int selectModeDevices[numberOfKeys];int selectModeValues[numberOfKeys];Problems to solve that I can think of off the top of my head:* We should figure out an easy way to make it case insensetive. It's also probably   not terribly hard and could be done either in LoadConfig() or in GetActionValue(),   so SDLK_a and SDLK_A return the same int.* I don't show anything for setting and getting new keys or input, but thats fairly   trivial.* Alternatively the XML doc could be laid out like <fire1>mou1</fire1><orbit>key9</orbit>  depending on how cConfig works, I can't remember at the moment. And then you could   just chop it up in LoadConfig or something.* This input library doesn't currently support joystick functions, but the developer  said he was going to add it and even if it doesn't finish it in time, we could do   it ourselves.-----------------------------------------------------------------------------------// The following uses Drew Benton's "SDL input library" found at // http://www.gamedev.net/community/forums/topic.asp?topic_id=328994enum actions {	ACT_FIRE1,	ACT_ORBIT	//etc,etc}cInput::cInput() {	SDL_Event Event;	LoadConfig("keys.xml") //see note above	Input inputClass; //Drew Benton's SDL Input Library	//I'm sure there will be more to add here}void cInput::LoadConfig(string configFile) {	//see note above}int cInput::GetActionDevice(int action) {	if (flyMode == true) {		return flyModeDevice[action];	}	else {		return selectModeDevice[action];	}}int cInput::GetActionValue(int action) {	if (flyMode == true) {		return flyModeValue[action];	}	else {		return selectModeValue[action];	}}bool cInput::testAction (int thisAction) {	switch( GetActionDevice(thisAction) ) {		case 1:			if (inputClass.isKeyPressed( GetActionValue(thisAction) ) ) {				return true;			}		case 2:			if (inputClass.isButtonPressed( GetActionValue(thisAction) ) ) {				return true;			}			break;		case 3:			//no joystick support in inputClass yet, but its going to be added			break;	}	return false;}void cInput::resetKey (int thisAction) {	// works much the same way as testAction, but it uses setKeyUp() or setButtonUp() 	// so the action happens only once.}//this function is called in Epiar's update cyclevoid cInput::Update() {		//this chunk of code is from Drew Benton's demo included with the library	while ( SDL_PollEvent(&Event) )		{			if ( Event.type == SDL_QUIT ){				//do whatever we have to do to tell Epiar to quit			}			// Here we first call the Poll function with the current event			// inside our polling loop			InputClass.Poll(Event);		}		// Then we just have to call the update function to take the data		// from the Poll event and update the class	InputClass.Update();					//Now test each game action.	if (testAction(ACT_FIRE1)) {		player->fireWeapon(1);	}		if (testAction(ACT_ORBIT)) {		player->orbit(target);		resetKey(ACT_ORBIT); //for one time "toggle" type actions	}		if (testAction(ACT_SELECT)) {		//get the target by looking at whatever is at the current mouse location.		//get the mouse location using InputClass.GetMouseX() and InputClass.GetMouseY()		player->setTarget(something);		resetKey(ACT_SELECT);	}

[Edited by - TheMoebius on July 31, 2005 2:22:34 PM]

@Drew:
Is there still some place where we can download this library? I'm very interrested in it especially in its design.