Show Posts
1
General discussions / Thinking about converting...
« on: July 31, 2011, 01:28:11 am »
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.
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.