SFML 2.0 vs SDL 1.3

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?

11/21/2011  01:53 PM         1,117,130 sfml-audio-2.dll
11/21/2011  01:53 PM         2,605,213 sfml-graphics-2.dll
11/21/2011  01:53 PM         1,175,542 sfml-network-2.dll
11/21/2011  01:53 PM           880,888 sfml-system-2.dll
11/21/2011  01:53 PM           916,777 sfml-window-2.dll
               8 File(s)      9,427,582 bytes
              
11/20/2011  05:26 PM           236,924 libsfml-audio-s.a
11/21/2011  01:53 PM            92,720 libsfml-audio.a
11/20/2011  05:26 PM         2,075,664 libsfml-graphics-s.a
11/21/2011  01:53 PM           226,496 libsfml-graphics.a
11/21/2011  01:53 PM               878 libsfml-main.a
11/20/2011  05:26 PM           295,286 libsfml-network-s.a
11/21/2011  01:53 PM           123,840 libsfml-network.a
11/20/2011  05:26 PM            38,920 libsfml-system-s.a
11/21/2011  01:53 PM            54,712 libsfml-system.a
11/20/2011  05:26 PM           772,902 libsfml-window-s.a
11/21/2011  01:53 PM            55,224 libsfml-window.a
              12 File(s)      3,973,566 bytes

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.

I have beet rolled.

>>11,20,28
protip: processors aren't going to be getting faster for much longer, and same with storage densities increasing.

software, meanwhile, has gone farther and farther from the limits of efficiency. what you could do with 64KB in the 80s with a 10MHz CPU now takes megabytes or even gigabytes and gigahertz-level CPUs.

it's about time they realized how much waste has been going on.

>>42
lisp is shit

I cannot believe someone would write a library in sepples rather than C.

Stupid Frenchies.

I like SDL because it has more tutorials, and I'm going to work for video games.

>>45
We're all going to work for video games. Why else would we program?

>>46
For the art. If you lack that creative spark which drives you to program, you won't create programs, you would implement or rework existing ones.

>>47
Video games are the best art a programmer can make.

I, for one, welcome our new video game overlords.

Lisp OS should provide it's own graphics and audio API. Loading FFI libs is mediocre solution at best. Besides graphics and audio, everything else could be done internally. And we need better alternatives to ZLIB/PNG, because they arent the right thing. I.e. PNG doesnt support random access, meaning that things like http://en.wikipedia.org/wiki/MegaTexture cannot be easily packed into single PNG. PNG is also bad for sprites and GUI elements, which are frequently clipped, meaning no full decompression needed.

Sorry for a long rant. I just hate Worse is Better KISS solutions.

Lisp is shit.

>>51
No.

>>50
You will never amount to anything of significance.

>>53
My failure wont stop Unix/Linux from being a crappy OS.

>>50
Ever heard of the Single Responsibility Principle or Do One Thing And Do It Well?

Attempting to build file formats that handle a multitude of use cases will only amount to a format that is mediocre everywhere.

PNG, or Portable Network Graphics, has largely been successful at providing ``portable network graphics'' file format with lossy compression and adequate support for different pixel formats.

In fact, why would you even think about using PNG for textures, mega-textures, and the like outside of prototyping a game? PNG is a good intermediate format during development of a game, and provides an interchange container between the content creation tools and your engine's preprocessing tools. But in the context of game development, that's all it's meant for.

Generally, you set up your engine preprocessing tools to convert images to either raw or a special compressed format that your GP can decompress using specialized hardware at no cost, like DXTC/S3TC or PVRTC. That way, loading in a level's texture is super fast, you just do a single unbuffered POSIX read or Windows ReadFile call for the *entire* texture into a memory buffer and transfer it to the GPU using the relevant Direct3D/OpenGL call, no additional processing or decompression required.

It also results in simpler code and less bloated game binaries. All of the bloat and complexity is hidden in the preprocessing aka mod tools.

>>55 knows what ey's talking about. Massive precomputation is the Right Thing.

>>56
ey
fuck off and die you feminist piece of shit

>>57
ey is gender-neutral, not feminine.

>>55
file format with lossy compression
PNG is a lossless format.

>>58

he wasn't questioning the sexuality of "ey" you fucking retard. It is no secret you are a feminist piece of shit.

Fuck off and die.

>>59
All lossless format can also be lossy because nothing prevents the encoder from changing the data in order to increase the compression efficiency.

>>55
Single Responsibility Principle or Do One Thing And Do It Well?
Yes. PNG is responsible for being slow and not allowing random access. PNG is also responsible for being a binary format, when sane people want symbolic expressions: you know, putting quickly object placement info into extension chunk, so one could use PNG for holding maps for a video game, which are also rectangular and compress well.

>>8-41

-> ls -ahl SDL-1.2.14.tar.gz SFML-1.6-dev-linux-32.tar.gz
-rw-r--r-- 1 matt users 3.9M Nov 22 05:53 SDL-1.2.14.tar.gz
-rw-r--r-- 1 matt users 713K Nov 22 05:55 SFML-1.6-dev-linux-32.tar.gz

The actual source of SFML is much less than SDL.

>>63
implying documentation, image files, configure and unit tests are actual source code

>>64

-> du -sh SDL-1.2.14/src/ SFML-1.6/
6.9M    SDL-1.2.14/src/
2.2M    SFML-1.6/

Here. The entire SFML directory is just source code because I didn't download the SDK. The /src directory in the SDL directory is 100% source.

3 times bigger.

>>59
It was a typo. I also meant ``GPU'' when I said ``GP''.

>>62
so one could use PNG for holding maps for a video game, which are also rectangular and compress well.
No, you don't get it. PNG was never meant for that, so stop wishing it did.

If you want that, create your own file format.

SFML is C++ crap, meaning it can be used only with that crap language. So it's totally useless.

>>68

There isn't any reason to use either SDL or SFML when you can just use OpenGL directly with GLUT.

>>69
opengl recuires graduate math skill. you'll have set up matrices, materials, light and the shitz.

Also, opengl requires using C++ to write shaders. If you dont like C++ you'll get nowhere in opengl.

>>71
opengl requires using C++ to write shaders
No it doesn't.

>>70
opengl recuires graduate math skill.
If you don't have the patience to learn OpenGL, you shouldn't be programming.

opengl is so shit it is funny. I am not a Microsoft fun but Direct3D is a way better library.

>>74
Except on platforms without Direct3D.

>>75
Yeah, that sucks.

>>73
http://30.media.tumblr.com/tumblr_ksp4rtsWiE1qzpwi0o1_500.png

>>72
It does.
http://en.wikipedia.org/wiki/GLSL

#version 120
#extension GL_EXT_geometry_shader4 : enable
 
void main() {
  for(int i = 0; i < gl_VerticesIn; ++i) {
    gl_FrontColor = gl_FrontColorIn[i];
    gl_Position = gl_PositionIn[i];
    EmitVertex();
  }
}

ugly curly brace crap. pure unix KISS shit.

>>77
It looks like C but that is all. Your code is valid in Java too, so should we say learning GLSL requires Java knowledge?

>>73
What if I dont believe in Set Theory? There are no standalone linear algebra book - all use some kind of "vector space over rational field" pseudoscience.

>>78
If it ain't Lisp, it's crap.