Should I go from SDL to SFML?

[Ulrezaj]

Hello everybody!

First of all congrats for the people working on SFML, the library seems very nice. I'm on windows 7 but I saw that with some DLL's it would run on so I guess it's okay ; ) .

I am currently working on a 2D project in C/C++ with SDL and i was wondering to change to SFML since i read some benchmark stuff, and it's oriented object.

The problem for me is not the speed of the library but the weight and the different methods available:

>> I read somewhere that sf::Image is a heavy class, does this mean that I can't load many pictures on the screen? Or maybe I didn't understand  correctly what did you mean.

>>Are there any methods to extract a pixel from a picture (virtual or not (displayed or not)) and get the R,G,B,Alpha values like SDL_GetRGB does?

>>Is the blitting method (with clip etc.) and the key-event management work close to what SDL was doing?

>>Would you suggest me really to change my implementation and go from SDL to SFML? (since it'll require some time to reorganize all the stuff!)

I just passed through the documentation so I'm not that informed yet : ).

Regards

[Laurent]

Hi

>> I read somewhere that sf::Image is a heavy class, does this mean that I can't load many pictures on the screen? Or maybe I didn't understand correctly what did you mean.

No, it means that sf::Image holds the pixels of the image, and may be expensive to copy and manipulate in real-time. This paragraph is there to prevent users from misusing this class, it doesn't mean that SFML has some sort of limitations.

>>Are there any methods to extract a pixel from a picture (virtual or not (displayed or not)) and get the R,G,B,Alpha values like SDL_GetRGB does?

Yes, see the documentation of the sf::Image class.

>>Is the blitting method (with clip etc.) and the key-event management work close to what SDL was doing?

The event management is quite close to what SDL does, but drawing is different.
With SDL, surfaces are arrays of pixels, and "draw" operations simply consist of copying these pixels on other surfaces. This is slow and not flexible.
With SFML, a draw operation consists of sending the geometry and texture data to the graphics card, and let it do the rasterization job. This is normally faster, and more flexible because you can use all the graphics states that the graphics card can handle (blending, transformations, ...) for free.

>>Would you suggest me really to change my implementation and go from SDL to SFML? (since it'll require some time to reorganize all the stuff!)

If you don't have a good reason to do so, no. I mean, is there anything wrong with your current SDL implementation?

[Xorlium]

Let me disagree with the maker of SFML and say yes, you should switch. SFML is so much cleaner than SDL that I learned a lot about code quality and what ease-of-use means just by using SFML.

I also started with SDL and thought it was pretty good, until I tried SFML. SDL sucks in comparison. I'm glad I switched. Now I'm (im)patiently wating for SFML 2.0...

[Recruit0]

If you need to manage the code, then you should switch to SFML. SFML is more "automated" than SDL (i.e. there's less stuff you have to deal with). If code maintenance isn't an issue (unlikely), then don't bother.

[Zoomulator]

If you need hardware accelerated graphics then SFML is the way to go. If you want software managed graphics keep going with SDL.
The only use I see for SDL is building old school tile based systems. Actually oldschool games over all, where pixel manipulation is a needed feature. Changing pixels in openGL textures is challenging and kindof messy compared to software loaded surfaces.
If you're using C++, you should use a C++ library like SFML. Using SDL is very clumsy in comparison, mainly since it's a C interface. (atleast the 1.2v I've been using. There's a new 1.3v in the making which seems more organized.)
I didn't change to SFML because of the graphics, event structures or even OO interface though. I had an elaborate library built up around SDL which I was satisfied with already, utilizing openGL through SDL to get the hardware acceleration. What made me switch was the SFML socket support for networking! Trying to use other socket solutions like boost::Asio was way too much effort, so SFML came as a fresh breeze in my bloated, cramped and hot SDL code base. I threw out all my SDL code and re-implement the graphics in just a few hours with SFML, using the already existing sprite class.

[Ulrezaj]

Thank you very much for your answers that I'm taking in consideration.
I'm doing some last tests and SFML doc read before changing (or not).
Actually, for the pixels, i don't need to change them, just to get the rgba values  : )
As Laurent said it is possible so it's good news!

[Ulrezaj]

Sorry for the doublepost.
I may have misread the documentation of SFML but I didn't find any clipping method for a sprite/image in drawable or the 2 mentionned classes.
Is it named differently?

[Laurent]

SFML doesn't implement real-time clipping (yet), but depending on what you want to achieve, there may be workarounds.

[Recruit0]

You can clip with glScissor... Unless that's not what you're talking about.