Windowing Plugin System + SDL2 plugin

[Transporter]

There is no reason for me to add more dependencies like SDL to Ogre. I use Ogre's window code, Qt, MFC and pure WinAPI to create windows with Ogre content. I don't need SDL under Windows. OIS? Acceptable, but I also use DirectInput or the simple WinAPI to get inputs.

[TheSHEEEP]

If it is already certain that we need to get rid of OIS, two things seem possible:

1.) Have no input coming with Ogre. This is a bad idea. At least for samples, we need something, and then we can as well package it with Ogre like we do with OIS now.

2.) Replace it with something. If that something also improves window management, I don't see any downside. As long as the library is not too big and as long as you can still change window management to something else.

Any cross-platform solution is better than having to do something like Transporter describes for each platform.

[bcsanches]

2.) Replace it with something. If that something also improves window management, I don't see any downside. As long as the library is not too big and as long as you can still change window management to something else.

At first, I liked the idea of replacing the OIS and windoing system with SDL. But later, following the discussion it became clear for me that Ogre should not have a big dependency on Windowing system.

So for now, I think the best thing would be to keep Ogre not dependent on a specific windowing system. I like the freedom to plug it to anything that I wish. In my projects, first I started with my own input system using win32, later I switched to SDL (1.2) and I had no trouble plugging it to Ogre. So for me, Ogre is just a rendering engine, I create the window, give it to Ogre and I let ogre do its works.

So I think adding SDL to Ogre project only because of the windowing stuff is too heavyweight for it. I am not expert about ogre internal structure (I am using only it as a library and never did any big change to it), but is there any chance we can keep the windowing system as a external component? So ogre may have some interfaces about what it expects from windows and the existing windowing system can be moved to that component as a "ready implementation". If anyone wants to plug a different system, just create its own component. But I have no idea if moving the windowing system to an external component is possible or worth the effort.

I do not feel comfortable with Ogre providing a built-in input system, like a lot of people, I already have my own input layer and I do not want to have to carry another input system within my system.

In the discussion, I have the impression that all the problems that people discussed about OIS does not impact the samples, so I am wondering, is it worth the effort to drop OIS and build another input component only for the samples?

Just my 0,02 cents.

Best Regards

[Klaim]

As far as I understand, making Ogre totally dependent on a windowing library is NOT what is discussed here. The point is that Ogre will always allow to provide a window handle, but still need to provide a simple way to create a window.
Maybe a component providing window support, separate from Ogre's core, and adding a windowing library dependency, would be a nice solution as it would make clear that either you want Ogre to provide windowing and you'll have to have that additional dependency, or you do the windowing yourself with Ogre having no windowing dependency/code.
The samples would use that component, but maybe somone working with a specific windowing system would prefer to use "vanilla" Ogre.

[holocronweaver]

I agree with Klaim. I think the way forward is the creation of an OGRE windowing API. We can port the current OGRE windowing code to this API and if developers feel it is worthwhile, they can continue to maintain this code. Alternatively a dedicated library could be used via the same API, and an implementation for SDL2 could be included to serve both as an example of the new windowing API and as a more robust alternative to the native OGRE windowing library.

In the discussion, I have the impression that all the problems that people discussed about OIS does not impact the samples, so I am wondering, is it worth the effort to drop OIS and build another input component only for the samples?

OIS is no longer actively maintained and has lots of bugs that must be patched from time to time by OGRE devs. This is a drain on dev efforts and will only become more so as operating systems change their interfaces and more extensive changes to OIS are required. Thus moving away from OIS will save devs time now, but will save allot more time in the future.

[bcsanches]

OIS is no longer actively maintained and has lots of bugs that must be patched from time to time by OGRE devs. This is a drain on dev efforts and will only become more so as operating systems change their interfaces and more extensive changes to OIS are required. Thus moving away from OIS will save devs time now, but will save allot more time in the future.

thanks, it is clear now that dropping it will be a good thing for the project.

[dermont]

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.

Very informative post regarding the problems you encountered. This will really help those who have no interest in SDL resolve these issues.

I have seen all the problems you encountered above and believe most of them are fixable (on NVidia cards anyway) through either randr1.1/Xinerama or randr1.2/XRRScreenResources and updates to the glx code to handle multiple monitors. Any fixes though would probably never be as comprehensive as what SDL2 offers.

I understand you you've moved on to SDL and probably don't want to go into details on customers xinemara/metamode config setup. However regarding the 2nd monitor turning black on non default resolutions is this problem specific to Ogre or does this just happen with other programs.

[binarycrusader]

While there doesn't seem to be consensus on the windowing, can we at least agree that OIS should be dumped in favor of SDL2 if only for the samplebrowser, etc.?

It sure would make building and using Ogre3D a lot easier on some platforms.

I'm willing to do the work if no one else is able to.

[Mako_energy]

It doesn't seem to have been mentioned yet, so I feel compelled to mention that passing an external window handle into Ogre when creating the window is not the only way to integrate SDL and Ogre...assuming collecting input is the only thing you want to do.

It isn't documented in SDL because the methods weren't designed to work like this, but you can use the "CreateWindowFrom" method passing in the window handle after Ogre has created the window and SDL will collect input on it. I have done exactly this in my game engine and it works well on Windows, Linux, and MacOS. A couple notes on this though: I had to submit a couple of patches to get this working on Windows and Linux. The Windows patch was accepted and so it won't be an issue, but I haven't been able to verify (yet) that the Linux patch has been accepted. When we went to add support for MacOS it just worked. Also, I have only tested collecting input from a window using this method. Otherwise I have left Ogre in complete control of the window (when I go to resize for example).

Here's the code in our repo that does the integration:
https://github.com/BlackToppStudios/Mez ... w.cpp#L173

The highlighted line is where we create the window, the following lines we set up the SDL window and "link" them. After that input events are reported as you would expect in SDL.

[scrawl]

Thanks for the fixes.I had tried SDL_CreateWindowFrom back then but was encountering severe problems on windows as you mentioned. I might try it again some time.
Leaving Ogre in control of the window doesn't solve some of its issues though, eg the multi monitor bug on linux.

[Mako_energy]

I agree there are some nuanced issues with Ogre's windowing code(more than just the Linux bug you mentioned), but I don't feel that adding a dependency to OgreMain in order to solve them is a step in the right direction. They should just be bug fixed, while keeping the all the existing methods for integration with other windowing systems intact, or maybe even expanded. And then for samples integrate SDL the way I have demonstrated just to collect input.

[holocronweaver]

I don't feel that adding a dependency to OgreMain in order to solve them is a step in the right direction.

Again, I agree. If we instead create a new OGRE windowing API and port the existing OGRE windowing code to it, developers will be able to easily switch between windowing libraries at will so long as they have the necessary API implementation. OGRE could ship with an implementation for SDL2, but the native OGRE windowing library or some other library could be used if SDL2 is not available or not desired.

[holocronweaver]

Looking more carefully at the RenderWindow class as a OGRE windowing API, I find it already fulfills 90% of my needs. The rest, like multi-monitor support, could be added on. In addition, there is already a partially implemented SDLWindow for the GL and GL3+ render systems.

What is needed to add SDL2 support is a SDL2Window child class of RenderWindow for each render system. To make this easy to use, CMake and/or ogre config flags can be added to select windowing API. I will take care of this for the GL3+ RS.

I'm willing to do the work if no one else is able to.

If you want to go ahead with this, I would make a brief proposal outlining how you will do the replacement so that the OGRE devs can weigh in. They generally welcome contributions, but just in case this one is not welcome it is better to find that out BEFORE you do all the work and create a pull request.

[scrawl]

Please make it a plugin based system (eg Plugin_WindowingDefault and Plugin_WindowingSDL) instead of build options.
Much more flexible and otherwise it'd be hard to package the SDL version into a repo.
Also, you'll be able to add custom windowing plugins (e.g. QT) without rebuilding Ogre

[holocronweaver]

Please make it a plugin based system (eg Plugin_WindowingDefault and Plugin_WindowingSDL) instead of build options.

Good idea! I will probably start off using the current primitive build system approach to get the SDL2 support implemented in GL3+, then step back and add a plugin system for windowing. This can then be ported to the other RS.

[scrawl]

Rough roadmap -

- Test SDL2 RWs using the old (build option) approach first
- Move stock render window implementations to Plugin_WindowingDefault
- Add Plugin_WindowingSDL2
- Port samples to SDL input, kick OIS out
- Add examples for a few features to sample browser: hardware cursors, window icons (with the SDL windowing plugin, RenderWindow should be able to setWindowIcon(Ogre::Image image)) . Showing and hiding cursor, relative input.

Does that sound good to you guys?

[holocronweaver]

Does that sound good to you guys?

Yes, that is almost exactly what I had in mind, except I had not considered examples. Do you mean adding examples to the wiki? I will make sure there is a multi-monitor SDL2 example as this is a common problem OGRE users have to deal with and something the native windowing code does not handle well.

[binarycrusader]

Looking more carefully at the RenderWindow class as a OGRE windowing API, I find it already fulfills 90% of my needs. The rest, like multi-monitor support, could be added on. In addition, there is already a partially implemented SDLWindow for the GL and GL3+ render systems.

What is needed to add SDL2 support is a SDL2Window child class of RenderWindow for each render system. To make this easy to use, CMake and/or ogre config flags can be added to select windowing API. I will take care of this for the GL3+ RS.

I'm willing to do the work if no one else is able to.

If you want to go ahead with this, I would make a brief proposal outlining how you will do the replacement so that the OGRE devs can weigh in. They generally welcome contributions, but just in case this one is not welcome it is better to find that out BEFORE you do all the work and create a pull request.

To be clear, the only thing I'm able to commit to is the replacement of OIS with SDL2 for exactly the functionality OIS is used for now (input). I don't think there's anything controversial about that. Replacing the windowing code would require far more time than I'm able to commit to at the moment.

But as you said, before I venture off to do that, I'd like to be certain there are no objections to the complete replacement of OIS with SDL2.

Again, I'm not committing to nor have any desire to enter the windowing debate. This is strictly about using SDL2 as a replacement for OIS.

[masterfalcon]

SDL uses the zlib license and I'm no lawyer. Is that cool for us to include in SDKs?

[cord]

SDL uses the zlib license and I'm no lawyer. Is that cool for us to include in SDKs?

Yes, zlib licensed code can be freely

1. Integrated into an MIT-licensed project, e.g. Ogre. A zlib-licensed package can be relicensed and redistributed as MIT-licensed, as long as the redistribution does not misrepresent where the package is coming from.
2. Linked to, e.g. as a plugin that is zlib-licensed
3. Redistributed, e.g. all the same download links that Ogre currently uses for source and binary distribution
4. Resold, e.g. just like the MIT license a zlib-licensed project can be part of a commercial project

The zlib license does not require that you mention the authors in your documentation, but they say, "an acknowledgment in the product documentation would be appreciated but is not required."

The zlib license does require that you not misrepresent where you got the code, or attempt to distribute modified versions as if they are the original.

Disclaimer: I am not a lawyer.

[scrawl]

SDL uses the zlib license and I'm no lawyer. Is that cool for us to include in SDKs?

Of course. Just read the license text, its pretty short and clear imo.

[syedhs]

I think that is very fair to replace OIS with SDL2 in samples - and OIS itself is not in the core, so pretty clean to me. For one want to use SDL2 they can follow the samples, for one who doesn't want Ogre remains as it is..

[masterfalcon]

Well, I'd give it a thumbs up to go ahead and replace OIS with SDL2. Anyone else want to give their opinions?

[scrawl]

@masterfalcon: I think it's rather clear at this point no one loves OIS any more I was rather hoping on some feedback on the roadmap I posted for creating a windowing plugin system. "Just" replacing OIS with SDL2 (without having it also handle windowing) will require using SDL_CreateWindowFrom, which was buggy on windows the last time I tried (I don't know if the fixes Mako_energy mentioned landed in an SDL release yet?)

[masterfalcon]

Yeah, I've never been a big fan of it. Mostly because I was forced to make fixes to it that I didn't want to spend time doing.

My apologies ahead of time, I have not been keeping up with this thread and haven't looked at SDL's API in ages.

Before I comment on moving to SDL2 for windows I have one question and it is quite important. A lot of users use Ogre to render into a viewport that is part of a larger window. Whether it's created via GTK+, Cocoa, Windows whatever, .NET, etc. Is that still possible if using SDL2.