Has anyone else wondered if it might be a good idea to replace our platform specific windowing code with SDL2?
Pros:
- It supports all platforms we support, and more
- Lifts a LOT of work from our hands
- Current windowing code has some bugs (eg OGRE-169) that would be solved automatically
- Limitations in our window code (eg you can't change title after creating the window - window icons not possible - etc) these are already possible in SDL
- SDL2 is very stable, and it's used in a bunch of AAA titles by Valve
- (Samples) We could FINALLY drop the unmaintained OIS with its stupid bugs and limitations, and switch to SDL for input
Here's a list of advantages of SDL input over OIS, to my knowledge:
Q: But Ogre is a rendering engine, who cares which input engine is used by the samples?- Hardware cursors
- Key scancodes
- Joystick hotplug
- Mouse warping
- Text input API
- Better input grabbing behaviour on linux
- Cursor can be grabbed/ungrabbed at any time
The reality is that people look at the samples / tutorials to get started which at the time of writing use OIS.
If you've noticed, about 90% of projects still seem to be using OIS, even though SDL2 is not difficult to plug in and is far superior input wise.
Q: But you can already use SDL2 and Ogre by using external windows!
Yes, indeed. However I think this is bad as a permanent solution for a few reasons.
- The integration is somewhat wonky. The documentation for the external window parameters has been lagging behind (not sure if this is fixed yet). There's no official example code. This can be fixed, but there will always be platform specific integration code that needs to be done on the user's side to pass the window handle. Nasty.
- There's a few bugs that may be extremely hard to solve. I noticed that with externalWindowHandle on linux, FSAA doesn't work due to the way the context is created. With parentWindowHandle, FSAA works, but it crashes randomly with the MESA driver (still not sure if that's an issue on Ogre's side or MESA)
- If you do something wrong, you get hard to track down problems (this is mostly when both libraries try to create a GFX context)
Q; There's already a SDL RenderWindow implementation in the source!
Yep, and it needs to be updated to SDL2.
The other problem is that it's a build time option, which is probably the reason that it's virtually unused and hasn't been touched in ages. We really need a unified implementation, 20 different build options don't help, especially for packaging and SDKs.
Cons:
- A new dependency to build (on the other hand, OIS would be dropped)
- Has a few extra features we may not need. On the other hand, threads and barriers might be useful later
- C api might be off-putting to some
SDL feature overview