Home » Discussion forums » OpenTK » Support
BlueMonkMN's picture

Keyboard Access

Posted Tuesday, 11 March, 2008 - 11:27 by BlueMonkMN in

Is it true that the input features of OpenTK apply only to GameWindow and cannot be accessed via GLControl?

‹ [Audio]OpenAL on Vista 64 3D extents ›

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler's picture

Re: Keyboard Access

Posted Tuesday, 11 March, 2008 - 11:44 by the Fiddler

For now, yes. This limitation will be lifted as soon as I can find a way to either redirect input messages on X11 or implement asynchronous input there.

The problem is that the InputDriver and Windows.Forms end up fighting for the input message, which ends up in either (but not both!) On Windows, you can subclass and provide your own WndProc, which will process input messages before passing them to Windows.Forms. On X11 (straight xlib), I haven't been able to find a way to do this.

objarni's picture

Re: Keyboard Access

Posted Tuesday, 11 March, 2008 - 13:03 by objarni

I think it is quite OK if input is handled differently in a GLControl scenario from a GameWindow.

After all, if the developer uses GLControl, he/she probably knows Windows.Forms :)

It would be a bit "messy" actually if input *could* be handled both ways.

But I can see the "economic issue" of a OpenTK user being able to convert code between the GLControl<->GameWindow contexts if the GameWindow specific way of handling input also works in a GLControl scenario.

But I don't think it's worth the effort/quality cost for such a small thing..

the Fiddler's picture

Re: Keyboard Access

Posted Tuesday, 11 March, 2008 - 13:17 by the Fiddler

Actually making InputDriver work with Windows.Forms (and possibly GTK#) was a design decision taken from the beginning. The user will have to instantiate an InputDriver manually, if he wishes to make use of this functionality.

It's not as messy as it sounds - you'll only *need* to do this for joystck input. There will be a clear warning in any case: "if you need joystick input, consider switching to GameWindow".

One other advantage of OpenTK.Input is that it may provide more functionality (e.g. >400 DPI for mice under windows). The fact that it will be easier to port from GLControl <-> GameWindow is a nice side-effect too.

This is not high priority though as GLControl isn't really targeted at games.

BlueMonkMN's picture

Re: Keyboard Access

Posted Tuesday, 11 March, 2008 - 20:36 by BlueMonkMN

You mentioned joystick input. When I looked I didn't see any obvious support for that in the code I have. Is joystick input currently supported via OpenTK?

the Fiddler's picture

Re: Keyboard Access

Posted Tuesday, 11 March, 2008 - 20:59 by the Fiddler

No, but it's one of the two missing pieces left for OpenTK 1.0 (the other is support for Mac OS X). Once joystick input is in, we hit beta status. :)

BlueMonkMN's picture

Re: Keyboard Access

Posted Saturday, 4 July, 2009 - 14:11 by BlueMonkMN

Are you aware of any issues in supporting direct Keyboard access in Linux on both 32- and 64-bit systems? I'm using the following platform declarations for Linux and it doesn't work in a 64-bit environment (it does work in a 32-bit environment):

   [DllImport("libX11")]
   private static extern IntPtr XOpenDisplay(string display_name);
   [DllImport("libX11")]
   private static extern void XQueryKeymap(IntPtr display, System.UInt32[] keys);
   [DllImport("libX11")]
   private static extern IntPtr XGetKeyboardMapping(IntPtr display, byte first_keycode, int keycode_count, out int keysyms_per_keycode);
   [DllImport("libX11")]
   private static extern void XDisplayKeycodes(IntPtr display, out int min_keycodes, out int max_keycodes);
   [DllImport("libX11")]
   private static extern IntPtr XFree(IntPtr data);

- Ben / "BlueMonkMN" / Scrolling Game Development Kit - http://sgdk2.sf.net/