Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

SFML 2.0 vs SDL 1.3

Name: Anonymous 2011-11-21 0:01

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 !!mJCwdV5J0Xy2A21 2011-11-22 9:19

If >>70 don't like OpenGL that much, i have to remind, software rendering is several orders of magnitude slower and there is no magic SSE hack which is "at the same speed as GPU" since GPU has thousands of fully parallel cores and CPU is limited to max 4-8 cores explicitly managed by the program(not by hardware,as in GPU parallel calculations). Software rendering is fit only for small, low-resource games and demos.
Perhaps when GPU features are merged into CPU die entirely the need for separate GPU will disappear, and OpenGL will become historical curiosity, but today isn't the year of integrated GPU(despite AMD efforts).

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List