Both are undergoing development
Both support hardware accelerated 2D out of the box
Both are licensed under the zlib license -- that's right, you are now free to statically link SDL to your programs
SFML is mostly supported by one developer, a much smaller team than the one behind SDL
SFML is only aimed at Windows/Linux/OSX for the moment, while SDL supports a much wider range of platforms
SFML 2.0 is pretty unstable at the moment, with the lead developer stating that he's prepared to completely break parts of the API prior to the 2.0 release
SDL 1.3 is probably pretty unstable as well
SFML has a much more friendly API than SDL, in my experience, although this is limited to usage of 1.2
Given my limited knowledge of SDL 1.3, I'm not sure which is the better library to side with. I originally jumped ship from SDL to SFML because of its friendlier API and hardware accelerated 2D graphics, but if SDL 1.3 is going to feature similar hardware acceleration along with a brisker, more reliable pace of development, my inclined to side with it. Can /prog/ convince me to pick a camp?
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-21 8:45
SDL 324kb dll
SFML 24000kb in 5 DLLs
The latter could be as fast as sepples allows it but adding twenty mb of bloat is not excusable for library which is a minimal layer over OpenGL
twenty mb of bloat twenty mb
Do they still use 56kbod modems in Russia?
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-21 9:12
Speed of transfer isn't the problem, it just indicates there is alot of code for very little function.
Consider that for 24mb would be enough to contain entire DirectX 8.1(11.8 MB as full install),OpenGL(2mb with GLUT, all bells and whistles),3-4 sound libraries and still not reach even 20 mb.
>>10 it just indicates there is alot of code for very little function.
So what? Maybe it's infinitely decompressed or something, anyway, why do you care about functionality density per megabyte? Why is this a metric that one should strive to optimize?
I feel like you maybe read too many books which brainwashed you with patriarchal preconceptions.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-21 9:48
>>11
Its simply called bloat. I don't read books, i just see this library advertised as "fast and efficient".
Not to mention that SDL.dll does not include networking and audio, last time I checked.
Even if you were to include libsndfile-1.dll (325 120 bytes) and openal32.dll (208 896 bytes) for some reason, you would still be very far away from 20mb.
>>16 .a
Those are supposed to be statically linked into your program executable file and pruned by the linker. The actual size is much smaller.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-21 11:11
>>18
The post wasn't about them, its about the DLLs. The whole library is at 24mb of DLLs.
Name:
Anonymous2011-11-21 11:27
>>12 Its simply called bloat.
And why you say that as if it were something bad? I don't read books,
Then you got yourself brainwashed by something else. i just see this library advertised as "fast and efficient".
What's slow and inefficient about it?
>>13
well, that's kind of my point. You see people trying to create something under some artificial constraints. You can call it "art" or "intellectual masturbation", or whatever, that's OK, no problemo.
But if you forget about the fact that the constraints are artificial, then you get brainwashed by the semi-imaginary peer pressure which tells you that no "bloat" is good, because it's good, because look at how respected fr are, you should respect what respected people do and try to be respected as well, so stay away from the bloat! First rule of the no-bloat club: don't question why bloat is bad!
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-21 11:40
>>21
When logic fails a brainwashed individual, he resorts to an ad hominem, preferably one which implies that the interrogator belongs to them, the enemy which seeks to destroy the group to which the individual belongs.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-21 11:55
>>24
I don't have to prove that bloat is bad, it obvious that functionality which comes at lesser cost is better than one that comes at higher cost.
You can fiddle with gigabyte sapping, memory leaking VMs and gigantic libraries all day, that typical for AAA-class Enterprise Software Developers, its just not as efficient or elegant in terms of design as >>13
>>16
My bad; I realize now that you have the supplied pre-compiled DLLs that were built using MingW. Of course it's going to be bloated shit; don't blame SFML, blame the retardation that is MingW.
Name:
Anonymous2011-11-21 12:09
I don't have to prove that bloat is bad, it obvious
Heh.
that functionality which comes at lesser cost is better than one that comes at higher cost.
Define cost.
You can fiddle with gigabyte sapping, memory leaking VMs and gigantic libraries all day, that typical for AAA-class Enterprise Software Developers
Here we can see how brainwashed individual tries to further assert his ad hominem and the notion that the questioner belongs to a hostile class, which is why his questions are dangerous to even try to answer.
its just not as efficient
You must say that it is not as efficient three times, only then it will become true. Two times are not enough.
or elegant in terms of design as
Oh, yes, sure, it's not "elegant", it's not "beautiful", it's not a piece of art -- not something created under pointless constraints.
By the way, while we are at it, do you realize that we are discussing the size of the binary, not the source code? Not that it is terribly important, since your rinsed and dried brain blows fuses when it detects questioning of your silly beliefs either way.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-21 12:18
>>28
>not something created under pointless constraints
These are qualities of the software, have less size,less more use, more speed are not "pointless"
>CSFML is not C++ so using that supposed ``bloat'' as reason to pick on C++ makes no sense.
Thats exactly why its larger its filled with useless Sepples functions, which mingw compiles in.
Name:
Anonymous2011-11-21 12:25
>>29 These are qualities of the software, have less size,less more use, more speed are not "pointless"
I didn't think your brain would literally short-circuit, ha ha ha.
You poor creature, have you ever been as far as decided even do more like?
>>29
No, it's larger because MingW is a terrible compiler. Clearly you have never actually even bothered to build any windows executables with it or you would be familiar with that. What goes in the VC++ redistributables is pretty much statically linked into every MingW executable in existence and that is the reason it generates massive bloat. It being C++ or C has literally nothing to do with it.
Of course, IHBT since you clearly never even bothered looking at CSFML's source if you say things like its filled with useless Sepples functions.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-21 12:29
>>30
I don't think so, i meant to type 'less memory use', but missed a few keys.
Is memory use, size of program, speed of execution one of "pointless constraints"?
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-21 12:33
>>31
>never even bothered looking at CSFML's source
I checked the DLLs in notepad, all are filled with thousands of Sepples functions at the end.
>>32 Is memory use, size of program, speed of execution one of "pointless constraints"?
Depends on the actual values. For instance, the difference between 20mb and 2mb used by an in-memory image of library on an 4Gb machine, for a 3d graphics application, is irrelevant, the 2mb memory consumption constraint is artificial, and spending any effort whatsoever to fit the library in the constrained space is pointless.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-21 12:59
>Depends on the actual values
I see you have some sense, now what would make a library less efficient? Having more size is just one of symptoms, bloated OOP abstraction
layers and generally unoptimized, low-quality code.
>spending any effort
The effect is multiplied by thousands of programs where programmer did not spend any effort. The next enterprise code monkey which is assigned to a program just wants the monthly banana for least effort and will be as lazy as the last.
I see you have some sense, now what would make a library less efficient? Having more size is just one of symptoms, bloated OOP abstraction layers and generally unoptimized, low-quality code.
You are speaking out of your anus.
In this particular case it was demonstrated to you that the "bloat" of the binary was not caused by any of these things.
Brainwashed people tend to ignore facts in favour of "ideologically correct" reasoning.
>>16
1, those are the C SFML bindings, not the default C++ ones.
2, you listed every possible version of the library there. Both the release and debug versions of both the static and dynamically linked libraries.
Can we ignore the impostor FrozenVoid now and get back to discussing the actual merits of SDL 1.3 and SFML 2.0?
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-21 13:41
>those are the C SFML bindings, not the default C++ ones.
here are C++ bindings, i don't see how this improves the size
Directory of C:\download\SFML-1.6-dev-windows-mingw\SFML-1.6\lib
Worst case: 9 MiB of DLLs, plus some linking overhead should add around 10 MiB of overhead to your program.
Typical case: You use the static libraries and only the parts of SFML that you actually used are linked in. The overhead is a fraction of that of using the dynamic libraries.
In either case, SFML doesn't add enough overhead to your executable to impact distribution. Even the 9 MiB of DLLs (plus the libsndfile and openal DLLs) easily compress down to a 1.5 MiB 7z archive, or a 2.5 MiB zip archive.