Windowing Plugin System + SDL2 plugin

Discussion area about developing or extending OGRE, adding plugins for it or building applications on it. No newbie questions please, use the Help forum for that.
scrawl
OGRE Expert User
OGRE Expert User
Posts: 1119
Joined: Sat Jan 01, 2011 7:57 pm
x 216

Windowing Plugin System + SDL2 plugin

Post by scrawl »

Edit: The plan now is to create a windowing plugin system and create an SDL2 plugin that allows using SDL2 + Ogre together natively (no buggy externalWindowHandle mess). I've preserved the original post below.




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:
- 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
Q: But Ogre is a rendering engine, who cares which input engine is used by the samples?

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
Last edited by scrawl on Thu Feb 27, 2014 7:24 pm, edited 2 times in total.
cord
Halfling
Posts: 59
Joined: Tue Oct 22, 2013 10:22 am
x 7

Re: Replace platform specific windowing with SDL2

Post by cord »

I'm working on Mac OS X so I see a few more SDL2 benefits specific to my platform:
  • The current OpenGL OSX code does not support resizing or closing (!!!) the window
  • The external window code needed for SDL and the integration process are broken on OS X, probably it is just a less-used feature on a less-used platform so no one noticed.
It only took about 15 minutes to get SDL support working, so I agree that SDL2 will work just fine.

There will be more work to update the demos and wiki than to actually integrate SDL2.
cord
Halfling
Posts: 59
Joined: Tue Oct 22, 2013 10:22 am
x 7

Re: Replace platform specific windowing with SDL2

Post by cord »

Here is my SDL2 support. I'm not submitting a patch on this or anything because I am probably doing it in a slightly more flexible (but harder to explain) way.

Put the files in RenderSystems/GL/src/SDL and RenderSystems/GL/include/SDL, then modify RenderSystems/GL/CMakeLists.txt to use them. I only use them on the OS X platform because the GLX code works with the SDL event system fine, so I don't need SDL for linux

On OSX, I install SDL2 with "brew install sdl2"

Note that some of the files were moved into the SDL folder, so you might want to delete files of the same name in RenderSystems/GL/src or RenderSystem/GL/include
Attachments
SDL.zip
one SDL2 implementation
(10.86 KiB) Downloaded 433 times
User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
x 56
Contact:

Re: Replace platform specific windowing with SDL2

Post by Klaim »

I must admit I've thought recently about switching to SFML (which is more C++ friendly thant SDL but don't have the support of Valve and is less cross platform) for inputs and window for some time for the same reasons.
So I don't see a problem using SDL2. However, I don't know the API but does it really cover enough high abstractions compared to what OIS provide? Or will there be a need to add some wrapper? I guess that would not be much work but I don't see it as a costless change.
User avatar
Zonder
Ogre Magi
Posts: 1168
Joined: Mon Aug 04, 2008 7:51 pm
Location: Manchester - England
x 73

Re: Replace platform specific windowing with SDL2

Post by Zonder »

Library size should be a factor as well.
There are 10 types of people in the world: Those who understand binary, and those who don't...
Transporter
Minaton
Posts: 933
Joined: Mon Mar 05, 2012 11:37 am
Location: Germany
x 110

Re: Replace platform specific windowing with SDL2

Post by Transporter »

scrawl wrote: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
I reject your proposal. As you already wrote, we'll get a new dependency because OIS is not required for OGRE core only for the samples. Also SDL is using DirectX and OpenGL by itself which might create conflicts with the renderers. Btw, if you use windows you can change the window title later without SDL.
scrawl
OGRE Expert User
OGRE Expert User
Posts: 1119
Joined: Sat Jan 01, 2011 7:57 pm
x 216

Re: Replace platform specific windowing with SDL2

Post by scrawl »

As you already wrote, we'll get a new dependency because OIS is not required for OGRE core only for the samples
Realistically, who uses only OgreCore? Almost no one. Maybe the visual tests. Therefore I do not see that as a big deal. It's still an inconvenience of course, but imo there are more advantages.
Also SDL is using DirectX and OpenGL by itself which might create conflicts with the renderers.
It's very easy to instruct SDL to not create a context and let Ogre create it as usual.
Btw, if you use windows you can change the window title later without SDL.
You can probably do that on any platform manually, but the point is that you need platform specific hacks.
Last edited by scrawl on Fri Oct 25, 2013 4:24 pm, edited 2 times in total.
scrawl
OGRE Expert User
OGRE Expert User
Posts: 1119
Joined: Sat Jan 01, 2011 7:57 pm
x 216

Re: Replace platform specific windowing with SDL2

Post by scrawl »

Zonder wrote:Library size should be a factor as well.
I would think that with static linking, the impact should be pretty small, but this needs to be tried out.
So I don't see a problem using SDL2. However, I don't know the API but does it really cover enough high abstractions compared to what OIS provide? Or will there be a need to add some wrapper? I guess that would not be much work but I don't see it as a costless change.
Well, it's all in C, so that might be a turn off, but other than that, I think it's pretty much on the same abstraction level.
Frankly, I like the event loop in SDL better than using 20 listeners when using OIS. It just feels like I'm in charge :)
User avatar
Jabberwocky
OGRE Moderator
OGRE Moderator
Posts: 2819
Joined: Mon Mar 05, 2007 11:17 pm
Location: Canada
x 218
Contact:

Re: Replace platform specific windowing with SDL2

Post by Jabberwocky »

I had to incorporate SDL2 into my game for the linux version.

From memory, here are some of the problems I encountered with Ogre on linux:
  • On multiple monitors, the game would display an improper resolution
  • On multiple monitors, the game would permanently screw up the resolution of the 2nd, non-active monitor, forcing the user to manually fix it themselves, which many users did not know how to do.
  • On multiple monitors, the game would turn the 2nd monitor black.
  • I believe there may have been some single monitor, fullscreen issues on certain linux window managers as well.
Using SDL2 fixed most or all of the problems I had.

From what I've read, linux's window manager code is an absolute mess. Even worse, each distro / WM has it's own unique quirks. Keeping on top of this requires a huge amount of effort, and a huge amount of expertise. I do not believe anyone on the Ogre team has the linux expertise to fix and maintain our linux / glx code.

SDL2 code is being actively developed, primarily because of Valve's push to support Steam on linux / SteamOS. I agree, from a linux perspective, that switching Ogre to use SDL2 is a very good idea.

I can understand people's objections. SDL2 does a lot more than just windowing, and so it's a heavyweight dependency for what we need it to do. But at least it is all completely open source (zlib licensed), so you can always mess with it if you need to. I had to hack it so I could use OIS, since my game was already written to use OIS.

I'm less aware of how necessary or useful SDL2 would be for OSX and windows. We do have Ogre team members who seem to do a good job of handling those platforms But I don't konw how much effort goes into that, which potentially could be allocated elsewhere if we switched to SDL2. Also, we could always lose one of those team members - whereas using SDL2 is more future-proof.

The advantages of SDL2 input over OIS sound pretty beneficial for all platforms.
Image
User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
x 56
Contact:

Re: Replace platform specific windowing with SDL2

Post by Klaim »

Just for the sake of making sure there is a minimum effort for maximum efficiency, if SDL2 is seriously considered by the Ogre team to replace OIS and the window creation implementation, then I suggest evaluating using SFML 2.x too as (except the lack of mobile support which is coming in the next version) it does provide the same features and "might" be less of a problem on library size (it's a set of separate libraries, input+window is just one) and maintainability (because it's modern c++).
As said SFML isn't supported as strongly as SDL2 but it's good to consider close alternatives when considering changing a dependency.
Owen
Google Summer of Code Student
Google Summer of Code Student
Posts: 91
Joined: Mon May 01, 2006 11:36 am
x 21

Re: Replace platform specific windowing with SDL2

Post by Owen »

scrawl wrote:
As you already wrote, we'll get a new dependency because OIS is not required for OGRE core only for the samples
Realistically, who uses only OgreCore? Almost no one. Maybe the visual tests. Therefore I do not see that as a big deal. It's still an inconvenience of course, but imo there are more advantages.
Except OIS is, as said, only a dependency of the samples. OgreOverlay and co don't depend upon it either.

Also, I ask: What about people who are today using externalWindowHandle and similar features? What of people integrating with wxWidgets, Gtk+ or Qt? SDL is, as said, a bigger dependency than many applications will want.

Perhaps what we are coming to is that there ought to be a better way to integrate external windowing libraries with Ogre. Maybe then we could deprecate the externalWindowHandle/co complexity, and perhaps even migrate to using SDL as the default windowing provider.

The interface for connecting to an external windowing toolkit is liable to look like the one for SDL anyhow.
User avatar
holocronweaver
Google Summer of Code Student
Google Summer of Code Student
Posts: 273
Joined: Mon Oct 29, 2012 8:52 pm
Location: Princeton, NJ
x 47

Re: Replace platform specific windowing with SDL2

Post by holocronweaver »

OGRE is meant to be a graphics API-agnostic rendering engine, not a window manager or user I/O library. Since OIS is no longer maintained and thus we need to move away from it anyways, now would be a good time to export windows management to a library built specifically for that purpose, allowing OGRE developers to focus on, well, OGRE the rendering engine. This is in line with the modular, purpose built design philosophy of OGRE. Less is more, one library for one purpose.

This is my summary of the PRO argument and I tend to agree with it.

I can only think of one compelling CON. OGRE is almost useless without a solid window manager, so SDL better be rock solid and have a bright future to take on such an important role. I am not knowledgeable enough about SDL to weigh this argument, but it is a serious concern for me.

Will some of the OGRE devs who work on windows management at the OS level please comment? I would also like to hear from more developers who have used SDL2.

Ideally we should have separate libraries for I/O and window management, so we can have best of the best and not put all our eggs in one basket, but if SDL2 happens to be the best in both categories then it would be the one to go with.
User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7157
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 534

Re: Replace platform specific windowing with SDL2

Post by Kojack »

It looks like OpenMorrowind was considering switching to SDL 2 with Ogre a while ago (no idea if they went ahead with it, I only found it on a quick google search).
But they stopped because:
After a bit of playing around, it looks like SDL2 isn't going to fit our needs. The sdl_input branch mostly works as intended under Linux, but even simple programs using SDL2 have non-trivial bugs under Windows. Unfortunately, I don't think using SDL 1.2 is an option either, since it has the same issues with keyboard grabbing under Linux as OIS has.

SDL might be an option later, but it looks like there isn't much attention being paid to Windows at this point in the development cycle, and using it now would cause more problems than it would solve.
https://forum.openmw.org/viewtopic.php? ... =40#p13159
That's from january, so I don't know how good support for windows is now in sdl 2.0.1. We'd want to do some testing on every platform before adding an audio/input/forcefeedback/sprite library as our way of window management.

It would be interesting to compare SDL 2's threading system to what we currently use from Boost.
scrawl
OGRE Expert User
OGRE Expert User
Posts: 1119
Joined: Sat Jan 01, 2011 7:57 pm
x 216

Re: Replace platform specific windowing with SDL2

Post by scrawl »

Klaim wrote: Just for the sake of making sure there is a minimum effort for maximum efficiency, if SDL2 is seriously considered by the Ogre team to replace OIS and the window creation implementation, then I suggest evaluating using SFML 2.x too as (except the lack of mobile support which is coming in the next version) it does provide the same features and "might" be less of a problem on library size (it's a set of separate libraries, input+window is just one) and maintainability (because it's modern c++).
As said SFML isn't supported as strongly as SDL2 but it's good to consider close alternatives when considering changing a dependency.
SFML is interesting. My only gripe with it is that it doesn't support force feedback. Not a terribly important feature, but if joysticks are supported, might as well do FF.
Being C++ is a plus of course, but shouldn't be the deciding factor, imo.
It would definitely help if the SDL guys made their library more modular like SFML is.
Kojack wrote:It looks like OpenMorrowind was considering switching to SDL 2 with Ogre a while ago (no idea if they went ahead with it, I only found it on a quick google search).
But they stopped because:
After a bit of playing around, it looks like SDL2 isn't going to fit our needs. The sdl_input branch mostly works as intended under Linux, but even simple programs using SDL2 have non-trivial bugs under Windows. Unfortunately, I don't think using SDL 1.2 is an option either, since it has the same issues with keyboard grabbing under Linux as OIS has.

SDL might be an option later, but it looks like there isn't much attention being paid to Windows at this point in the development cycle, and using it now would cause more problems than it would solve.
https://forum.openmw.org/viewtopic.php? ... =40#p13159
That's from january, so I don't know how good support for windows is now in sdl 2.0.1. We'd want to do some testing on every platform before adding an audio/input/forcefeedback/sprite library as our way of window management.
The windows problems are long fixed (we were using the pre release version of 2.0), and we already switched. It works great on all 3 platforms. The code for our integration layer can be found here.
Also, I ask: What about people who are today using externalWindowHandle and similar features? What of people integrating with wxWidgets, Gtk+ or Qt?
externalWindowHandle can stay as is, I guess.
Perhaps what we are coming to is that there ought to be a better way to integrate external windowing libraries with Ogre.
I have thought about that, too. First idea would be to allow the user to plug in his own RenderWindow implementation: Root::setRenderWindowImplementation (RenderWindow* myRenderWindow)
Unfortunately these implementations are again dependent on whether GL or DX is used, so not sure how solid that would turn out.
Last edited by scrawl on Fri Oct 25, 2013 9:10 pm, edited 2 times in total.
User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
x 56
Contact:

Re: Replace platform specific windowing with SDL2

Post by Klaim »

scrawl wrote: Unfortunately these implementations are again dependent on whether GL or DX is used, so not sure how solid that would turn out.
Also, SFML2 is GL only, which makes it unpractical in our case.
scrawl
OGRE Expert User
OGRE Expert User
Posts: 1119
Joined: Sat Jan 01, 2011 7:57 pm
x 216

Re: Replace platform specific windowing with SDL2

Post by scrawl »

Klaim wrote:
scrawl wrote: Unfortunately these implementations are again dependent on whether GL or DX is used, so not sure how solid that would turn out.
Also, SFML2 is GL only, which makes it unpractical in our case.
If it works anything like SDL, you can make it create a window without a gfx context.

You can even use SDL without DirectX support compiled in, and then let Ogre create a DX context on the created window.

But I haven't tried SFML so not sure if it works that way.
User avatar
lunkhound
Gremlin
Posts: 169
Joined: Sun Apr 29, 2012 1:03 am
Location: Santa Monica, California
x 19

Re: Replace platform specific windowing with SDL2

Post by lunkhound »

For the record, joystick hotplugging is possible with OIS (at least under Windows). Just handle the WM_DEVICECHANGE event, and destroy and recreate the OIS stuff.
cord
Halfling
Posts: 59
Joined: Tue Oct 22, 2013 10:22 am
x 7

Re: Replace platform specific windowing with SDL2

Post by cord »

holocronweaver wrote:OGRE is meant to be a graphics API-agnostic rendering engine, not a window manager or user I/O library. Since OIS is no longer maintained and thus we need to move away from it anyways, now would be a good time to export windows management to a library built specifically for that purpose, allowing OGRE developers to focus on, well, OGRE the rendering engine. This is in line with the modular, purpose built design philosophy of OGRE. Less is more, one library for one purpose.

This is my summary of the PRO argument and I tend to agree with it.

I can only think of one compelling CON. OGRE is almost useless without a solid window manager, so SDL better be rock solid and have a bright future to take on such an important role. I am not knowledgeable enough about SDL to weigh this argument, but it is a serious concern for me.

Will some of the OGRE devs who work on windows management at the OS level please comment? I would also like to hear from more developers who have used SDL2.

Ideally we should have separate libraries for I/O and window management, so we can have best of the best and not put all our eggs in one basket, but if SDL2 happens to be the best in both categories then it would be the one to go with.
I want to echo holocronweaver's idea. Integrating OGRE directly with SDL or SFML seems like the wrong approach. Users may want Qt or GTK+, yes?

Would it be possible to expose just a few functions and try to make OGRE platform agnostic? There is still the risk that everybody ends up just picking the "default" choice and the other platforms don't get as much testing. But if the interface is simple enough how much work could it be to get up and running with a new platform? Like, for example, the PlayStation4 dev kit.

I'm willing to try switching between SFML and SDL to check that switching is easy.
Transporter wrote:Also SDL is using DirectX and OpenGL by itself which might create conflicts with the renderers.
No, managing if / when SDL creates / destroys a render context is easy. SDL even supports starting up but not touching D3D or GL. I was able to find lots of examples by searching. As a last resort, just look at the source code to find out what SDL is doing.
User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
x 56
Contact:

Re: Replace platform specific windowing with SDL2

Post by Klaim »

scrawl wrote:
Klaim wrote:
scrawl wrote: Unfortunately these implementations are again dependent on whether GL or DX is used, so not sure how solid that would turn out.
Also, SFML2 is GL only, which makes it unpractical in our case.
If it works anything like SDL, you can make it create a window without a gfx context.

You can even use SDL without DirectX support compiled in, and then let Ogre create a DX context on the created window.

But I haven't tried SFML so not sure if it works that way.
Ah true!
AgentC
Kobold
Posts: 33
Joined: Tue Apr 24, 2012 11:24 am
x 5

Re: Replace platform specific windowing with SDL2

Post by AgentC »

SDL also has the possibility to hook itself into an existing window such as one created by Qt. I'm not completely sure if OpenGL pixel format choosing and context initialization works properly in that case though, so it may require API expansion / fixing. A SDL + Qt combo would naturally mean paying the SDL library footprint while not using it for much.

As for SFML vs SDL, my gut feeling is that SFML may be friendlier to use with its C++ API, but SDL's core developers have much longer experience with multi-platform low level system interfacing. With SDL you also get Android, iOS and Raspberry Pi support right now.
User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7157
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 534

Re: Replace platform specific windowing with SDL2

Post by Kojack »

I just did a quick release build (vc2012) with audio and rendering disabled in cmake (still got video, so should have the window stuff). The sdl2.dll is 574KB. That's not too bad (at least compared to the 8MB cg.dll we include). There might be more settings that can trim down the size, plus a static build will remove most stuff anyway.

Although the problem with custom cmake settings to disable bits is that people may see that ogre uses sdl2 and assume all of it (audio, etc) is available to them.
User avatar
Jabberwocky
OGRE Moderator
OGRE Moderator
Posts: 2819
Joined: Mon Mar 05, 2007 11:17 pm
Location: Canada
x 218
Contact:

Re: Replace platform specific windowing with SDL2

Post by Jabberwocky »

Kojack wrote:Although the problem with custom cmake settings to disable bits is that people may see that ogre uses sdl2 and assume all of it (audio, etc) is available to them.
For sure, some people will want to use these additional SDL2 features. Maybe just having a wiki article on how to build and include your own fully feature-enabled SDL2 would do the trick?
scrawl wrote:If it works anything like SDL, you can make it create a window without a gfx context.
This was the key under linux+ogre+SDL2 to get everything working properly. If you let Ogre create the context, everything worked great. If SDL2 did, there were problems at the very least with framebuffer objects, which messed with shadows and RTTs in general.
Image
dermont
Bugbear
Posts: 812
Joined: Thu Dec 09, 2004 2:51 am
x 42

Re: Replace platform specific windowing with SDL2

Post by dermont »

I don't see this as a good idea at all. The functionality already exists that allow the use of SDL or whatever via external/parent window handle or external GLContext.

If there are problems using the existing Ogre GLX windowing system and randr then why not address them.

For example it's not Ogre's fault that for Nvidia there is Xinerama/NVidia Xinerama/metamodes/randr v1.1/earlier drivers wrongly reporting randrv1.2 support/randrv1.2+. No wonder some (especially older) windows managers encounter difficulties.
User avatar
holocronweaver
Google Summer of Code Student
Google Summer of Code Student
Posts: 273
Joined: Mon Oct 29, 2012 8:52 pm
Location: Princeton, NJ
x 47

Re: Replace platform specific windowing with SDL2

Post by holocronweaver »

dermont wrote:If there are problems using the existing Ogre GLX windowing system and randr then why not address them.
What are your reasons for wanting to keep the OGRE-maintained windowing code?
dermont
Bugbear
Posts: 812
Joined: Thu Dec 09, 2004 2:51 am
x 42

Re: Replace platform specific windowing with SDL2

Post by dermont »

holocronweaver wrote: What are your reasons for wanting to keep the OGRE-maintained windowing code?
As I said the versatility of the current OGRE-maintained windowing code, it's very easy to combine with Qt/Wx/fltk/gtk+/X/whatever and run your own event input/loop. Even this and other threads show how easy it is to hook up to SDL.

If I understand correctly the proposal is to use OGRE directly with SDL and therefore SDL would now be a prerequisite. What about the users that don't want to use SDL?

Will there be a "createRenderTarget" method (i.e. "createRenderWindow" without windowing/ say passing in external drawable) that will allow users to at least maintain some of the existing functionality without having to build against SDL?

Even then you would need SDL to build the samples and some users wouldn't bother. How would that help identify bugs etc? There is already a SDL plugin, why can that not be used?

What is going to happen when there are problems (and there will be) with window settings/placements/managers, do we head over to the SDL forums?

What about third party libraries such as python-ogre? Do I have to wrap some of the functionality of SDL to python just to able to use ogre.

Anyway everyone will have their own preferences to use/not to use SDL. I guess any reason wouldn't make any difference to whether a new SDLOgre is implemented.
Post Reply