Windowing Plugin System + SDL2 plugin

[scrawl]

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.

Of course it is, you have two choices:
- Use the default (old) windowing plugin and use externalWindowHandle parameters just like before.
- Code a windowing plugin for the toolkit you using (GTK, Qt etc) which will provide RenderWindow implementations. If it's written well, it can also be pulled into the Ogre repo.
Either way, you wouldn't be using SDL at all, or even linking against it.

For users who do want SDL, it's as simple as using an Ogre copy that has the SDL plugin built and then loading that plugin. No need to bother any more with the externalWindowHandle mess.

[Mako_energy]

@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?)

When did you last try to do this?

Here's the report on the SDL bug tracker for the windows patch(my confirmation it was accepted and is in there):
http://hg.libsdl.org/SDL/rev/612b41c44af1

Sadly, it seems the Linux fix was never accepted. Luckily we saved the changes we made to the x11window class in SDL in a simple patch file:
https://github.com/BlackToppStudios/Mez ... 2013.patch

And it merits a repeat, the MacOS side didn't need any changes. Just worked when we tried to do this with a Cocoa window.

If you still have issues, I may be able to help with them. But we should move that discussion elsewhere if so.

[masterfalcon]

Alright, sounds like a decent plan.

Maybe I missed some details but the idea is to leave the current windowing intact, move it to a plugin and port other windowing apis to plugins as well?

[scrawl]

When did you last try to do this?

It was a few months ago.

If you still have issues, I may be able to help with them. But we should move that discussion elsewhere if so.

Not really interested in this any more, with the current plan we are not going to need SDL_CreateWindowFrom.

Alright, sounds like a decent plan.

Maybe I missed some details but the idea is to leave the current windowing intact, move it to a plugin and port other windowing apis to plugins as well?

That's the short summary, yeah.

[binarycrusader]

Not really interested in this any more, with the current plan we are not going to need SDL_CreateWindowFrom.

I'll need to use SDL_CreateWindowFrom to get the samples working, right? Since I assume the desired result was to change the sample browser / samples to use SDL for input, but continue to use Ogre for the windowing.

[sajty]

Has somebody tried my ois fork?
I have fixed all linux and windows issues that I had encountered.
Before the fixes ois was unusable on linux, but now it's usable!
https://github.com/sajty/ois

I don't like SDL 1.2's input system, because it is full of XSync and the windowing code is very crowded.
We even got reports from people, who can't get the input working on their linux box with SDL 1.2 embedded into Ogre. Game starts up, but keyboard and mouse is dead.
I never used SDL 2.0 so I can't say anything about that. Hopefully they have rewritten the input code.

[scrawl]

Has somebody tried my ois fork?
I have fixed all linux and windows issues that I had encountered.

Well, I have reports from <1% of users who randomly lose keyboard input after a period of time. Happens in OIS 1.3 too. Do you know anything about that problem?

SDL2 has been a LONG time coming and it's great. You should really take a look at it!

I'll need to use SDL_CreateWindowFrom to get the samples working, right? Since I assume the desired result was to change the sample browser / samples to use SDL for input, but continue to use Ogre for the windowing.

Actually, my idea was to make the samples use the SDL windowing plugin. The downside is that the default windowing plugin will receive less testing, but it'll probably still be used a lot from people who are unwilling to migrate from OIS. Plus, the visual tests don't need any input, so there's your test case for the default windowing plugin.

If there's enough request, we can add another build mode to make samples use default windowing plugin + SDL_CreateWindowFrom. Need to make sure it's not buggy on any platform though

[sajty]

Well, I have reports from <1% of users who randomly lose keyboard input after a period of time. Happens in OIS 1.3 too. Do you know anything about that problem)

Unbelievable that OIS 1.3 on Linux is working for 99% of the users! Nice work! When I had embedded SDL 1.2+Ogre into the WebBrowser I had randomly lost the input (similar situation than yours). It was caused by XServer crash when calling XSync. Creating a wrapper message handler and forwarding to SDL only important messages made it more stable, but SDL calls XSync too much so even after that it crashed sometimes. Ask the <1% to check the XServer logs for the reason. I have fixed lot of Linux issues, but I don't remember if I had fixed crashes (I wrote the fixes 2 years ago). Ask them to try it if nothing else works.
Also on windows the SDL1.2 had huge input latency! At least 2 frames!
And if you grabbed the mouse in the corner of the window to move camera, the camera movement/frame was limited to the window frame, so if you grab when the mouse is 2 pixels from window border than in that direction you can rotate the camera 2 pixels/frame!

[scrawl]

Unbelievable that OIS 1.3 on Linux is working for 99% of the users

"Working", minus tons of (non-fatal) bugs and missing features.

. I have fixed lot of Linux issues, but I don't remember if I had fixed crashes (I wrote the fixes 2 years ago). Ask them to try it if nothing else works.

I already switched to SDL2 for that project

And if you grabbed the mouse in the corner of the window to move camera, the camera movement/frame was limited to the window frame, so if you grab when the camera is 2 pixels from window border than in that direction you can rotate the camera 2 pixels/frame!

Just warp the mouse to the center of the screen before grabbing it?
Anyway, SDL2 has a relative input mode on X11. It only works in fullscreen, but you can still fake relative input by warping the mouse to the center of the window every frame. Which seems to be the only way of doing it in windowed mode. Yeah, X11 is a mess.

I can't confirm there's input latency in SDL2 either.

[Jabberwocky]

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

At least for linux, this is extremely complicated. It can't just be fixed. Very few people in the world (and certainly no one on the Ogre team) has the expertise needed to fix these problems properly. Feel free to download SDL2, look at the source code, and see how complex it is to deal with the variety of linux windows managers. And worse - it's a moving target. linux is trying to sort it's window manager issues out, but this involves future changes which will result in even more linux window manager branches to support.

SDL2 does this for us. So at least for linux, using SDL2 for windowing is an extremely good idea.
I would far rather the Ogre team be working on things they're good at (rendering functionality) rather than trying and probably failing to fix things they're bad at (e.g. linux windowing code).

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).

I absolutely agree users should not be stuck with SDL2. However, we do need a default option that works out of the box, both for windowing and input. The trick is to make this easily replaceable for folks who want something else.

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.

+1

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.

Yes, this is important. Using SDL_CreateWindowFrom does not solve the linux fullscreen and dual monitor problem.

• SDL must create the window.
• Ogre3D must use the SDL-created window
• Ogre3D should create the opengl context, NOT SDL.

In case it helps, I'm going to attach some source code from Salvation Prophecy, which includes the setup code for SDL2 on linux. I do this with great hesitation, because this code is some of the messiest in my game. It has been repeatedly patched to deal with various hardware, windows and linux port issues, much of which was added post-ship (so I didn't want to drastically refactor the code).

The important bit is in function GraphicsSystem::InitSDL.

[scrawl]

Ogre3D should create the opengl context, NOT SDL.

I feel like the problems when SDL created the context may be due to the external window code. There are lots of complex OpenGL engines on top of SDL and none of them seem to have problems with FBOs like you encountered. So given that this can most likely be fixed when using SDL directly, we should be trying to let SDL create the context, since that's again less platform specific and possibly buggy code on our side.
Plus, I've also encountered issues when Ogre creates a context for a window created by SDL, which I'm not sure how to fix, see https://ogre3d.atlassian.net/browse/OGRE-319 and https://ogre3d.atlassian.net/browse/OGRE-318

[holocronweaver]

this code is some of the messiest in my game.

Do you write blog posts in all your source files?

You are too hard on yourself - the code is fairly clean and easy to read. If this is your messy code, I would love to see a a sample of your neat code. Thanks for contribution - lots of great notes to keep in mind for my own projects. I will squirrel this away for when I work on SDL2 windowing in GL3+.

I've also encountered issues when Ogre creates a context for a window created by SDL, which I'm not sure how to fix, see https://ogre3d.atlassian.net/browse/OGRE-319 and https://ogre3d.atlassian.net/browse/OGRE-318

Thanks for pointing these reports out. I will probably experiment with both approaches, but will keep your points in mind.

[Jabberwocky]

we should be trying to let SDL create the context, since that's again less platform specific and possibly buggy code on our side.

Sure, that makes sense. Maybe someone with low-level gl expertise than I can get that to work. I couldn't, though.

What's nice about the ogre-created context is you can use the existing glx code as is. But I'm all for any solution which works.

Regarding the bugs you posted - yeah, I ditched support for the open source drivers completely, and require the NVIDIA/AMD proprietary drivers. I think this is fairly common for a lot of linux games. But it would be nice to get the open source drivers to work too. I have no idea whether they're just fundamentally flawed or not.

Do you write blog posts in all your source files?

Heh.
Whenever I end up writing weird or complicated code, I always try to document the thought process of why it's there.

[Transporter]

Do you write blog posts in all your source files?

Heh.
Whenever I end up writing weird or complicated code, I always try to document the thought process of why it's there.

I love that! I have so many undocumented source codes. This drives my colleagues crazy.

[lunkhound]

Do you write blog posts in all your source files?

Heh.
Whenever I end up writing weird or complicated code, I always try to document the thought process of why it's there.

Thanks for sharing! Those comments are a real treasure-trove of hard-earned wisdom. Wow, supporting linux sounds like a huge pain in the ass!
Kinda surprised there was nothing about MacOS in there though...

[scrawl]

Wow, supporting linux sounds like a huge pain in the ass!

With the current external window system, yup. That is also kinda the point of this thread. With a "native" SDL plugin for Ogre, none of these hacks will be necessary (hopefully).

[Jabberwocky]

Agreed - getting an Ogre-based program to work acceptably well on linux right now is difficult, unless perhaps you want to limit yourself to non-fullscreen programs. Both Ogre and OIS cause problems.

[spacegaier]

Both Ogre and OIS cause problems.

Please create JIRA tickets for any concrete issue, so that we can try to eventually tackle them and improve . Or of course as usual: Directly provide a fix if you can . I am also in contact with the OIS creator on how to move forward...

[Jabberwocky]

Sure thing spacegaier - but I figure we should decide on this whole SDL2 thing first. If we decide to make the switch, then there's no point filing bugs in code we're no longer using.

[scrawl]

I figure we should decide on this whole SDL2 thing first

Haven't heard any objections yet

I am also in contact with the OIS creator on how to move forward

He still replies? Wow!
But yeah, agree with Jabberwocky that you might be wasting your time.

[spacegaier]

But yeah, agree with Jabberwocky that you might be wasting your time.

Until some minutes ago, I wasn't even aware of that thread, hence so far, I never was under that impression. Might change now ...

[nedelman]

I've used Ogre3D on Windows, OS X, iOS, Android, and Windows 8/RT/phone - not on Linux though - and I have to mostly disagree with adopting SDL universally for window creation and management. It makes more sense to use the current approach, which is to let Ogre3D create a simple window in the base case, and let the user/programmer supply a custom window if necessary. The only situation where I could agree with SDL being adopted is in the Linux version of Ogre3D, and that's only if SDL's window handling really does a better job of handling its Linux support than Ogre3D does.

As for using SDL for input handling, I'd definitely have to disagree with that as well. Input handling varies so widely from platform to platform (and even device to device) it makes more sense to get away from device-centric input handling and use higher level notions of mapping input device actions to application-specific events. But I think that's moving into a separate question of whether Ogre3D should have functionality beyond just graphics (I think it should).

Where I do agree is that I think it should be much easier for new users to get started with Ogre3D, not just with precompiled binaries and samples, but also being able to build from the full source code. I've been using Ogre3D for years now and even now I find that building these things to be a tedious and error prone process. Compare that to something like Cocos2DX where you download one source package and can then easily (compared to Ogre3D) build and run the SDK and samples across every platform.

[Transporter]

I've used Ogre3D on Windows, OS X, iOS, Android, and Windows 8/RT/phone - not on Linux though - and I have to mostly disagree with adopting SDL universally for window creation and management. It makes more sense to use the current approach, which is to let Ogre3D create a simple window in the base case, and let the user/programmer supply a custom window if necessary. The only situation where I could agree with SDL being adopted is in the Linux version of Ogre3D, and that's only if SDL's window handling really does a better job of handling its Linux support than Ogre3D does.

As for using SDL for input handling, I'd definitely have to disagree with that as well. Input handling varies so widely from platform to platform (and even device to device) it makes more sense to get away from device-centric input handling and use higher level notions of mapping input device actions to application-specific events. But I think that's moving into a separate question of whether Ogre3D should have functionality beyond just graphics (I think it does).

I agree!

Where I do agree is that I think it should be much easier for new users to get started with Ogre3D, not just with precompiled binaries and samples, but being able to build from the full source code. I've been using Ogre3D for years now and even now I find that building these things to be a tedious and error prone process. Compare that to something like Cocos2DX where you download one source package and can then easily (compared to Ogre3D) build and run the SDK and samples across every platform.

There is the intention to update the documentation (http://www.ogre3d.org/forums/viewtopic.php?f=4&t=78545). I also created a lot of small samples for debugging special functions of ogre. I could write a few wiki pages about them. Compiling is not that easy, but I have a couple of batch files, so it is just a few mouse clicks for me.

[Jabberwocky]

Here's a presentation by Valve on porting to linux - slide 8 says this:

Windowing issues

Consider SDL!
Handles all cross-platform windowing issues, including on mobile OSes.
Tight C implementation — everything you need, nothing you don’t.
Used for all Valve ports, and Linux Steam

Given Steam for linux, and the upcoming Steambox, it's pretty safe to say Valve now sets the standard of how to properly port games to linux. And their advice ain't bad for windows and mac, either. Also, there's some talk of a future PS4 port, which could is interesting!

The only situation where I could agree with SDL being adopted is in the Linux version of Ogre3D, and that's only if SDL's window handling really does a better job

Right - so I think this is where we stand:

• We need SDL2 for Ogre on linux.
• The benefits of using SDL2 across the board for other platforms is questionable - I'd be curious to hear from the various Ogre team members on this.

This leads to 2 reasonable plans:

Plan 1: Have an optional SDL2 plugin/component to handle windowing
Everything about ogre stays the same, but you can opt-in to use SDL2 if you want.

• (advantage) This fixes the linux problem.
• (advantage) This does not force Ogre users to use SDL2
• (disadvantage?) This does not leverage SDL2 to reduce the ogre team workload in maintaining windowing code on all the various platforms.
• (disadvantage?) This does not leverage SDL2 to provide a common windowing API across all the various platforms, which would seem cleaner.
• (disadvantage) We're stuck with OIS (because SDL2 is optional). Do we want to support both SDL2 input and OIS?

This is pretty similar to what scrawl proposed, except that I don't think we can remove OIS.
(edit) Or can we? See scrawl and my posts below (/edit)
Incidentally, another problem I've had with OIS is that avast anti-virus thinks it's a virus and deletes the dll.

Plan 2: SDL2 is a non-optional ogre component to handle all windowing

• (advantage) This fixes the linux problem.
• (disadvantage) This does force all Ogre users to use SDL2
• (advantage?) This does leverage SDL2 to reduce the ogre team workload in maintaining windowing code on all the various platforms.
• (advantage?) This does leverage SDL2 to provide a common windowing API across all the various platforms, which would seem cleaner.
• (advantage) We switch from a non-maintained input library (OIS) to a maintained input library (SDL2).

Feel free to add to those lists, if I'm missing anything.

It sounds like Plan 1 is the preferred plan for now. Which should be fine for everyone because SDL2 is optional.
Downline, if the SDL2 plugin/component proves to be workable across all platforms, maybe we consider moving to plan 2?
But, as noted above, I think this means we're stuck with OIS for now.

[Zonder]

OGRE doesn't require input but does require windowing. What is used in the samples doesn't really matter in my opinion and if we provide SDL windowing we should be using the SDL input for simplicity. What other people use is up to them at the end of the day. I do think windowing should be a plugin for this reason as well so people aren't tied to dependencies unless they want them.

Advantage for plugin: Porting to other platforms with closed architectures with closed source licenses with proprietary windowing.