Cireon's picture

Intended usage (custom) platforms

I was not sure where to post this, feel free to (ask me to) move it if this is not the right place to discuss this.

I am currently working on a project that is supposed to be released at some point using an engine based on OpenTK. In the past releases, we have had several problems using the SDL2 backend. While we do require SDL2 for proper gamepad support, it also results in the game not working for a significant subgroup of our potential players. We are also not entirely happy with how SDL2 handles the fullscreen. Hence, we would like to return to the native code for the graphics element of our game, while still having an option to use SDL2 for the input (we only need SDL2 for the gamepad code really).

Right now there is however no control whatsoever over what is used. OpenTK automatically chooses SDL2 if the library is available, so it is an "all or nothing" deal. From what I can see, the Factory.Default is so intertwined in the code, that there is not really a way around it without diving into the OpenTK source ourselves.

So I return to my question: what is the intended solution for these situations? The current platform implementation feels very rigid and I don't see a way of forcing the Factory to use the native drivers without SDL2, which would also restrict us from using SDL2 to create some custom code for gamepads. Ideally, we would even use a hybrid inputdriver between SDL2 and Windows/OSX, as it seems both recognise different gamepads (or not).


Comments

Comment viewing options

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

1. We need bug reports for the issues you are encountering with the SDL2 backend. We cannot fix bugs we are not aware of.

2. We need bug reports for the issues you are encountering with gamepad support. We cannot fix bugs we are not aware of.

3. The following code will force OpenTK to use the native backend:

using OpenTK;
 
static void Main()
{
    var options = new ToolkitOptions
    {
        Backend = PlatformBackend.PreferNative
    };
 
    using (Toolkit.Init(options))
    {
        ...
    }
}

4. The various namespaces of OpenTK can be treated as separate modules. You are free to mix and match e.g. SDL2 input with OpenTK.GameWindow. The only limitation is opening a window from two different toolkits in the same process. Some toolkits may impose additional limitations.

Cireon's picture

Regarding 1 and 2:
I would like to explain the exact problems we run into, but we haven't been able to reproduce it ourselves yet. Our guess is that is has to do with the difference between 32- and 64-bit systems, but we haven't found a clear pattern yet. I will definitely let you know when I find them though. I am not responsible for technical support for our project, so I do not have access to the exact data either. I will enquire my colleague about these though.
Additionally, we don't like the fullscreen behaviour of SDL2, which is why we would like to have the native backend.

Regarding 3:
Thanks a lot, that is very helpful.

Regarding 4:
I am not entirely sure what is meant by this. At first I thought I could have an SDL2 inputdriver running next to the other stuff, but it seems I misinterpreted, as none of those classes are accessible. I am therefore not sure what is meant with modules, so any clarification would be appreciated.

the Fiddler's picture

Regarding 4:
You can combine a SDL-based input driver with OpenTK.GameWindow. This is what MonoGame does, for example.

For this, you will need a SDL binding. You have three options:

  1. Modify OpenTK to make OpenTK.Platform.SDL2.Sdl2 public.
  2. Copy OpenTK.Platform.SDL2.Sdl2 directly into your project.
  3. Use a 3rd party SDL binding.

The SDL binding in OpenTK is private by design. However, if there is enough interest, I'd consider moving that into its own separate project that could be used independently.

Edit:
Just a clarification regarding joystick support. OpenTK.Input.Joystick and OpenTK.Input.GamePad should give identical results between OpenTK and SDL2. Anything else is a bug that can - and should - be fixed.

Right now, there are a couple of known issues:

  • OpenTK is using the gamepad database of SDL 2.0.1, which is slightly out of date (so some gamepads may not be recognized.) Updating that is trivial.
  • On Windows, OpenTK combines an XInput and a WinMM joystick driver. SDL2 combines an XInput and DirectInput driver. XInput gamepads should give identical results between the two, but older gamepads may not. This will be fixed in a future version via a new USB HID driver (which is already implemented, but not yet merged.)