Thinking about converting...

[Tomkeen]

Hello everyone,,
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) I have no idea how well Ogre can integrate into a SFML window. SFML can use an existing window, yes, but will still create its own OpenGL context for it. You mention "inputs", so this may not be applicable to you, but this might cause issues nevertheless. What kind of inputs do you need to catch? Do you need events, or just real-time state of input devices?

2) iOS and Android kind of work, but are not much maintained so you should test and see if your specific app works fine or not on your target devices. WebOS is not supported.

3) SFML uses internal threads, mostly in the audio module. Some classes directly use a thread (classes derived from SoundStream and SoundRecorder), and for the rest it's the audio back-end (OpenAL) which has its own threads. The rest are threading utilities, but you should ignore them and use what C++11 offers instead. You can't modify how SFML internally uses threads, but even if you could, you wouldn't be able to go one level lower (OpenAL, OpenGL, etc.) so that's probably an idea to forget.

4) You should give more details (what is "too simplified"? what "internal data" do you need? ...)

5) Yes

[eXpl0it3r]

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.

Any reason you remained with the SDL 1.x version instead of trying SDL 2.0?