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?

>>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.