Windowing Plugin System + SDL2 plugin

[scrawl]

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.

Take a look at the roadmap I posted. The "current approach" you are talking about would be preserved perfectly in the default windowing plugin. Therefore no one's existing projects would be broken even.
Again, the idea is NOT to force adoption of SDL universally on everyone. We provide several plugins and you can use what you want. You can continue using OIS as well if you so desire.
And again, the problem with the custom/external window support right now is that it's a complete mess (understandably, when you're combining libraries that clearly weren't written with each other in mind). This has been discussed to death in this thread already. Take a look at Jabberwockys post for instance...

Bottom line: it is an optional new plugin, there's no breakage for anyone, therefore I don't see a disadvantage to be honest.

Which plugin is be used by the Ogre samples is another (less important) question, but since OIS does seem to be abandoned right now, SDL makes more sense.

[Jabberwocky]

Which plugin is be used by the Ogre samples is another (less important) question, but since OIS does seem to be abandoned right now, SDL makes more sense.

That's a good point. I suppose SDL2 could be mandatory for the samples, but not mandatory for Ogre in general. Which would allow us to remove OIS completely.

I should note this technical detail. I used SDL2 + OIS on linux. To accomplish this, I had to modify the SDL2 code myself to disable SDL input. There was no API to disable SDL input. And having both SDL input + OIS input active at the same time didn't jive.
Perhaps we could request this feature (using SDL without SDL input) from the SDL team, or provide a patch for it. It would be a simple code change. This would allow people to use our Ogre SDL2 windowing plugin, combined with some other input library, without having to modify the SDL2 code themselves.

[scrawl]

Perhaps we could request this feature (using SDL without SDL input) from the SDL team, or provide a patch for it. It would be a simple code change. This would allow people to use our Ogre SDL2 windowing plugin, combined with some other input library, without having to modify the SDL2 code themselves.

That is an interesting point. I have to wonder though about the use case. Why would I use SDL's windowing, but not decide to use it's input? Not really aware of any input library that currently matches SDL's features.
It's not like porting from an existing system (like when you're still used to OIS) would be a lot of work. Talking with the input library should usually happen at a pretty abstract level - if you have hundreds or thousands of calls to the input library in your code, you're probably doing something wrong.
Anyway, I still don't see a reason to not allow that, so a patch to SDL (like adding a flag SDL_INIT_INPUT) could be a good idea.

[holocronweaver]

Why would I use SDL's windowing, but not decide to use it's input? Not really aware of any input library that currently matches SDL's features.

Perhaps SDL2 is dominant in both cross-platform windowing and user I/O right now, but in the future this could change and developers should be able to swap out quickly. I prefer to keep my libraries as modular as possible so that I am never forced to choose between losing the parts of a library I like and suffering through the parts I don't. My time and energy is too precious to spend wrestling leviathan libraries.

[nedelman]

Perhaps SDL2 is dominant in both cross-platform windowing and user I/O right now, but in the future this could change and developers should be able to swap out quickly. I prefer to keep my libraries as modular as possible so that I am never forced to choose between losing the parts of a library I like and suffering through the parts I don't. My time and energy is too precious to spend wrestling leviathan libraries.

In that case it would make sense to just write your own input handling routines for each platform (which is what I do for most platforms). For the Ogre3D sample programs though it makes more sense to just go with a cross-platform solution that already works.

[holocronweaver]

In that case it would make sense to just write your own input handling routines for each platform (which is what I do for most platforms).

Open source exists largely so we can share our labor and not duplicate effort. Writing everything myself and not contributing back to the community is a last resort I intend to avoid. If things get really bad, I will just start my own open source library.

[nedelman]

In that case it would make sense to just write your own input handling routines for each platform (which is what I do for most platforms).

Open source exists largely so we can share our labor and not duplicate effort. Writing everything myself and not contributing back to the community is a last resort I intend to avoid. If things get really bad, I will just start my own open source library.

If you've done any amount of cross platform programming for input devices you'll quickly discover there's no clean way to cover every type of device type through an interface so that you can call getKeyboardKey(), getMultitouch(), getMouseAxis(), getJoystickAxis(), and so on in a totally generic and optimal way. To cover everything you end up hooking a lot of custom code into your application, which becomes a major project in itself, certainly far beyond the purpose of the Ogre3D samples.

What is being proposed here is whether SDL is appropriate for use with the Ogre3D samples. I'd say that, yes, it is. Your concern that SDL that might disappear and that Ogre3D developers should account for that seems a little paranoid.

[holocronweaver]

Your concern that SDL that might disappear and that Ogre3D developers should account for that seems a little paranoid.

I think you misunderstood me - I never suggested 'SDL might disappear'. I was saying that I prefer libraries which have dedicated purposes so that we can alway use the best of the best for OGRE. For example, if SDL2 has great I/O but there is a better library for windowing, we should not be stuck with shoddy windowing because we chose to use SDL2 for I/O in the samples.

[syedhs]

I prefer to keep my libraries as modular as possible so that I am never forced to choose between losing the parts of a library I like and suffering through the parts I don't. My time and energy is too precious to spend wrestling leviathan libraries.

A lot of times, to invest effort on some things which we foresee may or may not happen (code with modularity in mind) can be non-trivial.. so what I am trying to say here is we should put a little faith on our dependencies which in this case is SDL and then code our sample to use solely SDL2 and as a result, lots of time will be saved. And may I add, it is not easy to design for modularity.. and sometimes it ends up worse - with unnecessary code clutter here and there.

[holocronweaver]

we should put a little faith on our dependencies which in this case is SDL and then code our sample to use solely SDL2 and as a result, lots of time will be saved.

You mean making the samples require SDL2 for both windowing and I/O? I definitely agree we should require SDL2 I/O for the samples, unless someone can think of an incredibly clever I/O plugin interface. That would be awesome, but I cannot think of a way to achieve it. Requiring SDL2 for windowing should not be necessary, even for the samples, so long as some other windowing plugin is available and the user has the appropriate library installed. It would be sad to have a cool windowing plugin system and not get to show it off in the Sample Browser. Not to mention it may be necessary for systems we add which are not yet supported by SDL2.

And may I add, it is not easy to design for modularity.. and sometimes it ends up worse - with unnecessary code clutter here and there.

You are right. Sometimes achieving modularity requires more time than it saves. In the case of I/O and windowing the separation should be relatively trivial. After all, we are already doing it by using OIS with our own windowing code.

[binarycrusader]

Why would I use SDL's windowing, but not decide to use it's input? Not really aware of any input library that currently matches SDL's features.

Perhaps SDL2 is dominant in both cross-platform windowing and user I/O right now, but in the future this could change and developers should be able to swap out quickly. I prefer to keep my libraries as modular as possible so that I am never forced to choose between losing the parts of a library I like and suffering through the parts I don't. My time and energy is too precious to spend wrestling leviathan libraries.

I find that incredibly unlikely. SDL has been around since 1998. It has outlived a multitude of libraries from the same period, survived the death of its indirectly sponsoring company (Loki Software), survived a failed attempt at hybrid-licensing (just like Ogre3D used to have), and lived on.

Today, it is now part of hundreds of games on Steam enabling Mac/Linux ports of popular titles, and Valve themselves are using it.

What more serious endorsement do you need?

Personally, I think it's plain silly to keep the current Ogre3D windowing code or to keep maintaining it. It's a waste of precious little resources that Ogre3D has that could be spent on far more important things.

However, that's not my call, and I think the current plugin approach should assuage the concerns of even the most cautious developers.

[binarycrusader]

Your concern that SDL that might disappear and that Ogre3D developers should account for that seems a little paranoid.

I think you misunderstood me - I never suggested 'SDL might disappear'. I was saying that I prefer libraries which have dedicated purposes so that we can alway use the best of the best for OGRE. For example, if SDL2 has great I/O but there is a better library for windowing, we should not be stuck with shoddy windowing because we chose to use SDL2 for I/O in the samples.

At this point, I think it's safe to say that SDL2 represents the best cross-platform windowing library available.

The only other one I personally know of that comes close is GLFW.

But GLFW doesn't have the input management capabilities that SDL does (as an example). In particular, SDL's haptic support is far beyond any of the cross-platform libraries I'm aware of and is improving rapidly due the heroic efforts of the SDL project members and the increasing usage of it in Steam titles.

[binarycrusader]

we should put a little faith on our dependencies which in this case is SDL and then code our sample to use solely SDL2 and as a result, lots of time will be saved.

You mean making the samples require SDL2 for both windowing and I/O? I definitely agree we should require SDL2 I/O for the samples, unless someone can think of an incredibly clever I/O plugin interface. That would be awesome, but I cannot think of a way to achieve it. Requiring SDL2 for windowing should not be necessary, even for the samples, so long as some other windowing plugin is available and the user has the appropriate library installed. It would be sad to have a cool windowing plugin system and not get to show it off in the Sample Browser. Not to mention it may be necessary for systems we add which are not yet supported by SDL2.

I personally was assuming (despite my reservations about bothering to keep the decrepit windowing code in Ogre), that when I changed the samples to use SDL2, it would be only for input with precisely what you said above in mind. If there's going to be a plugin system for windowing, the samplebrowser is the place to demo it.

[Zonder]

Perhaps we could request this feature (using SDL without SDL input) from the SDL team, or provide a patch for it. It would be a simple code change. This would allow people to use our Ogre SDL2 windowing plugin, combined with some other input library, without having to modify the SDL2 code themselves.

That is an interesting point. I have to wonder though about the use case.

The use case is quite simple you have a project already using OIS and need to port to linux . Makes me think an option will be needed in the plugin on initialization.

[holocronweaver]

SDL has been around since 1998. It has outlived a multitude of libraries from the same period, survived the death of its indirectly sponsoring company (Loki Software), survived a failed attempt at hybrid-licensing (just like Ogre3D used to have), and lived on.

Over its long life, SDL1 spent much of its time abandoned and/or poorly maintained. (Not to say no one tried to maintain it, but they usually only met with partial success and there were insufficient maintainers to fully patch things up. The web is littered with SDL1 horror stories from seasoned developers. The SDL1 bug tracker was like a graveyard.) Hence the rise of alternatives such as SFML. SDL2, only released last year, is an attempt to take back the mantle that SDL1 held for a few years in the early 2000's. If anything, I would use the history of SDL1 as a cautionary tale about how a library is only as good as it is maintained and that initial forward momentum does not a good long-term library make.

Today, it is now part of hundreds of games on Steam enabling Mac/Linux ports of popular titles, and Valve themselves are using it. What more serious endorsement do you need?

I agree we should use SDL2 for I/O. However, it should not be required for windowing since the windowing plugin architecture makes such a requirement unnecessary.

Personally, I think it's plain silly to keep the current Ogre3D windowing code or to keep maintaining it. It's a waste of precious little resources that Ogre3D has that could be spent on far more important things.

I have no problems with porting the OGRE windowing code to a plugin if people find it useful and want to maintain it, even if I do not. If after the plugin architecture is widespread we find no one uses native OGRE windowing anymore, perhaps we should remove it then.

However, that's not my call, and I think the current plugin approach should assuage the concerns of even the most cautious developers.

I admit to erring on the side of caution in my business decisions. I also drive like a grandma. But hey - a decade of driving and no accidents!

[Kojack]

There was no API to disable SDL input. And having both SDL input + OIS input active at the same time didn't jive.
Perhaps we could request this feature (using SDL without SDL input) from the SDL team, or provide a patch for it. It would be a simple code change. This would allow people to use our Ogre SDL2 windowing plugin, combined with some other input library, without having to modify the SDL2 code themselves.

That's an odd design decision (SDL's, not yours). SDL has individual subsystem initialisation for timers, events, audio, video, joysticks, haptic devices and gamecontrollers using the SDL_Init or SDL_InitSubSystem calls. But it's mouse and keyboard input can't be individually controlled? Why?
I wonder if the mouse issue is only on linux?

The library that opens a window for ogre really shouldn't dictate how we handle input. I use my own input library in most cases.

Hmm, I just tried a quick test of sdl2. I couldn't get it to work at first due to linking errors. Turns out SDL2 uses a macro to hijack the main function so it can set itself up and redirect std out and err to files. I had a main that looked like int main(), that's not acceptable to SDL2. I had to add the command line argument parameters.

[AgentC]

Hmm, I just tried a quick test of sdl2. I couldn't get it to work at first due to linking errors. Turns out SDL2 uses a macro to hijack the main function so it can set itself up and redirect std out and err to files. I had a main that looked like int main(), that's not acceptable to SDL2. I had to add the command line argument parameters.

In my own work I've had to fork SDL2 and do some modifications to overcome various SDL initialization and linking issues that particularly have to do with Windows. For example in a certain case (the ifdefs seem to be only for Watcom compiler, but they also trigger on MSVC) it would define the _DllMainCRTStartup function, which would interfere with normal CRT initialization when being compiled inside a DLL. I believe it's an awesome library for what it does, but it does have somewhat of a god complex. It's also prepared to implement malloc by itself if you let it

So using an unmodified SDL2 with Ogre, at least in its current form, can present some problems. However I'd assume the developers are happy to incorporate fixes when well justified.

[Klaim]

For information, SFML too have input associated with windowing. Most users will not complain as you still need a window to extract input from, at least on windows.

[AgentC]

It is quite natural to combine input and windowing also because the OS also gives window state updates like close button pressed, window minimized, window maximized. And if the input library already defines a set of events (like SDL does) these notifications can define their own event types and go into the same input event queue. If the input and windowing libs are separate then it needs to be decided which library actually handles these. Probably the windowing lib as they're quite critical to the app lifecycle even if the app itself is just rendering and doesn't care of input at all.

[scrawl]

Hmm, I just tried a quick test of sdl2. I couldn't get it to work at first due to linking errors. Turns out SDL2 uses a macro to hijack the main function so it can set itself up and redirect std out and err to files. I had a main that looked like int main(), that's not acceptable to SDL2.

The purpose of the SDL2main library is to provide a common main function for all supported platforms, but you are not required to use it.

"SDL2main provides SDL_main(), which is a global entry point for all SDL apps. You are not required/forced to use it, but is presence is based on the variety of the systems SDL supports. Windows uses WinMain(), Linux uses main(), Android needs JNI and some Java to actually use SDL, so SDL_main() makes things a little easier. "
http://forums.libsdl.org/viewtopic.php? ... 9b8dc87980

You can prevent the main function from being wrapped by just not including SDL_main.h and not linking with the SDL2main library.

I've had to fork SDL2 and do some modifications to overcome various SDL initialization and linking issues that particularly have to do with Windows. it would define the _DllMainCRTStartup function, which would interfere with normal CRT initialization when being compiled inside a DLL.

You don't need to modify SDL to prevent this. Just don't link SDL2main library when you are building another library with it. In FindSDL2.cmake, there's a variable SDL2_BUILDING_LIBRARY you can set to automatically do this.

[Kojack]

You can prevent the main function from being wrapped by just not including SDL_main.h and not linking with the SDL2main library.

sdl_main.h is included by sdl.h, which is required to get the subsystem init enums and functions like SDL_Init

[scrawl]

Right. What I should have said is: Don't include SDL in your main file. (Which shouldn't be too difficult - usually your main file should just construct an Application object defined somewhere else).
Alternatively, you can just #define SDL_MAIN_HANDLED which will stop SDL from using the main macro.

[binarycrusader]

There was no API to disable SDL input. And having both SDL input + OIS input active at the same time didn't jive.
Perhaps we could request this feature (using SDL without SDL input) from the SDL team, or provide a patch for it. It would be a simple code change. This would allow people to use our Ogre SDL2 windowing plugin, combined with some other input library, without having to modify the SDL2 code themselves.

That's an odd design decision (SDL's, not yours). SDL has individual subsystem initialisation for timers, events, audio, video, joysticks, haptic devices and gamecontrollers using the SDL_Init or SDL_InitSubSystem calls. But it's mouse and keyboard input can't be individually controlled? Why?
I wonder if the mouse issue is only on linux?

The library that opens a window for ogre really shouldn't dictate how we handle input. I use my own input library in most cases.

Hmm, I just tried a quick test of sdl2. I couldn't get it to work at first due to linking errors. Turns out SDL2 uses a macro to hijack the main function so it can set itself up and redirect std out and err to files. I had a main that looked like int main(), that's not acceptable to SDL2. I had to add the command line argument parameters.

Barring bugs, use of SDL_Main is completely optional; see the migration guide:

http://wiki.libsdl.org/MigrationGuide

According to Sam Lantinga:

If you don't want SDL to redefine your main function, just
define SDL_MAIN_HANDLED before you include SDL.h, and then
call SDL_SetMainReady() before you call SDL_Init().

http://lists.libsdl.org/pipermail/sdl-l ... 88747.html

[scrawl]

On a related note, Wayland support just landed in SDL2

[Jabberwocky]

Cool, and very relevant to this discussion. This is exactly why, for linux at least, it would be great to piggy-back on the ongoing open-source work of other experts in the field.