Print

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

[Kraythe]

I would like to expand OIS to be more feature rich. I would like to propose the following feature additions and changes. Some of these will cut across the whole OIS source base.

1) Implementation of Mouse Capture functionality.

This means that when inside the client area the mouse will be able to float out of the client area transparrently but it can also be siezed and not allowed to leave for things like mouse look. This is important in strategy and RPGs where the user is often looking at lore sites or usign teamspeak or other out of game functionality. To this end I would like to have two methods:

capture(); /** This method siezes the mouse and doesnt allow it to leave the client area; useful for mouse look */

snapshot(); /** this method gets the current state of the input device (buttons down, location of mouse, etc) This is used for unbuffered input.  */

2) Implementation of multiple language keyboards.

The keyboard scan codes are currently mapped to default US keyboard and that is bad internationally. I propose that the key codes be stored in an array that can function as a lookup table. We should also populate a number of lookup tables for various european keyboards. Later we can worry about other input methods such as non-latin character sets.

3) Implement the ability to register more than one mouse or key listener.

[pjcast]

I too also want to have OIS be as feature rich and flexible as possible  

1.) Because there is no real center keeping of Devices, you call capture on each device regardless of if in Buffered or Unbuffered (by design). Now, there could be other calls added into perform certain things.. Like free the mouse though. But, capture is needed regardless as long as you want to have state changes and events happen. Also, you can already recieve the state of the mouse/joystick from buffered or unbuffered mode. Same for the keyboard, except it does not return a structure, only has isKeyDown type of methods.

2.) Have you looked at OISKeyboard.h & .cpp? This is the approach used. Currently, only english is supported, but the plan is to load the mappings from a file.

3.) As I've mention elsewhere... I feel that the majority of apps only need one listener per each device. And, if the app needs braodcasting of events, all they have to do is create a super class that they recieve events from and broadcast. Now, this could be (like ActionMapping) a compile in feature choice though... Just create the DispatchListener and it handles the rest kindof thing.

[Kraythe]

I too also want to have OIS be as feature rich and flexible as possible  

1.) Because there is no real center keeping of Devices, you call capture on each device regardless of if in Buffered or Unbuffered (by design). Now, there could be other calls added into perform certain things.. Like free the mouse though. But, capture is needed regardless as long as you want to have state changes and events happen. Also, you can already recieve the state of the mouse/joystick from buffered or unbuffered mode. Same for the keyboard, except it does not return a structure, only has isKeyDown type of methods.

Ok then we could add a new method to do this. Its probably better that we dont change method names anyways of current methods as that would mess up people that wanted to upgrade. So we could call the method ... hmm ... ideas ...

Code: [Select]


sieze()
trap()
grab()


Other ideas ? The basic idea being that the mouse can not escape the window if this method is called with a value of true but otherwise the mouse will smoothly exit the client area if the pointer reaches the side.

2.) Have you looked at OISKeyboard.h & .cpp? This is the approach used. Currently, only english is supported, but the plan is to load the mappings from a file.

Actually that wont work. You should read the windows documentation on scan codes for an overview but the problem is that you modeled only the easiest model keyboard. I use a german keyboard and that one is much more problematic. For example you have combination keys. for example if I press the ^ key in the upper left of my keyboard an then press the o key, I get ?. This is a ocmbination using something called a dead key and that wont work with a simple enumeration mapping.

I think there should be an expansion of the listeners to incorperate this functionality. The methods keyPressed() and keyReleased() will deliver only the scancode to the user. The method keyTyped() will perform a scancode to key typed lookup and will give the user an actual key typed. So in the case of ? it would only deliver the keyTyped() call when the o is typed. keyTyped() will deliver the unicode UTF-8 value for the key that is typed as well as the ASCII code if there is an ASCII code for the particular key typed.

Users would be able to use  enter, backspace and the F keys using something like the following code: (Note that ScanCode is a typedef to be cross platform)

Code: [Select]


keyPressed(Keyboard source, ScanCode code) {
    if (code == source::nonCharCodes[ENTER]) {
        // do code for enter.
    }
}


This will allow a user to hook into multilanguage keyboards and recieve input without all the problems. As for reading this data from a file, there is really no need. The layouts are extremely static and adding new keyboards is just a matter of creating a new definition file and loading it. There is really no need to bloat the code with file IO.

You would also probably want to have a method that will try and determine what layout of the keyboard is being used. This might be a method in the input manager that the platform implementations must implement in their own way.  At any rate it is much more complicated than it appears to be at first.

3.) As I've mention elsewhere... I feel that the majority of apps only need one listener per each device. And, if the app needs braodcasting of events, all they have to do is create a super class that they recieve events from and broadcast. Now, this could be (like ActionMapping) a compile in feature choice though... Just create the DispatchListener and it handles the rest kindof thing.

Well if you really want to do it this way I suppose that would be fine. However, I dont see anything wrong with multiple listener capability. Its a few minutes (at most) to implement with an STL set.

[pjcast]

First of all, using file IO actually will decrease the current code size, cause there will be less code instructions filling the mapping.

Also, the current mapping is not really just a simple enumeration, and combinations already work... Ie. Shift & f = F, Shift & 3 = #, etc. And this can differ from language as it is determined by the current mapping.

Additionally, the KeyCode enum is what DirectInput returns from the keyboard (and it is not really the KeyCode, but a ScanCode). Not sure what you would want to with typedef'ing a ScanCode variable. In fact, language selection should happen at runtime, not compile time, so I do not think a typedef would work... For, you should be able to build your app in (for instance) the US, and distribute it to any country and have it just work. Of course, this does mean that (a) the lib may need to determine current locale, or (b) the app has a user dialog that the user can select langauge from.

[pjcast]

I've thought a bit about mouse and grabbing/hiding/etc..

I think before a design decision is finally made.. First thing that needs to be thought about is... should a mouse be able to recieve updated input when it is no longer contained by the window?... For intance, if DirectInput Exclusive mode is used, mouse is gone forever until unaquired.. at which time it no longer recieve any events after that.

now, if we instead always create mouse with NonExclusive mode access.. then, the mouse will be able to be seen and events generated. Then this leads to the secondary flag of Foreground and background.. If we use background then the mouse will always recieve input, even when window is no longer in focus.

A second thought is about removing those start up settings entirely and just come up with some common behavior settings (in an Enum). Though, X Windows always only gives input to your window when the mouse is over it.. so there is no cross-platform method there that relates to DI Background mode. The only way to do that would be to bypass X and read from /dev/input/eventX (where X represents a number and can be any kind of device).

Then we could add some public methods to mouse class for Hide, Grab, etc. For D3D we could just recreate the device with exclusive access to hide the mouse and grab it - as we could maybe reposition the mouse when it nears the screen's edges instead (as I do with X Windows) for grabbing.

[pjcast]

Ok, I think I've decided one  method should be added to Mouse

virtual void enableHardwareCursor( bool enable )

When the hardware (OS) cursor is visible (active) then the mouse is not grabbed at all... It will just move in and out of app window. Now, when you set it to enabled (the default setting), the mouse dissappears and becomes grabbed. IMO, grabbing and visibility go hand in hand - if you are grabbing the mouse, you do not want to show the mouse warping back to center. Also, grabbing can be accomplished two ways (1) the Mouse Device can be destroyed and then created again with EXCLUSIVE Access which hides and captures the mouse - best way I think - or (2) Hide the cursor using Win32API, then begin warping cursor around to keep it from leaving using SetCursorPosition(,).

[Anonymous]

First of all, using file IO actually will decrease the current code size, cause there will be less code instructions filling the mapping.

Why would stuffing all that file IO in there be good? And why bother when the keyboard layouts are standardized?

Also, the current mapping is not really just a simple enumeration, and combinations already work... Ie. Shift & f = F, Shift & 3 = #, etc. And this can differ from language as it is determined by the current mapping.

But it doesnt cover dead keys which are the combination of two key strikes. Since Im working on a german keyboard Im all too familiar with them. You also need a mapping from left alt-keypress.

Additionally, the KeyCode enum is what DirectInput returns from the keyboard (and it is not really the KeyCode, but a ScanCode). Not sure what you would want to with typedef'ing a ScanCode variable. In fact, language selection should happen at runtime, not compile time, so I do not think a typedef would work... For, you should be able to build your app in (for instance) the US, and distribute it to any country and have it just work. Of course, this does mean that (a) the lib may need to determine current locale, or (b) the app has a user dialog that the user can select langauge from.

No you misunderstand me ... ScanCode is a typedef because on some systems the code might be packed into 4 bytes and another on 1 byte. It just abstracts out things just in case.

typedef int ScanCode;

What I would do is set up a smart matrix that would read the codes comming in from the keyPressed and keyReleased methods and then output the keyTyped method accordingly. In the case of dead key typing, there would be only one keyTyped event for 2 keyReleased events. In windows you can also type a 4 keystroke unicode code to get unicode output as well so that would be supported.

Each keyboard type would be a static instance of the Keyboard class with the appropriate matrix values.

[Anonymous]

I've thought a bit about mouse and grabbing/hiding/etc..

I think before a design decision is finally made.. First thing that needs to be thought about is... should a mouse be able to recieve updated input when it is no longer contained by the window?... For intance, if DirectInput Exclusive mode is used, mouse is gone forever until unaquired.. at which time it no longer recieve any events after that.

The mouse should send input to the Application so long as it is over the client (non titlebar and so on) area of the window. The mouse shouldnt have to be held in the window and contained. A user should be able to seemlessly follow across the window and out the other side with the cursor following it.

Note that this doesnt mean we have to use the OS cursor. We could grab the mouse when it comes in the client and release it when it goes out of the client and then automate that under the hood with a default cursor. Of course that would mean rendering the cursor in ogre and that might be too ogre specific. if we let the operating system cursor show then we have to abstract out methods for setting the cursor (arrow, text input, custom) so that the user can change the cursor.

now, if we instead always create mouse with NonExclusive mode access.. then, the mouse will be able to be seen and events generated. Then this leads to the secondary flag of Foreground and background.. If we use background then the mouse will always recieve input, even when window is no longer in focus.

The mouse listeners should recieve input whenever the cursor is over the window. You should take a look at the game "Eve Online" www.eve-online.com. There is a 14 day trial of the game so you need not buy anything; try it in windowed mode. That game behaves exactly the way I would expect our library to behave. The mouse moves smoothly between the game and desktop and the cursor changes even when the mouse is over the game while it is behind another application. In this case the first click brings the window to foreground. The only thing it doesnt do right is that when the user right clicks adn holds on, it should capture the mouse and make the cursor vanish until the key is released.

A second thought is about removing those start up settings entirely and just come up with some common behavior settings (in an Enum). Though, X Windows always only gives input to your window when the mouse is over it.. so there is no cross-platform method there that relates to DI Background mode. The only way to do that would be to bypass X and read from /dev/input/eventX (where X represents a number and can be any kind of device).

I cant speak to X windows programming other than to say that I know a background window in X can recieve mouse input because you can paste to a background window or even type in it if you turn on the ability to type in the window you hover over.

Then we could add some public methods to mouse class for Hide, Grab, etc. For D3D we could just recreate the device with exclusive access to hide the mouse and grab it - as we could maybe reposition the mouse when it nears the screen's edges instead (as I do with X Windows) for grabbing.

Well the initialization routines are bound to be varied. =)

[Anonymous]

Ok, I think I've decided one  method should be added to Mouse

virtual void enableHardwareCursor( bool enable )

When the hardware (OS) cursor is visible (active) then the mouse is not grabbed at all... It will just move in and out of app window. Now, when you set it to enabled (the default setting), the mouse dissappears and becomes grabbed. IMO, grabbing and visibility go hand in hand - if you are grabbing the mouse, you do not want to show the mouse warping back to center. Also, grabbing can be accomplished two ways (1) the Mouse Device can be destroyed and then created again with EXCLUSIVE Access which hides and captures the mouse - best way I think - or (2) Hide the cursor using Win32API, then begin warping cursor around to keep it from leaving using SetCursorPosition(,).

I believe there is a win32 API method for getting the mouse and pinning it to one window. I believe the method is capture(). At any rate if we go this route then we have to make sure that we provide a method to set the cursor for the mouse so that the user can set the cursor to something they want (text input, pointer, rolling, custom, etc)

[Kraythe]

Bah... I forgot to log in before I posted. Those posts were from me pjcast.

[pjcast]

As far as handling the setting of cursor.. that is not really needed. Most apps are fine with the default cursor types provided by the OS. And if they need something specific, they can always use a little OS specific code of their own. Rendering is way beyond the scope of the lib... the only place where the lib creates a mouse cursor is on XWindows, as there is no method to hide the curosr and a blank one is created.

X Windows will only send mouse events to the window that recieves events (the window you connect to) I am sure pasting is a completely different message, and as far as window's becoming active wen the mouse hovers over them that is an OS control thing.

In regards to the typedef, no KeyBoard scancodes that I am aware of are multibytes - must keyboards do not have more than 256 keys... Though, the actualy chracter representation could be a multibyte character.. which is why the method that gets the character (via Mappings) returns a short.. it could also return an Int maybe.. but, I still do not see your point about IO bloat? Using file IO routines is not going to bloat the lib. And, I am not talking about keyboard layout, but actual character values for the KeyCodes..

[Kraythe]

As far as handling the setting of cursor.. that is not really needed. Most apps are fine with the default cursor types provided by the OS. And if they need something specific, they can always use a little OS specific code of their own.

ok I can cope with that. Its better than us trying to abstract it out since that would probably be bloody hard given the various cursor formats and so on.

Rendering is way beyond the scope of the lib... the only place where the lib creates a mouse cursor is on XWindows, as there is no method to hide the curosr and a blank one is created.

Totally agreed on the rendering and Ill take your worrd for it on the XWindows. Im comming mostly from a windows side and soon to be OS X side. (I will work on a port when we get near a 1.0)

X Windows will only send mouse events to the window that recieves events (the window you connect to) I am sure pasting is a completely different message, and as far as window's becoming active wen the mouse hovers over them that is an OS control thing.

Ok ..well we can make it transparent underneath then. Or perhaps the window must be in the foreground to get input (ie it must be the active application). I have no problem with that so long as the mouse can smoothly slide over the window and out. You should be able to rapidly move in oand out of the window even if it is the main application.

In regards to the typedef, no KeyBoard scancodes that I am aware of are multibytes - must keyboards do not have more than 256 keys... Though, the actualy chracter representation could be a multibyte character.. which is why the method that gets the character (via Mappings) returns a short.. it could also return an Int maybe..

Well we can drop the typedef .. Im not married to it. I just thought that some OS might use a different type for the scan code. However, we can cross that bridge if we find it later. Lets leave it as a short for now.

but, I still do not see your point about IO bloat? Using file IO routines is not going to bloat the lib. And, I am not talking about keyboard layout, but actual character values for the KeyCodes..

This is where I have the better of you... let me find the page ...

http://msdn.microsoft.com/library/en-us/winui/winui/windowsuserinterface/userinput/keyboardinput/aboutkeyboardinput.asp

Check out that page on MSDN and do a search in the text of the page for "Dead-Character Messages" and you will see what Im talkign about. The layout is more complicated than you might expect. Essentially we will have to build 3 lookup tables. One for straight key presses on chars with scan codes for modifiers (shift, etc), Another to translate Dead-Character Messages, and another for scan code look up on control keys like enter, shift, etc.

I know EXACTLY how to build this PJ and Im willign to do it now. If, after you see it, you want to store the configurations of these three tables to a file, *shrug*. I dotn see any need for it but im not "against it." The only thing it would benefit is being able to add a new keyboard layout without compiling the library.

[Kraythe]

Also look at this link.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wceddk5/html/wce50conGermanKeyboard.asp

Uhh .. and lookign at the japaneese section of that keyboard layout page is making me think that we will need specialized classes for each type to do the lookup.

[pjcast]

Yeah, localization stuff sucks.. And I really do not plan to get too deep into that until the next release (0.5.0). THough, if you want to take a crack at it, I am open to that :wink:

Another thing I thought of is, (but was in a hurry really to get out the 0.2 release).. was that the OS (Windows, probably XWindows too) may have some features / API to deal with translating ScanCodes to localised Unicode formats.. I just havn't looked into that.. cause really, looking at the Win32API (and X API) scare me  :twisted: Neither are what I would call pretty..

Though, I went with the transaltion using Maps.. either way works for me.. Which ever way is the easiest, most flexible is the best way IMO.

And, I finally figured out what you were asking for with the mouse before.. I think that is not very easy to do... The best way would be for the app to request that the hardwareCursor be shown and hidden upon whatever trigger events it wants. - when shown, it would also no longer be grabbed. This could be accomplished via a keystroke, or the app could just monitor the location of the mouse itself, and request to show the hardware cursor - removing any grabs.

[Kraythe]

Ok I will take a crack at it .. but now I have a bunch of patches to submit. I have ported all the Visual C++ projects to 2005 and as well to link and compile against the binary release of ogre. I have also set up the _DLL_EXPORT macro and fixed it to several objects.

Other than that, I only have the one patch I submitted before but I can resubmit everything together. I will need an email to send it to though. Copy paste in forum wont cut it.

I will investicate handling the translation with windows code. That was sheer brilliance and Im annoyed it didnt occur to me. Of COURSE the OSes have code for this so just use theirs. Silly.