Elysian Shadows

Have you guys hear about this SFML?

It stands for simple fast media library, and supposedly its less convoluted, faster, and much more object oriented than SDL(I don't think SDL is written in OO, but then again I'm not familiar with it). It also has several bindings to a slew of languages (.NET languages, Python, D, Ruby, etc).

http://www.sfml-dev.org/index.php

I've given it a try on my dual-boot machine (Mac os x, and win xp), and it works pretty good on both. I've also checked out SDL vs. SFML benchmarks on their forums, and it seems SFML is faster by magnitudes of clock cycles in certain cases. Pretty sweet. I'll be further investigating this little thing, and maybe use it

Anyone interested in it? Or are you only interested in SDL!!

I took a look at the first tutorial they have for it (the event handling one), and you have to do a crapload of stuff just to be able to get events... Whereas in SDL you can just do SDL_PollEvent(). SFML sounds cool, but until it's as easy to use as SDL, I'll stick with what I already know that I can use.

sparda wrote:much more object oriented than SDL(I don't think SDL is written in OO, but then again I'm not familiar with it).

SDL, OpenGL, Allegro, DirectX, and all of those are the anti Object Oriented.

They're all written in C. That way they can be compiled in C and C++ projects. And personally, I think I would rather have a backend media library/collection of APIs written in lower level, faster, procedural C than object oriented C++.

You're manipulating the API/library with your own programs, you can make the way you use them object oriented, but I don't think that they, themselves, should be.

But hey, that's just my very C biased, low level, procedural opinion.

GyroVorbis wrote:

sparda wrote:much more object oriented than SDL(I don't think SDL is written in OO, but then again I'm not familiar with it).

SDL, OpenGL, Allegro, DirectX, and all of those are the anti Object Oriented.

They're all written in C. That way they can be compiled in C and C++ projects. And personally, I think I would rather have a backend media library/collection of APIs written in lower level, faster, procedural C than object oriented C++.

You're manipulating the API/library with your own programs, you can make the way you use them object oriented, but I don't think that they, themselves, should be.

But hey, that's just my very C biased, low level, procedural opinion.

I'd have to agree with that.

Also I have a tendency to break OO design and use procedural C cause it makes sense and well...why not

SFML sounds cool, but until it's as easy to use as SDL, I'll stick with what I already know that I can use.

I don't think that's what you mean. I think we can agree that difficulty is relative; meaning for instance that I can find SFML much easier than SDL, simply because I know it better, or in a more in depth manner. I think what you're saying is that you feel more comfortable with SDL, which is fine BTW. Plus, programming is something that is generally not easy. Certain things are more convenient, but not easy.

SDL, OpenGL, Allegro, DirectX, and all of those are the anti Object Oriented.

They're all written in C. That way they can be compiled in C and C++ projects. And personally, I think I would rather have a backend media library/collection of APIs written in lower level, faster, procedural C than object oriented C++.

You're manipulating the API/library with your own programs, you can make the way you use them object oriented, but I don't think that they, themselves, should be.

But hey, that's just my very C biased, low level, procedural opinion.

I'll admit, I'm C biased as well, but you have to wonder, given the procedural vs. object oriented remarks, how SFML is faster in these forum benchmarks. You can argue that the benchmarks are biased towards SFLM, but as you read the forums you realize that a lot of these people come from an SDL background anyway. eg the user: Pwndja.

I like my game APIs to be written in C no doubt, but there comes a time to admit when certain developers are better than others at making their library faster. SFML seems to be the faster one in this case (aren't game libraries all about the speed anyways?). The way I see it is: SDL is getting antiquated; its an old library. Plus, hasn't it been at version 1.2 for eons now (notwithstanding minor releases like 1.2.13)?

It semms cool. I like to code OO, but i dont really know if u would perfer an API to be OO or not.

But i guees i will stick to SDL for awile. I need to get a game done soon, and chaning libary wont help.

Are you required to release .o files of any program that utilizes SFML? And very interesting points, sparda.

The reason SDL hasn't had to do a major release is because the system its wrapping for the various OSs haven't changed alot.

Stuff has been added like in GSOC force feedback for joypads, a alpha SDL port to the iPhone(which can't be released due to NDA...which is BS) which has OpenGL support and input I believe. But anyways SDL is stable, and you know what your getting...a solid API. I would give this a chance and play with it when I get the time, but right know I'm going to stay an SDL fanboy.

And very interesting points, sparda

Thanks Falco.

Are you required to release .o files of any program that utilizes SFML?

What do you mean, like licensing terms or something? To my knowledge, SFML is completely free and nonrestrictive, for commercial as well as personal use. So that means you don't have to release anything you don't want to; heck, you can keep it closed source even:

SFML is completely free for any use, commercial or not, open-source or not. That is, you can use SFML API in your project without any restriction.
Indication that you use SFML in your project is not required, but would be appreciated.

As for the SFML source code itself:

Source code is provided under the terms of the zlib/png license

If you meant something else by the object-files comment, I apologize ahead of time for misinterpreting. And if that's the case, I would like to know exactly what you meant by that.

I would give this a chance and play with it when I get the time, but right know I'm going to stay an SDL fanboy.

Hey, I won't hold it against you. After all, unwillingness to change is one of the most predictable of human reactions.

SDL is a much more widely documented(at the moment) and definitely a very stable API, therefore adopting this language is a pretty good option.

I don't always solve everything in an OO fashion, because sometimes it's cleaner to do some things procedurally (depending on the scale of the project), it's always nice to have that choice and flexibility that the C++ offers at it's core(there are OO components, but you don't have to use them, should the API respect this?, Ithink so )

But there's no harm in trying something new, and there's no reason to disregard a new API before it's been tried and tested, however I'll be sticking with SDL, because it's what I know, and currently it gives me what I need, if my needs grow, then I'll move onto a bigger and better library...

I'm looking forward to hearing some feedback on this API though.

I like SFML, but unless you already know something similar like SDL, it's nearly impossible to learn from the tutorials on the websites. But otherwise, it's great.

And there's no need to get addons... like with SDL you need SDL_image, SDL_ttf, SDL_net... In SFML, it's all together.

Yes, Ginto speaks the truth. On top of that, there are classes for easily programming TCP/UDP sockets as well, without the need to compile and integrate a new subsystem, like SDL would have you do (Not that its difficult, just a hassle, case in point: I had trouble compiling SDL_image on Mac and Vista, because of bitchiness regarding the TTF library). So abstractly it can be thought of as a monolithic system. I'm not sure if SDL has multithreading capability, but SFML, I know, has a plethora of classes to easily facilitate this very feature as well.

And here is the killer: There is an iPhone/iTouch port being worked on extensively, which would work natively with C/C++ (So I guess I'll be the first one from here to take that new PowerVR hardware for a spin Well, maybe Ginto will beat me to it since he is also learing SFML

sparda wrote:Yes, Ginto speaks the truth. On top of that, there are classes for easily programming TCP/UDP sockets as well, without the need to compile and integrate a new subsystem, like SDL would have you do (Not that its difficult, just a hassle, case in point: I had trouble compiling SDL_image on Mac and Vista, because of bitchiness regarding the TTF library). So abstractly it can be thought of as a monolithic system. I'm not sure if SDL has multithreading capability, but SFML, I know, has a plethora of classes to easily facilitate this very feature as well.

Also, it has it's own random number generator.

sparda wrote:And here is the killer: There is an iPhone/iTouch port being worked on extensively, which would work natively with C/C++ (So I guess I'll be the first one from here to take that new PowerVR hardware for a spin Well, maybe Ginto will beat me to it since he is also learing SFML

Maybe... Thing is, I have neither the iPhone or iTouch...

It sounds really great :D after i am done with this project in SDL, i will look at it :D

I personally like SFML, but one thing that I hated was that I couldn't get sound to work with my programs using the audio part of it. So I used SDL for audio. So I'm using both at the moment