Windowing Plugin System + SDL2 plugin

[madmarx]

I personnally prefer SFML, (since I teach with it) but it's not as if I was as much active as I used to be within Ogre3D community, so my advice should be taken with a grain of salt. It seems to me that both SDL2 or SFML are kind-ok. I will certainly not rant again SDL2 for the samples. VRPN is by far the most complete and supported I/O library, but is also completely overkill .

[sawyersam]

I'm new to using Ogre, but as a developer trying to use it on Mac OS X I am all for dumping OIS and fixing the windowing interface. Ogre should either make the effort to make cross platform input and windowing work properly or just depend on a project that does. I just wasted a decent amount of time because I had an xbox controller plugged-in from playing with my Oculus Rift (Kojack, you are awesome!). Apparently, having an Xbox controller plugged-in crashes OIS in createInputSystem() on Mac OS X (with tattiebogle.net driver). At first I thought maybe it was a bad interaction with the Oculus code since it just started happening. Tried another project without Oculus that used to work, didn't work. Crap, did some Mac OS X update break something? Is there a new mac port OIS? Will that even work? I remember reading something about OIS for Ogre being special somehow and reading some forum posts about issues with Cocoa. I'll check out the latest version of OIS source. Hmm.. something must be wrong. It's on sourceforge and looks abandoned. Oh thank god, found it on github. Hmm... what a terrible repository name. Oh shit, same as the sourceforge version. I guess I'll try to build OIS from source (oh, crap, xcode project file references xcode 2.2, guess I'm in for some fun). What about the Ogre-specific fixes I vaguely recall? After another search, I found the wiki page telling me to download a patch from the sourceforge issue tracker (uh oh, long list of unmerged patches). After patching and fixing up the xcode project file, building a debug version, and having the source handy, I could see it was crashing while trying to handle a joystick input type. Ugh! Unplug xbox controller and everything is back to normal. Invest some time and effort generating a patch for an abandoned project? Huge potential rat hole and not very appealing.

As for windowing, the demos for my Ogre 1.9.rc1? (haven't messed with it in awhile) SDK on Mac OS X has an annoying behavior with mouse capture. Sometimes, in order for the Ogre mouse cursor to function, I have to Command-Tab to another app to regain my cursor, position it where the Ogre window will appear, and then Command-Tab Ogre into the foreground (e.g. every time I start up the app). If I make a change under 'Configure' in the Sample Browser I also have to do another Command-Tab sequence to get my mouse cursor back. I'm usually running in fullscreen mode without a cursor so it doesn't matter so much to me, but it looks bad to people evaluating the potential use of Ogre on Mac OS X. If the mouse is positioned outside of the Ogre window and I Command-Tab into the Ogre window, the mouse cursor will not work. Before figuring out the Command-Tab trick, it just seemed like Ogre was broken on Mac OS X when I first played with the SampleBrowser. (maybe CGWarpMouseCursorPosition somewhere would help?)

[Gwenn_]

From what I read, opponents to the idea suggest that adding a dependency is wrong. What exactly is the problem with that ?

[Kojack]

From what I read, opponents to the idea suggest that adding a dependency is wrong. What exactly is the problem with that ?

Ogre is already pretty bloated, we should be trying to reduce dependencies rather than add them. Although adding is fine if it's carefully considered and provides a good benefit without making things worse for a segment of existing users.
The problem with SDL2 as a dependency is that it brings in a lot of other stuff that absolutely shouldn't be a dependency of Ogre, such as audio.
But it does sound like the advantages outweigh the disadvantages in this case. It still feels icky though.

[scrawl]

It's an optional dependency - if SDL is not found the SDL windowing plugin won't be built, but you can still use the (old) Ogre windowing plugin.
Similar to how the CgProgramManager plugin requires CG, but it is by no means required to use Ogre.

[Klaim]

Anyway, there is several setup being discussed here and there is a lot of confusion from people not having followed the different ideas.
Maybe we need a formal proposition or something like that to talk about a specific setup.

[Mako_energy]

It's an optional dependency - if SDL is not found the SDL windowing plugin won't be built, but you can still use the (old) Ogre windowing plugin.
Similar to how the CgProgramManager plugin requires CG, but it is by no means required to use Ogre.

If the Ogre provided windowing system is as terrible and buggy as people are saying and this change is used as an excuse to not fix it...then how optional is it really? Not just speaking of SDL, but using something other then Ogre windowing code.

From what I read, opponents to the idea suggest that adding a dependency is wrong. What exactly is the problem with that ?

As others have said it's bloat, adding code I don't need or want for one small detail. It also complicates the build system and it's one more thing that can go wrong and delay a release. In general it's best practice to keep things as lean as possible to minimize problems that could arise. Then again I'm one of those devs that avoids Boost like the plague.

[Jabberwocky]

I personnally prefer SFML,

I've used SFML too, and I much prefer its very clean C++ API over SDL2. It is very nicely written code.

But from what I understand, SDL2's windowing support on linux is much more robust. For example, I have read that currently there are still problems with SFML+linux+fullscreen. Also, given Valve's adoption and support of SDL2, I think it's a safer long-term bet. So I think SDL2 is still the proper choice.

If the Ogre provided windowing system is as terrible and buggy as people are saying and this change is used as an excuse to not fix it...then how optional is it really?

I understand your point. But I'd say the issues with Ogre's windowing system depend on what you're doing with it.

For example, I initially released my game windows-only, and Ogre worked totally fine for me. (However, I did have to patch OIS to support DirectX, as OIS's use of DirectInput doesn't fully support the XBox 360 controller).

It wasn't until I ported to linux, and needed to support full-screen that I ran into troubles.

So it depends on which platforms you're porting to, and what functionality (e.g. fullscreen support) you need on those platforms.

[Gwenn_]

From what I read, opponents to the idea suggest that adding a dependency is wrong. What exactly is the problem with that ?

Ogre is already pretty bloated, we should be trying to reduce dependencies rather than add them. Although adding is fine if it's carefully considered and provides a good benefit without making things worse for a segment of existing users.
The problem with SDL2 as a dependency is that it brings in a lot of other stuff that absolutely shouldn't be a dependency of Ogre, such as audio.
But it does sound like the advantages outweigh the disadvantages in this case. It still feels icky though.

Thing is : what is the purpose of Ogre ?

Okay, I know that : it's a general-purpose rendering software. But it already does additional stuff : it does windowing, user input, resource management (okay, that's a stretch) and it does these for a reason.
I understand the point that some users, maybe a lot of them, are using it for general-purpose stuff. But IMHO, most users are using it to make games out of it. So while Ogre shouldn't sacrifice the first category, I feel like addressing the second one's needs is a good idea.

Let's face it : Ogre is a complicated software. It's not a plug-and-play game engine, it's not a library with a few methods for fixed problems. It's a rendering engine, something that evolves very fast to keep up with technology and always needs extensive user work to make something out of it. Maybe bloating is actually a good thing, because it would remove work for the unexperienced developer who just want to "make it work", while maybe adding some bloat for the experienced one ?

[Kojack]

But it already does additional stuff : it does windowing, user input, resource management (okay, that's a stretch) and it does these for a reason.

Ogre has no user input.

[Gwenn_]

Samples need user input and windowing, therefore there is an official implementation of user input and windowing in Ogre samples. Samples that most users base their code on.

Now that we are done with the definitions, maybe we can discuss the point : what's the point of keeping Ogre a pure rendering engine, when other capabilities are fully implemented by the team and when these capabilities can be toggled out ?

[Klaim]

But it already does additional stuff : it does windowing, user input, resource management (okay, that's a stretch) and it does these for a reason.

Ogre has no user input.

Also, resource management will be removed from OgreMain and be provided by an optional plugin, to let you do the resource management specific to your app.

So basically, no input and no resource management, and in theory Ogre could not need any windowing code and just take a window handle to render in and ignore the rest of windowing features.

Samples need user input and windowing, therefore there is an official implementation of user input and windowing in Ogre samples. Samples that most users base their code on.

I use no sample code in my code and I'm a user. It's only examples, not a framework.
I use Ogre specifically because it will be plugged in the rest of my code, not the other way around.

Now that we are done with the definitions, maybe we can discuss the point : what's the point of keeping Ogre a pure rendering engine, when other capabilities are fully implemented by the team and when these capabilities can be toggled out ?

Ogre needs to stay a rendering frameworks. First because it's already a too much complex domain that suck up energy of a full dedicated team. There is no way the same team could do more. Second because I don't want a framework, I want a flexible rendering engine that I can use as I wish inside any kind of application. I don't want a pre-set environnement that forces me to use a specific set of tools so that the whole works, taking my app like if it was just an extension.

There is no good argument for making Ogre a framework of anything, it's just not the purpose at all. If you need a framework, use one, maybe one that use ogre inside it.

[Fritznorm]

Samples need user input and windowing, therefore there is an official implementation of user input and windowing in Ogre samples. Samples that most users base their code on.

Now that we are done with the definitions, maybe we can discuss the point : what's the point of keeping Ogre a pure rendering engine, when other capabilities are fully implemented by the team and when these capabilities can be toggled out ?

The question that you are asking is really of defining where something stops being "Ogre" and starts being something else. The problem with extending Ogre beyond being simply a rendering engine is that you start to dramatically limit its audience because you make too many design choices on the part of the developer. This is the kind of thing that a game engine will have to do, for example, and that's okay because you can have a more consistent set of criteria for that particular use case.

But with Ogre, what seems to make more sense (given its more varied and eclectic usage) is for the team to focus on making it a really good rendering engine - this is a hard enough job on its own. The engine can then provide an interface to allow you to overlay a windowing system, and input system, etc. but crucially not try to make the choices for you. Default bits of code can be supplied to let new users start, and it would be good to encourage users of Ogre to contribute back wiki articles on combining other libraries with Ogre, but these are not *core* bits of the software.

This doesn't contribute much to the "SDL2 or not" question in this thread, but I think there are good reasons for suggesting that specific windowing systems might be supplied with the samples, but mustn't be an additional dependency for the core. The core should just provide an adequate interface to allow a windowing system to be written on top of it. The question is, does it?

[Mako_energy]

Thing is : what is the purpose of Ogre ?

Okay, I know that : it's a general-purpose rendering software. But it already does additional stuff : it does windowing, user input, resource management (okay, that's a stretch) and it does these for a reason.
I understand the point that some users, maybe a lot of them, are using it for general-purpose stuff. But IMHO, most users are using it to make games out of it. So while Ogre shouldn't sacrifice the first category, I feel like addressing the second one's needs is a good idea.

Let's face it : Ogre is a complicated software. It's not a plug-and-play game engine, it's not a library with a few methods for fixed problems. It's a rendering engine, something that evolves very fast to keep up with technology and always needs extensive user work to make something out of it. Maybe bloating is actually a good thing, because it would remove work for the unexperienced developer who just want to "make it work", while maybe adding some bloat for the experienced one ?

I agree that Ogre is a very confused library that tries to do more then just rendering. It's halfway between a rendering engine and a game engine. Where disagree is whether or not this is a good thing. I think this is horrible and alienating. If you want an all in one solution, there are plenty out there...OgreKit or NeoAxis to name a couple that use Ogre (and I hope to one day add my engine to that list). Ogre itself shouldn't try to become this this though, because then it'll lose it's utility as an engine component. As klaim said, once you get to the point where you are trying to provide a larger and more complete solution you have to make design decisions for the user. People working lower level and with more strict goals for an actual release and profit do not like this.

There are a couple examples of Ogre trying to force design decisions in my personal experience alone:
1) The Resource system is a complicated mess of interfaces that was clearly originally designed with only filesystems and archives in mind. It's fine for simple samples on desktop computers, but doesn't provide good hooks for network resources. Nor does it provide adequate hooks for you to completely control the loading of dependent resources (like a mesh loading a material it uses). Bypassing this is non-trivial.
2) The WorkQueue, which was designed to be a threading solution for Ogres components that need one (terrain and paging mostly), is completely counter to the threading model/library that we have chosen as ideal for our engine. Right now it's not causing an issue because I haven't started dabbling into the components that use it and I'm hoping that the WorkQueue will get the axe(with refactors to the other components) before I have to dive into that mess.

Hobbyists and inexperienced developers can use other solutions if they want something quick and easy to demo. I'm pretty sure most or all of the more experienced Ogre developers in this thread/forum could share at least one story about how they had to engineer around Ogre's design to get what they want. That is work, time, and money wasted. Adding bloat invites these issues.

To make a comment on the SDL2 topic at hand, I am still in the "Just fix it" camp. I really don't understand the work involved to fix it, so maybe someone can enlighten me on some of the details. How much of the work is in the form of applying updates and fixes to the existing code vs ongoing maintainence? Is the scope of work something that would be appropriate for next years GSOC? Is looking at SDL2 to gleam ideas for an implementation in Ogre something that would feasibly cut down on the time it would take to create an in-ogre solution? I'd also like to note that this doesn't eliminate the need or desire for a window management plugin system, which I am entire for. This would just mean another solution would be available without any mandatory bloat on any platform.

[AlexeyKnyshev]

SDL is the best solution for windowing and input, but.... Anyone there know about unsigned convention in using OIS in pair window manager specific code in OGRE. The main reason for this - samples, they simply work on each officially supported platform.
As you know there is simple programmer's rule: "don't touch that works like a charm".

About SDL, it's quite easy to use it your project, something about 20 lines of code as I remember.

[FlorianGeorge]

If SDL/SDL2 would make it possible to compile Ogre out of the box on a Linux without X11, that would make Ogre (more) viable to be used on embedded systems that lack X11. Currently this is not (easily) possible, which is for the company I work at a severe limitation that might lead to us to having to drop Ogre as the used cross-platform renderer.

[cord]

If SDL/SDL2 would make it possible to compile Ogre out of the box on a Linux without X11, that would make Ogre (more) viable to be used on embedded systems that lack X11. Currently this is not (easily) possible, which is for the company I work at a severe limitation that might lead to us to having to drop Ogre as the used cross-platform renderer.

It's seriously easy to get Ogre to use SDL2 + OpenGL. I haven't tried getting OpenGL to work without X11 though...Is that where you're stuck?

[holocronweaver]

I am done with my initial implementation of SDL2 windowing for the GL3+ RS (thanks largely to code from cord and Jabberwocky!). Still need to test on Mac OS X, but it works great on Linux and Windows.

I plan to convert the sample browser to use SDL2 for I/O early next month. Unless someone has already started work on this?

[Jabberwocky]

[TheSHEEEP]

Go, go, go!

[scrawl]

I plan to convert the sample browser to use SDL2 for I/O early next month. Unless someone has already started work on this?

Does that include the windowing plugin API? Or how do you plan to hook them up? I think it would be a good idea to get the groundwork done first, then get to the candy
I actually had a try at this. What held me back was my wild ignorance of anything D3D. The D3D render systems are completely monolithic with regards to windowing at the moment, and I lack the expertise to fix it.
The GL rendersystems at least have (compile-time) swappable window implementations so they shouldn't be too difficult to fix.
I can tell you the API I had in mind.

WindowingInterface

This is an abstract, empty base class. Since window creation is render system specific, this class doesn't actually contain anything.

For example purposes, I'm now dealing with the GL RS only. Of course there'd also be a version of these classes for the other render systems.

< begin GL specific >
GLWindowingInterface : WindowingInterface

This is the windowing interface to be used by the GL RS. It'll basically be what the GLSupport and GLContext classes are right now - an API for creating GL windows, contexts and querying capabilities.

SDLGLWindowing : GLWindowingInterface
GLXGLWindowing : GLWindowingInterface

Here are the actual implementations of the GLWindowingInterface.

< / end GL specific >

The last piece in the puzzle are the plugins:

WindowingPlugin
- virtual WindowingInterface* getWindowingInterface (RenderSystemName);

SDLWindowingPlugin : WindowingPlugin
DefaultWindowingPlugin : WindowingPlugin

The user selects the wanted plugin in the plugins.cfg.
When a plugin is installed, it registers itself with Ogre::Root.
When a specific render system wants initialize, it asks Ogre::Root to supply a windowing implementation for this RenderSystem and for the currently selected windowing plugin. Root, in turn, will ask the currently active WindowingPlugin to return a windowing implementation for the wanted RenderSystem.
Since Root doesn't know anything about the implementation, it'll just return a WindowingInterface* - and since the GL render system knows that its, well, the GL render system, it can be downcasted to GLWindowingInterface* and that's all the GL RS needs to know. Under the hood it is a SDLGLWindowing, or whatever plugin is being used.

All of these classes should be part of a new "Plugins/Windowing/..." file structure.

Anyway, so the current roadblock is that I have no idea how a D3DWindowingInterface would look like.
Maybe we can implement this for GL rendersystems only, and let someone else can fix the rest?

[scrawl]

For anyone who may not be reading twitter, holocronweaver has started the work:

https://bitbucket.org/holocronweaver/og ... aa941ddc37
https://bitbucket.org/holocronweaver/og ... 06f9e12162

[ppd]

Tested SampleBrowser on SDL2 from holocronweaver's ogre-gl3plus-beta repo on Linux, and noticed that SDL cursor position doesn't correspond to real (i.e. X's) mouse cursor. It seems, that calling SDL_SetRelativeMouseMode every polling round resets pointer's history, and therefore effectively switches off acceleration. The results are funny - every time I've tried to get cursor to right side of the window, SDL's cursor appeared unaccelerated, invisible "real" one got out of the window, and SDL's got reset to left upper corner, irrespective of "real" position. One can observe this behaviour by switching on X's cursor (by not invoking SDL_ShowCursor(SDL_DISABLE)).

Calling SDL_SetRelativeMouseMode(SDL_TRUE) only once, in SDL init block (i.e. around line 684 SampleContext.h), and commenting out other appearances fixes the problem.

[holocronweaver]

It seems, that calling SDL_SetRelativeMouseMode every polling round resets pointer's history, and therefore effectively switches off acceleration.

Calling SDL_SetRelativeMouseMode(SDL_TRUE) only once, in SDL init block (i.e. around line 684 SampleContext.h), and commenting out other appearances fixes the problem.

Yeah, this was a hack when I was trying to debug a related problem with borderless windows in X11. I think I have tracked down the issue, but am not 100%.

While the current state of the repo was not meant to be test-ready, I am glad it runs for someone else. For those that are interested, in a few days I will be pushing a test-worthy version of SDL2 sample browser plus the new windowing system. I will post here when its ready to be put in the fryer.

[scrawl]

Last push was in february. Any chance we could get our hands on a WIP version at least?