Thank you fastcall22 and Serapth, this is really helpful.

I am wondering, is SFML 2.0 stable enough to base my whole project on it?
Also, if it is not, are there many things that need to be changed in my code in SMFL1.6<->SFML2.0 switch, or most of the calls remain the same and the changes are "behind the scenes" implementations?

Thanks for the sprite sheet implementation too, in SDL I just used a SDL_Rect[] as a possible offset to apply_surface, which was quite convenient, but this way I can do it in SFML too, and it's time I start getting familiar with some raw opengl too.

The differences aren't too major, you should be able to port without too much issue. You don't need to do a SDL_Rect implementation. Load an image as you would normally, but instead of using sf::Sprite, you use sf::Texture, which you can populate using LoadFromImage. The majority of other changes are small but annoying. The coordinate system for Sprites/Textures has been updated ( to make sense, the old naming convention was stupid ), obviously Texture was added for much the reasons of the problems you've run into, otherwise the biggest changes are input related. sf::Input is gone, replaced by two global namespaces.

I see, I'll port this early version to SFML 2.0, learn how input is working, and when everything seems comfortable I'll port my full project.

Input changed from using sf::RenderWindow.GetInput(), to two separate global methods sf::Keyboard and sf::Mouse

So, before you would go

myAppWindow->GetInput()->IsKeyDown(someKey);

You now do:

sf::Keyboard::IsKeyDown(someKey);


Ditto for mousing functions have also been split out. The change does make sense, but will potentially cause a number of changes to be required.

Well, I had a suggestion about why show was so slow using v1.6, when using SFML or SDL (even commenting out the SFML draw).

it looks like, in SDL, "part" is a pointer, while, when using SFML, it is not. Try setting the SFML version's part from Sf::Sprite part to Sf::Sprite *part.

It's probably all the copying it has to do.

[quote name='BeerNutts' timestamp='1326911372' post='4904031']
Well, I had a suggestion about why show was so slow using v1.6, when using SFML or SDL (even commenting out the SFML draw).

it looks like, in SDL, "part" is a pointer, while, when using SFML, it is not. Try setting the SFML version's part from Sf::Sprite part to Sf::Sprite *part.

It's probably all the copying it has to do.

Well, in SDL you have Surfaces that are associated with the image files (in my case)
To avoid having each particle load the same image that they share, I just used a pointer to the same Surface.

In SFML, there is a separate Image (or Texture in 2.0) that contains the actual image, and there is a Sprite, that (the way I understand it) is kind of like a pointer to the image.
I can set the sprite to an image, but it will only point to that one image, it won't contain the image file's data.

That's why in a traditional sense I wasn't using * pointer, but conceptually I was.
Either way, thanks for your comment, so far I seemed to have had the performance issues solved with using SFML 2.0.

btw I am really new to SFML, so please correct me if my understanding of this seems to be wrong
[/quote]

Typically, you load the image once, and you create a Sf::Sprite from that image. But, that has nothing to do with it being a pointer or not. You can create a new Sf::Sprite as a pointer for all your sprites, and, when you assign part, you're just copying the pointer (4 bytes, 1 CPU operation) instead of the whole Sprite class (much larger, taking a memcpy).

So, the point I was making really doesn't have anything to do with SFML or SDL; rather, with the speed it takes to copy a pointer, versus copying a whole class structure.