Retro compatibility

[NoIdea]

Hi, after looking a bit, I couldn't find a list of non retro compatible things between SFML1 and SFML2. It would be very appreciated to have a link that would give us that information. Thank you.

[Laurent]

There will be one when SFML 2 is released.

[Lupinius]

The things I noticed when switching:
sf::String is now used for storing text (like std::string)
sf::Text is used for displaying the text
The third and fourth arguments for sf::Rect now are width and height, not the second corner coordinates
Sockets have some different functions now

[NoIdea]

Thanks for this little summary, I wonder why Rect changed, I always hated width/height Rects... If anybody has more information, please add...

[Laurent]

The bottom/top representation led to inconsistencies and confusion, especially with integer rectangles, where it was not always clear if the last coordinate was included or not in the rectangle.

For a more complete list of changes, you can browse the list of closed tasks on the task tracker.

You can also see the General forum, where I post announcements about big modifications. The SVN log may also help you if you can extract useful information from it

[NoIdea]

Ok, thanks its just i'm doing a project on 1.6 and I want to be sure not to have to much problems when going to 2.0.

[Nexus]

You may also use the SVN version of SFML 2, such that you are able to keep the code constantly up-to-date.

[NoIdea]

You may also use the SVN version of SFML 2, such that you are able to keep the code constantly up-to-date.

I'm having enough trouble finishing my project with 1.6 to keep another version up to date with 2.0
I just wanted to have an idea to know where I might have problems and try to find a solution that wouldn't be to diffulcut to adapt for 2.0.
I've heard that rendering might be different in respect of OPENGL functions when displaying drwables. How much ? would it effect basic functions like GlClipPlane ?

I do not have any problems with naming changes, minor changes that just take a bit of search/replace to adapt.
However, I would like not to have to change a major part just because some things like threads don't exist (which would be quite unlickly : this is just an example).

[Tank]

You definitely will have a good amount of work when porting your application from SFML 1.6 to SFML 2.0 (/SVN). A lot of stuff has changed, and that doesn't only count for the public interface. You already addressed it: Using OpenGL calls in sf::Drawable's Render() method isn't possible anymore, you have to use sf::Renderer for this.

Depending on your project size and the time estimated to finish it, I suppose to switch to SFML 2 (and to be honest: it's worth it ).

[Laurent]

The drawables rendering stuff may not be stable (I'm talking about public interface, not robustness). I still hope to find a better design for this area before the final release. So if your code uses a lot of custom drawables, or makes OpenGL commands interact with SFML rendering, think twice before switching to SFML 2.

[NoIdea]

The drawables rendering stuff may not be stable (I'm talking about public interface, not robustness). I still hope to find a better design for this area before the final release. So if your code uses a lot of custom drawables, or makes OpenGL commands interact with SFML rendering, think twice before switching to SFML 2.

For the moment, I only use GLClipPlane to ensure each object of my GUI stays in the rectangle it has been assugned in,  but of course there may be other calls to OPENGL. Is glclipplane still working with 2.0 ? Is there another way (that keeps performances) ?
I haven't found any feature in 2.0 that I really need yet. Sf::RenderImlage is interesting but i've made my own specific class which may be quicker.

Work is not really a problem as long as it doesn't ask to rethink the whole architecture.

[Laurent]

Is glclipplane still working with 2.0 ?

I think so, but this kind of interaction is no longer recommended.

Is there another way (that keeps performances) ?

Yes, there will be masks based on GL clip planes implemented in SFML 2.

[NoIdea]

thanks, as soon as I make my project work with 1.6, I'll try to switch it to 2.0

Yes, there will be masks based on GL clip planes implemented in SFML 2.

"will" means it is not yet implemented (in which case I should wait a bit...)?

[Laurent]

"will" means it is not yet implemented (in which case I should wait a bit...)?

Yes.