Benchmark : SDL vs SFML

[Osbios]

Well SDL is nice for software rendering. Like a raytracer or real old style 320x200 pixel games. And at the begining I belived it would also make a good basic opengl context.
But after trying some time I just good feedup with all the bugs that I found in basic usage. For example you get the mouse at a totaly wrong position if you catch it in the opengl window. Or there is a missing event in some circumstances if you resize the window... and may some more...

So for me the most importend fact is, there is no real development going on anymore for SDL. Or at last not enough for my taste... so this bugs wont be fixed anytime soon.

Thats the point where SFML looks very different.

[Ashenwraith]

Speaking of performance, how is xna/directx working for 2d?

Xna actually has surprisingly great support for 2D. Its not as simple as SFML, but one big thing they have going for them is their SpriteBatch class. There are 5 sorting methods:
1. Immediate: Draw whenever the state (texture) changes.
2. Texture: Draw everything at once, ordered by texture (for when stuff doesn't overlap).
3. Deferred: Draw all at once in the same order called (same as Immediate, but delayed, I believe - its so you can build up multiple batches at once without messing up the drawing).
4. Front-to-back: Deferred, but sorted by depth.
5. Back-to-front: Deferred, but sorted by depth (other direction).

I personally only really used Immediate, since I find it easy enough to handle the ordering myself. I assume this is pretty much like the batching Laurent added to SFML 2.0. If a call to draw uses the same state as the last call, you queue it into the batch. If the state changes, you flush the queue, clear it, then place the newest call in the front of the batch. Combined with texture atlases, I was able to render my whole scenes in under 30-or-so batches.

However, with XNA, you are in a load of hurt if you try to do things your own way. One reason I switch from XNA to SFML for my project was since I didn't like how XNA's ContentManager worked. Switching to SFML, I had a robust content manager that supports lazy-loading, only loading one instance of each asset, and automatic asset reloading (if you call an asset that has been disposed, it reloads from file transparently) done very quickly. Trying to do this with XNA, I gave up after about a full day of working on it, and tons of hacking with reflection.

In my project, since I just replaced XNA with SFML, things are being used pretty much the same way. From what I can see, the only real performance hits are coming from the fact that I no longer have any batching. But even still, I am hitting 60 FPS no sweat. I think the SFML version is running about 50%* slower while doing the exact same stuff (even using texture atlases still), but again, we're comparing no batching to batching, and I am still using SFML 1.5. And my rendering is still written with XNA in mind, not SFML.

*This is a complete guess from memory based purely on approximate numbers I remember when looking at the Task Manager. In no way have I EVER actually measured it.

As far as simplicity goes, SFML beats XNA hands-down for 2D. Its quite scary how simple SFML is. And at least when you don't like how something works in SFML, you can roll your own without a fight.

Would be nice to see some benchmarks of XNA vs SFML 2

So are you giving up on XNA?

I thought  an XNA port of SFML would be cool.

[Spodi]

Yeah, I gave up on XNA after using it for about 2 years. I like SFML a lot more for 2d.

[Ceylo]

I thought  an XNA port of SFML would be cool.

I don't think "cool" is good reason for Laurent to implement a XNA backend  :lol: . Moreover it'd be a huge work, it's not portable, and benefits still need to be demonstrated. Thus Laurent might keep using OpenGL .

[Ashenwraith]

I thought  an XNA port of SFML would be cool.

I don't think "cool" is good reason for Laurent to implement a XNA backend  :lol: . Moreover it'd be a huge work, it's not portable, and benefits still need to be demonstrated. Thus Laurent might keep using OpenGL .

I wasn't proposing Laurent make an XNA backend, but as for the benefits--XNA seems to be the most open and easy way to get a game onto the xbox360.

Xbox Live! has a large 2D fanbase where many people actually still purchase 2D games (even retro ones). PSN's markeshare doesn't even compare. You have to go to handhelds for the next biggest market and good luck breaking into that.

http://www.gamasutra.com/view/news/28075/InDepth_Xbox_Live_Arcade_Sales_Analysis_March_2010.php

[Ceylo]

I wasn't proposing Laurent make an XNA backend, [...]

So what do you mean with "porting SFML to XNA" ? Making a new version SFML targetting Xbox 360 ? (like what may be done for an iPhone port ?)

[Ceylo]

As for the benefits, I was rather thinking of the benefits of using XNA, not of making a port for Xbox 360, even if both are linked. So.. ok as far as the benefits of a Xbox 360 port, even if I don't know whether it's achievable.

[Ashenwraith]

As for the benefits, I was rather thinking of the benefits of using XNA, not of making a port for Xbox 360, even if both are linked. So.. ok as far as the benefits of a Xbox 360 port, even if I don't know whether it's achievable.

Yeah, I prefer OpenGL/C++ over DirextX and C#, but I know XNA is integrated with Visual Studio.NET so I don't know if that helps.

But as for the benefit of XNA is summed up as:

"XNA Indie Games

Xbox 360 games written in XNA Game Studio can be submitted to the Creators Club community, for which premium membership is required, this costs US$49 for 4 months or US$99/year. All games submitted to the community are subjected to peer review by other creators. If the game passes review then it is listed on Xbox Live Marketplace. Creators can set a price of 80, 240 or 400 points for their game. The creator is paid 70% of the total revenue from their game sales as a baseline."

[xazax]

A similar benchmark between sfml2 and sfml1.6 would be very interesting

[thoralmighty]

A similar benchmark between sfml2 and sfml1.6 would be very interesting

interesting idea

[asdatapel]

Im gonna bump this topic cuz Id like to see how the results have changed after three years. Can you run the test again?

[Hiura]

Not now because Laurent is planning to modify the graphics API. So maybe in a few weeks.  :wink:

[Groogy]

Actually, see a benchmark after the graphics api change both between SFML2 vs SFML2(before and after change) and between SFML2 and SFML1.6 and SFML2 and SDL or any other API we can find ^^

[AdelR]

Now that SFML 2.0 and SDL 1.3 APIs have stabilized it would be interesting to see new benchmark.

[eXpl0it3r]

Now that SFML 2.0 and SDL 1.3 APIs have stabilized it would be interesting to see new benchmark.

You like to play with fire bumping a nearly one year old thread as your second post, but fear not, as the SFML community doesn't forbid this.

Actually I've always wanted to recreate that benchmark but never gotten around until you reminded me today and so I took my time and converted everything to SFML 2 (which was very very easy) and then compiled all the stuff (SDL, SDL_ttf, SGE) needed for the SDL (which was kind of a pain).

So here we go with my results with the latest SFML version, the SDL 1.2 library (changeset: 6396:b1c1b7ac4b39), the latest SDL_tff library (version 2.0.11) and the latest SGE library r030809. Everything linked dynamically and run in release mode:

1/ Test : sprites
SDL  displayed 388 frames
SFML displayed 147 frames
--> SFML is 0.4x as fast as SDL

2/ Test : alpha-blended sprites
SDL  displayed 107 frames
SFML displayed 146 frames
--> SFML is 1.4x as fast as SDL

3/ Test : rotating sprites
SDL  displayed 14 frames
SFML displayed 150 frames
--> SFML is 10.7x as fast as SDL

4/ Test : static text
SDL  displayed 3434 frames
SFML displayed 6187 frames
--> SFML is 1.8x as fast as SDL

5/ Test : dynamic text
SDL  displayed 155 frames
SFML displayed 4479 frames
--> SFML is 28.9x as fast as SDL

It's interesting to see SDL beating SFML in the static sprite rendering whereas in 2007 it was bearly able to draw a few frames.
But the static rendering is also already the only part where SDL is a tick faster then SFML.

If you want to try it or add anything, I've setup a Git(Hub) repository (I hope Laurent doesn't mind) so you can get the code + resources from here and for a fully working demo for Windows 32bit you can get the executable, libraries, resources and source from here.

I hope to see some further benchmarks since it can vary largly from hardware to hardware.
I personally would be interested in a pixel manipulation comparison and a SFML 2 vs SDL 2, so if anyone got a bit time and knowledge...