the Fiddler's picture

The Open Toolkit Library 1.1 rc1

OpenTK 1.1 release candidate 1 is now ready for download.

Sourceforge
Nuget

This release is compatible with the 1.1 API.

Changes:

  • [GameWindow] More accurate UpdateFrame and RenderFrame timing.
  • [Windows] GraphicsContext will no longer consider single-buffered contexts when double-buffering is requested. Fixes graphical corruption issues on specific GPUs.
  • [Windows] Stability improvements when running over a Remote Desktop Connection.
  • [Windows] Stability improvements when using tablet / pen input devices.
  • [Linux, Mac] Native support for the new Joystick and GamePad input APIs.
  • [Linux, Mac] Support for input device hotplugging.

Known issues:

  • [Joystick] Joystick hats are not reported.
  • [NuGet] OpenTK.GLControl will not appear in the Visual Studio Toolbox. Adding the control in code still works. (https://github.com/opentk/opentk/issues/37)
  • [Windows] MouseState may report incorrect values for X1 and X2 mouse buttons. (https://github.com/opentk/opentk/issues/27)
  • [Windows] Joystick and GamePad APIs may report different capabilities for the same device. The SDL2 backend is not affected. This will be fixed in OpenTK 1.1 rc2.
  • [Windows] HiDPI systems report values in pixels, not points. This is inconsistent with the Mac backend. (https://github.com/opentk/opentk/issues/47)
  • [X11] Missing HiDPI support (native or SDL2).

If you encounter a bug, please report it at https://github.com/opentk/opentk/issues


Comments

Comment viewing options

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

Wow this looks massive update, thanks Fiddler.

migueltk's picture

Great, thanks for your work ...

Villermen's picture

Awesome update, really dig the new input APIs!
Can you give a rough estimation on when the joystick-hat registering/other input APIs will be implemented?
No rush really, just as a heads up.

Gr.Viller

the Fiddler's picture

The issue with hats is that they are very inconsistent. One device may report its dpad as a hat, another as a button collection and a third one as two axes. SDL tries to hack its way around those differences, but it's not always successful. Personally, I would very much prefer to ditch hats completely and map them unilaterally to buttons (if discrete) or axes (if continuous).

That would give a consistent API between devices / operating systems, but it would also make incompatible with the gamepad mappings in SDL/Steam, which would be even less desirable. The end-goal is to pick gamepad mappings from Steam automatically when they exist - less configuration, happier users.

For this reason, I'm consciously delaying the hat API until I can ascertain what the optimal approach is. Better that, than adding a suboptimal API that we'll have to support indefinitely (like the old joystick implementation.)

(That said, if someone sent a patch to implement JoystickState.GetHat(int) I would most probably accept it. Adding support in the SDL backend at least would be quite easy.)

Villermen's picture

Take all the time you need, for sure I am really amazed by your work so far. Wouldn't reporting the hats as axes AND buttons support everything? I have no idea how the steam mappings work so I probably don't really know what I'm talking about. I've worked with SFML before and they would report the gamepad hats as axes (Also using SDL I believe).

the Fiddler's picture

Adding support for hats was easier than I expected - this is now implemented in OpenTK 1.1-rc2 for all platforms.

The drivers for win, mac and sdl2 report hats as expected. The native linux driver (/dev/js) reports hats as axes, so we'd need a new /dev/event driver to fix that. It's a few hundred lines of code, but sdl2 already implements this for us, so I don't consider this a high priority. (Patches welcome!)

One thing to keep in mind is that different devices report hats in different ways. For instance, one device might report its dpad as a hat, but another might report it as two axes. OpenTK.Input.Joystick exposes the device directly, so you need to take this into account when writing an application (i.e. add a configuration screen.) This is the same approach as sdl2, and is slightly different to sfml.

OpenTK.Input.GamePad builds on top of Joystick with a mapping scheme to map devices to a static, well-known configuration. The mapping scheme is identical to sdl2 GameController, which is nice in various ways (including for Steam integration.)

The final part in the joystick puzzle is a public API to read/write these configurations at runtime. This needs some more cooking, so it will be part of the next release.