SDL vs SFML vs Allegro?

[OmenFelix]

Hey, just out of interest, can some enlighten me as to which API you would say is the finest to use?

NOTE: I currently use SDL, as all the OOP crap drives me mad. I'm a procedural guy myself. :3

[superLED]

Hey, just out of interest, can some enlighten me as to which API you would say is the finest to use?

NOTE: I currently use SDL, as all the OOP crap drives me mad. I'm a procedural guy myself. :3

I would just stick to SDL until you are are ready to dive into OpenGL, if you're not so found of "OOP crap".

[OmenFelix]

Hey, just out of interest, can some enlighten me as to which API you would say is the finest to use?

NOTE: I currently use SDL, as all the OOP crap drives me mad. I'm a procedural guy myself. :3

I would just stick to SDL until you are are ready to dive into OpenGL, if you're not so found of "OOP crap".

OpenGL is procedural, or at least doesn't use any object-orientated features. I was only curious, not planning on switching as I've already tasted the poison that is OpenGL and it didn't taste nice. :P

[Nokurn]

Earlier this year I was moving between libraries a lot trying to find one I liked for this cross-platform game project that I was preparing to start. Here's my thoughts on the listed ones:

SDL 1.2
I never liked this SDL 1.2 all that much, but that's not why I ruled it out in this case. This particular game would use a lot of rotation, which SDL's software renderer can't handle quickly at all. You can bypass this by using OpenGL for rendering and SDL for window creation, input, etc.. But I just wanted to use a hardware accelerated library, so I tried...

SDL 1.3/2.0
This is, in my opinion, a massive step up from SDL 1.2. It's got a cleaner API, it's hardware accelerated, it supports multiple windows, and it doesn't use the GPL/LGPL. I decided against it because it's not yet officially released. I will revisit it later once it is, which I expect to be soon given the rate of updates on the Mercurial repository.

SFML 1.6
The API is nice, but it feels a bit restricted at times. It didn't support the peculiar viewport transformations that I needed to do to. It's soon to be deprecated by SFML 2.0.

SFML 2.0
SFML 2.0 didn't support Mac OS X at the time, which I use as my primary development platform, so I didn't give it much consideration. I do however like the improvements made from SFML 1.6 and will likely try it again once it comes out of RC.

Allegro 5
This is the library I settled on. It has good support for my two target platforms (Windows and Mac OS X), though I did find some bugs in the OS X port, which I had to work around. The API is extremely powerful and goes far beyond any of the other libraries listed here. It's hardware accelerated. It has abstractions for the file system (important for the directory enumerations this game uses) and configuration files. It can be easily integrated with physfs (important for the mods this game supports). Its addons (which are built from the same source tree) are very useful; as someone who doesn't think exit(1) is the proper response to fatal errors, I am especially fond of the native dialogs addon. The only thing that the API lacks is networking. In general, it's been a pleasure to use.

I'm afraid I can't give much insight on anything other than Allegro 5, but I'm sure there are others on this forum to represent them. So far it seems like I'm the only actual A5 user here, so I feel obligated to support it.

[dandymcgee]

Thank you for the insightful and unbiased review Nokurn!

@OP - There are already many discussions regarding these APIs on these forums. You may find it beneficial to search around and read some the responses from the past.

[OmenFelix]

Thank you for the insightful and unbiased review Nokurn!

@OP - There are already many discussions regarding these APIs on these forums. You may find it beneficial to search around and read some the responses from the past.

And I may do that. :3

[OmenFelix]

Earlier this year I was moving between libraries a lot trying to find one I liked for this cross-platform game project that I was preparing to start. Here's my thoughts on the listed ones:

SDL 1.2
I never liked this SDL 1.2 all that much, but that's not why I ruled it out in this case. This particular game would use a lot of rotation, which SDL's software renderer can't handle quickly at all. You can bypass this by using OpenGL for rendering and SDL for window creation, input, etc.. But I just wanted to use a hardware accelerated library, so I tried...

SDL 1.3/2.0
This is, in my opinion, a massive step up from SDL 1.2. It's got a cleaner API, it's hardware accelerated, it supports multiple windows, and it doesn't use the GPL/LGPL. I decided against it because it's not yet officially released. I will revisit it later once it is, which I expect to be soon given the rate of updates on the Mercurial repository.

SFML 1.6
The API is nice, but it feels a bit restricted at times. It didn't support the peculiar viewport transformations that I needed to do to. It's soon to be deprecated by SFML 2.0.

SFML 2.0
SFML 2.0 didn't support Mac OS X at the time, which I use as my primary development platform, so I didn't give it much consideration. I do however like the improvements made from SFML 1.6 and will likely try it again once it comes out of RC.

Allegro 5
This is the library I settled on. It has good support for my two target platforms (Windows and Mac OS X), though I did find some bugs in the OS X port, which I had to work around. The API is extremely powerful and goes far beyond any of the other libraries listed here. It's hardware accelerated. It has abstractions for the file system (important for the directory enumerations this game uses) and configuration files. It can be easily integrated with physfs (important for the mods this game supports). Its addons (which are built from the same source tree) are very useful; as someone who doesn't think exit(1) is the proper response to fatal errors, I am especially fond of the native dialogs addon. The only thing that the API lacks is networking. In general, it's been a pleasure to use.

I'm afraid I can't give much insight on anything other than Allegro 5, but I'm sure there are others on this forum to represent them. So far it seems like I'm the only actual A5 user here, so I feel obligated to support it.

Thankyou! How very insightful of you.

[lalacomun]

well i recomend you SDL since you can start right away with OpenGL for getting hardware acceleration but you can also get SDL 2.0 from mercury repos,in this version offers you hardware acceleration without OpenGL but you can also get software render for example:

if you use : SDL_Surface it will be a software accelerated
but if you use SDL_Texture its hardware accelerated

[OmenFelix]

well i recomend you SDL since you can start right away with OpenGL for getting hardware acceleration but you can also get SDL 2.0 from mercury repos,in this version offers you hardware acceleration without OpenGL but you can also get software render for example:

if you use : SDL_Surface it will be a software accelerated
but if you use SDL_Texture its hardware accelerated

Does SDL_Texture work the same as the Surface one in the sense of loading and rendering? Please elaborate as I'm intrigued. :3

[lalacomun]

well i recomend you SDL since you can start right away with OpenGL for getting hardware acceleration but you can also get SDL 2.0 from mercury repos,in this version offers you hardware acceleration without OpenGL but you can also get software render for example:

if you use : SDL_Surface it will be a software accelerated
but if you use SDL_Texture its hardware accelerated

Does SDL_Texture work the same as the Surface one in the sense of loading and rendering? Please elaborate as I'm intrigued. :3

here is a code where you can see al textures functions for loading them to blitting them:
http://hg.libsdl.org/SDL/file/601b0e251 ... tsprite2.c
as you can see there are several funtions sush as SDL_CreateTextureFromSurface, SDL_Renderer* etc..
and here a guide for porting your SDL 1.2 projects to SDL 1.3/2.0:
http://wiki.libsdl.org/moin.cgi/Migrati ... e_surfaces

[OmenFelix]

well i recomend you SDL since you can start right away with OpenGL for getting hardware acceleration but you can also get SDL 2.0 from mercury repos,in this version offers you hardware acceleration without OpenGL but you can also get software render for example:

if you use : SDL_Surface it will be a software accelerated
but if you use SDL_Texture its hardware accelerated

Does SDL_Texture work the same as the Surface one in the sense of loading and rendering? Please elaborate as I'm intrigued. :3

here is a code where you can see al textures functions for loading them to blitting them:
http://hg.libsdl.org/SDL/file/601b0e251 ... tsprite2.c
as you can see there are several funtions sush as SDL_CreateTextureFromSurface, SDL_Renderer* etc..
and here a guide for porting your SDL 1.2 projects to SDL 1.3/2.0:
http://wiki.libsdl.org/moin.cgi/Migrati ... e_surfaces

Thanks!