Thinking about converting...

[Mako_energy]

I'm currently developing a game engine and so far I've been using SDL to handle Windowing and Input.  SDL has started to become slightly on the complicated side since we updated to 1.3, and SDL's founder leaving the project a bit ago has me wondering if there is something better.  

This isn't actually the first time I've looked at SFML, I tried to take a look at it once before a while ago and couldn't get it to cooperate with Ogre, so I gave up on SFML.  This is one of the things I'd need to convert.  Here's a more complete list:

1) The ability to either bind Ogre to a window created by SFML(or the created context), or the ability for SMFL to use a window created by Ogre and gather input from it(as stated above).
(just before posting this I double checked some of the doc's, and SMFL does seem to be able to construct a window from an existing handle, would that be applicable to what I need?)

2) In addition to the 3 major PC platforms, support for mobile platforms.  iOS especially would be mandatory.  Android and WebOS would be nice, but not *required*.  From what I read when skimming the forums before posting this, it sounded like a major internal change which could occur with a new major release would need to happen to support this, and it sounds like there is one coming up, so I'm a bit hopeful for this.

3) I noticed a few things mentioning threads in SFML, does SFML have threaded code internally?  Or are they just there for the programmers convenience?  I need to have complete control over how the available threads are distributed to the systems in my engine, so if they are just convenience, then awesome.  Otherwise I'd need a way to override(such that I can provide the needed threads through my system) the internal threads.

4) The Input that you can grab from a window is a bit too simplified.  Is there any way I can get some of the internal data about the input and possibly inject it into my existing input handling system?  Even if it's just a list of all inputs generated per frame.

5) SDL 1.2 is coded so that any change to the context, such as toggling fullscreen or resizing causes the context to be reset.  This is actually what prompted me to upgrade to SDL 1.3.  Can SFML change common window settings without having to reset the context?  (I'm 90% sure it can, but confirmation is always nice)

That is the current list I can recall cause I wasn't smart enough to write down the concerns while I was thinking of them.  I'm sure I'll think of more later.  Any clarification on any of these questions would be greatly appreciated.

[Laurent]

Hi

1) Both SFML and Ogre can use windows created externally, but I don't know if they can mix well, since they both create their own OpenGL context. Why do you want to mix them?

2) I plan to support iOS in a future 2.x release, but not in 2.0.

3) SFML only creates threads in its audio module: streams/musics run in a separate thread created by SFML, and sounds are played in threads that are internal to OpenAL. And there's no way to override these.

4) In SFML 1.6, sf::Input simply relies on windows events. So you can replace it with your own input system easily. In SFML 2, events are still available but sf::Input has been replaced with sf::Joystick, sf::Mouse and sf::Keyboard that directly retrieve the device state from the OS, they are not connected to windows events anymore

5) SFML can change almost all settings without creating the context, except switching to fullscreen (but that may be improved one day)

[Mako_energy]

If there is no way to set SFML to not create it's own context and instead use a pre-made one, then I'd have to set Ogre to use the one made by SFML.  Still do-able, assuming I can get the Window handle from SFML, but not ideal.  Ideally I'd like to have Ogre control the window, and SFML collect input from the window.  This is the primary reason I want to mix them and is what I'm currently using SDL for(as a cross platform input handler).  I've looked at OIS and wasn't really impressed by it.

Additionally we haven't implemented networking in our engine just yet, and we were going to use Boost ASIO, but I'd like to avoid using boost if possible.  So SFML would give us that additional option.

I had no idea that OpenAL makes it's own threads internally, thanks for that heads up(we're using OpenAL for sound as well).

So it seems that SFML doesn't have everything I would need to convert, but may be updated in the future to have them.  So I guess I'll closely watch SFML's progress and hope some of these changes happen sooner rather then later.  Thanks for answering my questions Laurent.

[Laurent]

assuming I can get the Window handle from SFML

sf::Window::GetSystemHandle() (in SFML 2).

I've looked at OIS and wasn't really impressed by it

Unless it has major drawbacks, it shouldn't be worse than SFML. SFML only supports basic input stuff, nothing really fancy.
But anyway, SFML is not made for being used as an input system on top of an external window, so I think it's a bad idea.