Author Topic: SFML 2 API updates (Read 3469 times)

slotdev · « **on:** March 03, 2012, 07:06:11 pm »

I am going to update our codebase from SFML 2 (from November 2011) to the current snapshot.

Was there a list of changes made and what people need to do, to get it working? I know the drawing API has changed a lot from seeing things on this forum, but I have no idea what needs updating.

Any help appreciated!

Thanks
Ed

Laurent · « **Reply #1 on:** March 03, 2012, 08:48:07 pm »

There's no list. The best way to update your code is to compile it and fix errors one by one, with the help of the online doc and the topics of the General forum

slotdev · « **Reply #2 on:** March 03, 2012, 09:10:17 pm »

Right OK.

Out of interest, what kind of performance improvement can we expect (if any) from the previous way of doing things?

Thanks

Laurent · « **Reply #3 on:** March 03, 2012, 09:24:24 pm »

I can't answer, it totally depends on what you do.

slotdev · « **Reply #4 on:** March 03, 2012, 09:29:58 pm »

Rendering probably 20 to 50 sprites (including one 1680x1050) every frame @ 30fps.

Laurent · « **Reply #5 on:** March 03, 2012, 09:34:02 pm »

What I meant is that this question can only be answered by testing. It really depends on the details.

But it's likely to be worse if you use sf::Sprite. Significant improvements are achieved by batching geometry with vertex arrays.

slotdev · « **Reply #6 on:** March 03, 2012, 09:43:42 pm »

Sure, I understand.

I'm a little worried about the "likely to be worse if you use sf::Sprite" - we load a number of 2048x2048 spritesheets and SetSubRect on them to a sprite.

This is the core of our system, given that we only do 2D stuff, so any loss of performance will make me think twice about this update. We have to work on some old hardware (like Intel Extreme Graphics on a 1.8Ghz Celeron).

Thanks

Laurent · « **Reply #7 on:** March 03, 2012, 09:59:27 pm »

All I can say is: update, test, and let me know the results

Nexus · « **Reply #8 on:** March 03, 2012, 10:06:03 pm »

Quote from: "slotdev"

We have to work on some old hardware (like Intel Extreme Graphics on a 1.8Ghz Celeron).

Might not the texture size of 2048 also be a problem for older graphic cards? I've already experienced that my game didn't run at many users because of this.

slotdev · « **Reply #9 on:** March 03, 2012, 10:29:25 pm »

Quote from: "Nexus"

Quote from: "slotdev"
We have to work on some old hardware (like Intel Extreme Graphics on a 1.8Ghz Celeron).
Might not the texture size of 2048 also be a problem for older graphic cards? I've already experienced that my game didn't run at many users because of this.

Yes but 2048x2048 is the minimum size the various hardware we use supports, so we keep this as the standard.

Also, we don't give our apps to the general public, this is an industrial application, so we know the exact configuration of the hardware.

slotdev · « **Reply #10 on:** March 04, 2012, 08:05:30 pm »

OK so I am working through this and it all seems fairly clear.

in sf::Sprite...

SetTextureRect has replaced SetSubRect
SetScale has replaced SetScaleX and SetScaleY
SetPosition has replaced SetX and SetY

But what has happened to FlipX and FlipY?

Thanks
Ed

texus · « **Reply #11 on:** March 04, 2012, 08:13:33 pm »

Quote from: "slotdev"

But what has happened to FlipX and FlipY?

The solution can be found here: http://www.sfml-dev.org/forum/viewtopic.php?t=6676

Quote

Using a negative scale works, but it will flip the sprite not only its texture. So either set the origin of the sprite to its center, or adjust its position accordingly.

Using negative texture coordinates might work too, but you have to explicitely set the texture as repeated (it's not by default) -- texture.SetRepeated(true).