SDL 2.0

[short]

So I saw this link, and wanted to make sure everyone else here saw it.

http://www.phoronix.com/scan.php?page=n ... px=MTE0MDU

It seems that it will have valve's backing, so hopefully more updates. I looked on SDL's official website but didn't find anything, anyone else see anything?

[lalacomun]

nop, nothing, but SDL 2.0 seems great, finnally 2D Hardware accelerated graphics without using OpenGL

[Light-Dark]

- Hardware-accelerated 2D graphics.

Well I'm hyped.

[TheBuzzSaw]

I'm glad SDL is moving forward, but I'm tired of C frameworks. I'm investigating SFML to see if I like the API.

[short]

I'm glad SDL is moving forward, but I'm tired of C frameworks. I'm investigating SFML to see if I like the API.

Personally I'm not a huge fan of the camelCase, but I guess it does help intellisense with visual studio

[dandymcgee]

I'm glad SDL is moving forward, but I'm tired of C frameworks. I'm investigating SFML to see if I like the API.

I've recently started playing around with SFML 2.0 a bit and I have to say it's quite a nice library. Unlike SDL, it's not separated into a bunch of different packages you have to download but rather supports everything you need right from the start. The API seems very reasonable and respectable, and to be honest the SFML codebase is extraordinarily well organized and commented. I like being able to look under the hood every now and then when I'm not sure exactly how something works. I read through SFML's networking code and it's pretty straightforward BSD socket stuff. You could easily modify and recompile the SFML library if you ever needed to.

[eatcomics]

I'm glad SDL is moving forward, but I'm tired of C frameworks. I'm investigating SFML to see if I like the API.

I've recently started playing around with SFML 2.0 a bit and I have to say it's quite a nice library. Unlike SDL, it's not separated into a bunch of different packages you have to download but rather supports everything you need right from the start. The API seems very reasonable and respectable, and to be honest the SFML codebase is extraordinarily well organized and commented. I like being able to look under the hood every now and then when I'm not sure exactly how something works. I read through SFML's networking code and it's pretty straightforward BSD socket stuff. You could easily modify and recompile the SFML library if you ever needed to.

Damn it, I keep hearing these same things about SFML but I'm so stubborn I haven't taken the time to try and switch from SDL to SFML.

[superLED]

Damn it, I keep hearing these same things about SFML but I'm so stubborn I haven't taken the time to try and switch from SDL to SFML.

I would rather start using OpenGL with SDL (if you already are steady with it). Using OpenGL to render stuff. Then you could keep all your code for music, threads, input, networking and such, and just learn how to render with a new API.
Would take some time to do all that over again, if you already have made a framework/engine for your games.

[dandymcgee]

Damn it, I keep hearing these same things about SFML but I'm so stubborn I haven't taken the time to try and switch from SDL to SFML.

I would rather start using OpenGL with SDL (if you already are steady with it). Using OpenGL to render stuff. Then you could keep all your code for music, threads, input, networking and such, and just learn how to render with a new API.
Would take some time to do all that over again, if you already have made a framework/engine for your games.

That makes no sense. The rendering is the only part that wouldn't change when you switched to SFML, assuming you were already using OpenGL.

[superLED]

Damn it, I keep hearing these same things about SFML but I'm so stubborn I haven't taken the time to try and switch from SDL to SFML.

I would rather start using OpenGL with SDL (if you already are steady with it). Using OpenGL to render stuff. Then you could keep all your code for music, threads, input, networking and such, and just learn how to render with a new API.
Would take some time to do all that over again, if you already have made a framework/engine for your games.

That makes no sense. The rendering is the only part that wouldn't change when you switched to SFML, assuming you were already using OpenGL.

If you are going from 'pure' SDL to using OpenGL to render stuff, then you would only re-write the rendering-part of your engine/framework.
If you are going from 'pure' SDL to 'pure' SFML, then you would re-write all of your engine/framework.

Or am I totally lost?

(By 'pure' I mean using only SDL/SFML to do the rendering, music, input and all the other stuff)

[dandymcgee]

(By 'pure' I mean using only SDL/SFML to do the rendering, music, input and all the other stuff)

SFML uses OpenGL to render. It does not have a software rendering mode like SDL. The API simply wraps OpenGL as far as I can tell.

[CC Ricers]

Damn it, I keep hearing these same things about SFML but I'm so stubborn I haven't taken the time to try and switch from SDL to SFML.

I would rather start using OpenGL with SDL (if you already are steady with it). Using OpenGL to render stuff. Then you could keep all your code for music, threads, input, networking and such, and just learn how to render with a new API.
Would take some time to do all that over again, if you already have made a framework/engine for your games.

Yep, this is how I started using it once I felt I was ready for "expert mode" for the graphics. Kept everything simple because I hate writing my own input libraries.

I have never used SFML before, has it always been a hardware accelerated OpenGL wrapper? I would also assume it would take advantage of features like alpha blending, 2D matrix rotation, shearing, etc.

[dandymcgee]

I would also assume it would take advantage of features like alpha blending, 2D matrix rotation, shearing, etc.

I'm not sure that it does. Looking at the source for SFML 1.6, the Sprite class seems to be doing very simple immediate mode rendering of a textured quad.
If you want anything more they make it extremely easy to use your own OpenGL code for rendering, but the provided wrappers are fairly typical OpenGL calls.
This is better than SDL in that although both allow you to write your own rendering code, if you don't wish to do so SFML provides some for you behind the scenes,
whereas SDL uses software rendering. In either case, it is possible to get much better performance by providing your own rendering methods. These libraries
are not even remotely as sophisticated or optimized as something like the STL.

The SFML source code is very easy to read, I recommend you download it and judge for yourself.

[lalacomun]

SFML is nice, but i still prefere SDL & OpenGL, and yes SFML is preaty much a wrapper from OpenGL look at the basic shapes rendering its almost the same thing as OpenGL, a little bit easier on SFML but i recommend SFML A LOT!