Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[tuan kuranes]

I've  finished my first step to "Input Gesture Recognition Demo" using Ogre and OIS.

Mouse Gesture Save and Recognition is done.

Now I'm trying to make my design of "mouse gesture" struct buffer  generalizable to any input . but what causes me problem is keyboard input.

I would need to be able to store directly KeyCode and Modifier state into a struct to ease comparison afterwards.

In other words, I need

Code: [Select]


unsigned char OISKeyboard::getCurrentKeyPressed()
int OISKeyboard::getCurrentModifierState()


you can/should typedef the 'unsigned char' and the 'int' and int to some oisKeyCode and oisKeyModifier type def so that you can handle other things afterwards (multibyte input ?)

Once generalized it would permit 'Input gesture" save, recognition and replay.
Then I'll release the demo that will show  'input recognition and replay'
(I really only need those to do so, so it may be very soon.)

nb: did I already said that rss on website, forum, and wiki is a must have. (for me at least, or I forgot to pass by here.)

[pjcast]

Wow, an Input Gesture demo would be sweet

In other words, I need

Code: [Select]


unsigned char OISKeyboard::getCurrentKeyPressed()
int OISKeyboard::getCurrentModifierState()


Not sure if you've gotten latest Cvs yet. There is a method to test and see if a modifier
is down.. OISKeyboard::isModiefierDown( ... )
It uses an enum for Shift, Ctrl and Alt.. Would this work for you, or do you truly need the bitfield that stores the modifier state? If so, I could probably add access to it.

THough, not sure how easy it would be adding an OISKeyboard::getCurrentKeyPressed(). It would not work well for immediate mode. And, in buffered mode you already get which keyDown and the latest Cvs removed the need for lookupCharMapping and replaced it with a simple element in KeyEvent::text (which is an int- for more than ascii type of characters). Perhaps if you could clarfify what & where you will will be calling this. Immediate mode for example really has no notion of the current key down - as there could be many down at once.

[pjcast]

Oh, and I'll see about an Rss feed for the wiki and forum, the main site already has one, i just removed the Link I believe.. I will put it back there in a few.  

[pjcast]

I added the Rss / Atom links to the main page again in case you want to have them I will take a look for a forum or wiki mod that allows rss.. I am sure there is one.

[tuan kuranes]

you truly need the bitfield

...and the keycode.

Otherwise, when saving and comparing current input to saved one, I would have to check  "iskey () "for each possible key pressed or each ismodifier...

idea is to make comparison like

Code: [Select]


OIS::KeyboardState currentinputKeyboardState;
OIS::KeyboardState savedinputKeyboardState;
if (savedinputKeyboardState != currentinputKeyboardState)
      break;


And when saving user input gesture, I would not look for a particular key but instead save "whole keyboard state". (was my unsigned char and int above, but if a int describes whole keyboard state would be event greater)

If not possible in IMMEDIATE mode, immediate mode wouldn't be supported in the Save/Recognition when using keyboard, limiting this to mouse gesture only.

Thanks a lot for rss. subscibed.
phpbb rss mod  : http://www.ogre3d.org/phpBB2/viewtopic.php?t=2375&highlight=rss

[pjcast]

Thanks for the rss link.. now it is installed at:
http://www.wreckedgames.com/forum/rss.php Updates every 9 minutes for now.

Just the wiki left I can probably find a mod for that (you really seem to know a lot about everything - i also can't wait to start with the PLSM2 soon).

Hmm, you want to save the state of every key that is down from one call? I guess I could add a method that could copy the key buffer array into a user supplied array if that is what you are asking for. Not sure what ou mean, but the int does not represent the whole keyboard state, just the state of the three modifiers. That would just mean something like;

Code: [Select]


keyBuffer temp[256];
KeyBoard->copyState( temp );


Then you could do a memcmp or something on the returned buffer.

[tuan kuranes]

What's sort of wiki it is, mediaWiki, wikini... ?
[edit]
oh it's MediaWIKI and it already has RSS automatically
http://www.wreckedgames.com/wiki/index.php?title=Special:Recentchanges&feed=rss
[/edit]

Hmm, you want to save the state of every key that is down from one call?

I want to be able to compare two keyboard input (specific key pressed or modifier press doesn't interest me)

So I guess there would be two Save/Compare Mode
- Buffered (unsigned char keycode + int modifier)
- Unbuffered (keyBuffer temp[256])
(User being warned that BufferedMode is the preffered way for Keyboard, or memory and speed will suffer.)

I would then need  accessor to those 3, along with a OISKeyboard::isBuffered()

[pjcast]

What's sort of wiki it is, mediaWiki, wikini... ?
[edit]
oh it's MediaWIKI and it already has RSS automatically
http://www.wreckedgames.com/wiki/index.php?title=Special:Recentchanges&feed=rss
[/edit]

Hehe.. I already have an Rss feed there and didn't know :oops: It is a highly customized (still not complete, missing the special page navigations - which would have made this more obvious too) media wiki template.

- Unbuffered (keyBuffer temp[256])

You could use the above (as of yet unadded method copyKeyState( char[256] )) for both buffered and nonbuffered mode and just do a compare.. Though, this would not work well as is between platforms, but I could change that. Reason being, DirectInput copies odd values inside the buffer (high bits) while Linux just sets it to 1 or 0 depending on if down or not. This would be noticiable if you saved the Dx version and compared it to the linux version. I could however make them the same for this purpose. Will adding just that method work for you then? You really don't need the KeyEvent::text element since that is really just a character representaion and will be different across languages (depending on the locale).

I would then need  accessor to those 3, along with a OISKeyboard::isBuffered()  

Object base class already has a buffered property you can get at:
virtual bool buffered(); returns the buffered state, I was in a c# mood at the time so instead of calling it getBuffered, I liked the notion of using property like names

[pjcast]

I added a method: copyKeyStates
And put some test code in the buffered keyDown event in the Console demo... It seems to work as expected. The Array returned is normalised to 1 for down and 0 for up.. Will this method work for you? If so i will commit it once I add the linux version. And if you think that this will do what you need?

This code sets the test for the combination of KC_1 and KC_K and prints equal when both keys are found to be down.. This would also worked for nonbuffered keyboard mode.

Code: [Select]


//Testing Copy KeyStates method
char temp[256];
char test[256];

for(int i = 0; i < 256; ++i) test[i] = 0;

test[OIS::KC_1] = 1; test[OIS::KC_K] = 1;

g_kb->copyKeyStates(temp);

bool equal = true;
for( int i = 0; i < 256; ++i )
{
if(temp[i] != test[i])
{
std::cout << "not equal\n";
equal = false;
break;
}
}
if( equal )
std::cout << "Equal\n";


[tuan kuranes]

Will this method work for you?  And if you think that this will do what you need?

yes, seems fine, thanks !
I'll use that once committed and  i'll send or release the demo asap ( few days at most)

[cdsnyder]

Can I make a suggestion?  It would mean changing things around in code, but a class made specifically for storing a keyboard state would make this feature more maintainable I think.  That way each keyboard class will have it's own "current" keyboard state, and the user is insulated from creating strictly typed arrays of char[256].  The keyboard state class would have an empty constructor and a copy constructor. The user can simply instantiate one and then pass by reference to the keyboard class which will copy it's current keyboard state to the user provided reference.

So that the user could do something like this:

Code: [Select]


OIS::KeyboardState savedstate;
kb->copyState( savedstate );


With a proposed Keyboard method of:

Code: [Select]


OIS::Keyboard::copyState( KeyboardState& state )


And each keyboard class would have to maintain one. Maybe the KeyboardState would look something like this:

Code: [Select]


class KeyboardState
{
    public:
        KeyboardState();
        KeyboardState( KeyboardState& copyState );

        char KeyBuffer[256];
        unsigned int Modifiers;

};


or something like that... you get the idea. Preferably with typedefs for char and the int of course.  Off the top of my head I can't imagine it would change the interface of Keyboard, however it would mean updating the internal methods to modifying a protected KeyboardState instead of every class having it's own KeyBuffer and mModifiers.  

It wouldn't be too hard to overload the == operator in the future to compare two instances for changes, even if the OS differs the copies should be relativly equal. Adding other things like clear() and such would be easy as well.

Chris

[pjcast]

I thought about this, and I thought about adding something to akin to the MouseState class for keyboard. however, much of it would be overkill. Keyboards are at most 256 keys, and that will likely never change in the forseeable future, so abstracting out the char[256] is kinda just a lot of work for a simple thing.

Kinda along the same lines as why keyboard only has an isKeyDown method as opposed to the MouseState/joyStickState classes which conatin axes, buttons, and the helper method isButtonDown. The keyboard only has one component type.

Plus, this feature will likely not be used that much in ordinary apps, and I do not want to create a lot of breaking changes for something so simple. Though, I do agree with you in that it would be better in theory. But in practice this lowlevel access is the best as it means the least amount of code changes to OIS and has little overhead besides an array copy (though, I am not professing optimise before profiling, just in this case it makes more sense to me to do it this way.

[tuan kuranes]

good point, cdsnyder.
I like the extensibility given by the approach.
could be generalized to a OIS::Object having OIS::ObjectState.
So that each "Input Object" can have States ?

[pjcast]

A later release will feature a more generalized event handling system where you no longer need to worry about Key, Mouse, or Joy listenres.. instead you will just listen for Component Events (Buttons ( keys/buttons), Axes ( mouse/joy/tablets/etc), POVs, etc). Though, this would not work at all similiar to this method of doing gestures, you would have to maintain a linked list of evets in a certain order and listen for that to happen.

But, that is still in the planning phase and will be a couple of releases away (it will not break the current functionality) - it will function similiar to the Actionmapping demo.

[cdsnyder]

True.. I'm sure it would hardly be used. Was just thinking of the future.

As for keeping a list of events... I actually just finished writing the same thing into the mac keyboard The keyboard events from OSX happen in real time, while OIS behavior only calls back the listener upon calling capture(). So I needed to keep a list of OSX events to replay upon calling capture() for buffered input.

 I had to make a separate container that wrapped up a KeyEvent along with an an enum to specify the event type. I think tuan could easily do the same by registering a listener and then pushing each event onto the back of a list for a recording.  Then maintain an iterator through a recorded list and ++ it when it matches an event provided by the listener, and reset the iterator to your list.front() if the event does not match. When the iterator reaches list.end() then the sequence is complete. Replaying a sequence would just run through the recorded list and send a copy of each KeyEvent to whatever the program is using to handle input.

With unbuffered, you're correct, you would need to record the exact state to make sure an incorrect keypress resets the iterator through the recorded list. Really that would be very inefficient anyway wouldn't it? You'd have to compare all 256 values for every time through the loop. Registering a listener and then using the callback to inform each recorded list of an event would be much faster and would always catch every keypress/release.