Allegro.cc - Online Community

Allegro.cc Forums » Off-Topic Ordeals » Allegro vs SDL (revisited)

This thread is locked; no one can reply to it. rss feed Print
 1   2 
Allegro vs SDL (revisited)
Onewing
Member #6,152
August 2005
avatar

I assumed this was a topic from before, so I did a search on it. Funny enough, this was the first thing said in the first reply to the Allegro vs SDL thread:

Quote:

Noooo! Fool! You'll get us all involved in the Allegro vs SDL battle again

Of course, this thread dates back to 2002, so I thought I'd reopen the topic (there might be a more recent thread out there, but I'm lazy). Any comments on pros and cons of the packages? I'm thinking of joining a team who's working on a SDL project and wanted to get some insight on it first. I haven't looked at anything on SDL itself, so feel free to give me any pointers as well.

Also, in this group, one guy is very pro PureBasic. I haven't looked into it at all. I liked DarkBasic to some degree, but I don't know if the two can compare.

I'll read your delicious comments tomorrow (uh oh, just referred to a post as "delicious"...initiate beating of self).

[edit] You know what...

------------
Solo-Games.org | My Tech Blog: The Digital Helm

LennyLen
Member #5,313
December 2004
avatar

Quote:

I'm thinking of joining a team who's working on a SDL project and wanted to get some incite on it first.

I wonder if this thread will insight a heated argument. ;)

Onewing
Member #6,152
August 2005
avatar

You should've seen it before I did a spell check. I originally typed insite, which isn't even a word.....

------------
Solo-Games.org | My Tech Blog: The Digital Helm

Archon
Member #4,195
January 2004
avatar

I think PureBasic is not free.

I've looked at some SDL examples, it takes more to do something opposed to Allegro but in response, it may be more flexible. I have not used SDL before.

kentl
Member #2,905
November 2002

Some people at GDR thought that AllegroGL had some flaws in its support for OpenGL, which SDL wouldn't have. But that is just hearsay and people who have actually used AllegroGL extensively should answer to this thread.

Simon Parzer
Member #3,330
March 2003
avatar

Quote:

Some people at GDR thought that AllegroGL had some flaws in its support for OpenGL, which SDL wouldn't have. But that is just hearsay and people who have actually used AllegroGL extensively should answer to this thread.

That's true.
In SDL, you need no other library to use OpenGL. The OpenGL support is already included in the base library, which is relatively small. (Allegro: you have to include the additional library AllegroGL).

Comparison between Allegro and SDL (I've used both): SDL is more lightweight and has a cleaner API. For instance, SDL doesn't include drawing primitives, GUI functions, MIDI, etc. It has only basic functions for framebuffer, audio, threads, etc.
Some people consider Allegro bloated because it includes things like loading functions for different graphics/audio formats, FLIC animations, GUI functions, drawing primitives (circle,line,get/setpixel) etc.

When it comes to performance, I don't really see a difference between them.

So, to sum it up, SDL is just a layer on top of the platform specific low-level functions. Allegro is a complete game programming library.

Archon
Member #4,195
January 2004
avatar

Also note that SDL is LGPL while Allegro is giftware.

To keep your program close sourced, you have to include a licence notice with your distributions.

Evert
Member #794
November 2000
avatar

A thread topic that sounds less like flamebait would have been better, I think. ;)

Quote:

Any comments on pros and cons of the packages?

Some of SDL's internal code and its directory structure is much worse than Allegro's. I don't think you can disable SDL's magic main mangling and you need to have main as int main(int, char**). Other than that... I haven't looked at SDL extensively, certainly not recently.

Quote:

Some people at GDR thought that AllegroGL had some flaws in its support for OpenGL, which SDL wouldn't have.

Now that is interesting. What AllegroGL does is create the OpenGL window and provide functions for converting Allegro BITMAPs. For the rest you use OpenGL as you would normally.
I can't imagine what they are refering to.

Of course, needing AllegroGL CVS to work with Allegro 4.2 is a bit annoying.

Simon Parzer
Member #3,330
March 2003
avatar

Quote:

I don't think you can disable SDL's magic main mangling and you need to have main as int main(int, char**).

What about "#undef main" before your main function?

kentl
Member #2,905
November 2002

Quote:

Now that is interesting. What AllegroGL does is create the OpenGL window and provide functions for converting Allegro BITMAPs. For the rest you use OpenGL as you would normally. I can't imagine what they are refering to.

Me neither, but as I haven't tried AllegroGL asking follow up questions seemed futile for me. The comment was made in this thread at GDR, it's the sixth post created by PoV. So if you/anyone want's to you can ask for yourself, as you know how this works I am sure your question will be more intelligent than mine.

Thomas Harte
Member #33
April 2000
avatar

Quote:

When it comes to performance, I don't really see a difference between them.

There shouldn't be a difference on the Windows platform up to now. In the future it will become possible to write faster DirectDraw apps with Allegro than SDL because we've worked acceleration for some things into Allegro that are not supported by the SDL API at all. But as most people use OpenGL for most things now, the difference is principally academic.

On non-Windows platforms, SDL will often outperform Allegro because it has a more professional team behind it - in that most of them are literally professionals. For example, here on OS X SDL uses the vector unit for fast software blits whereas Allegro has a C loop that just copies one pixel at a time, even if that means looping byte by byte.

In addition, SDL support many more platforms than Allegro. Although the Allegro drawing and sound APIs are more feature packed than those included in SDL that's because in SDL there is almost an assumption that you'll use OpenGL and download addons. There are a series of "official" addons that do things like add TTF rendering, add a full mixer with MP3/OGG/MOD support, etc. It could be argued that SDL provides better platform neutrality because a lot of the things in its core API that are not in Allegro's would require platform specific code - e.g. CD player control, threads - whereas a lot of the things in Allegro's code that are not in SDLs are things that have to be done in software on almost every modern platform anyway - e.g. vector drawing to [the equivalent of] BITMAPs.

Quote:

The comment was made in this thread at GDR [gamedevelopersrefuge.org], it's the sixth post created by PoV.

Taking this to mean:

Quote:

There's some nostalgic value for me by using Allegro, but I've found it's add on AllegroGL to be rather unreliable. So, my shame to the Allegro nation is I've switched to SDL for it's OpenGL interface instead.

There have indeed been some serious issues with AllegroGL. For example - due to a typo where a mutex was unlocked prior to an important function then unlocked again at the end, it didn't work at all on my system until a very recent fix by Peter Hull.

I think these are mostly declining in number now, hopefully AllegroGL will soon be good enough for incorporation into the main distribution for 4.3.0 (NOTE: pure speculation on my part).

Peter Hull
Member #1,136
March 2001

Quote:

For example, here on OS X SDL uses the vector unit for fast software blits whereas Allegro has a C loop that just copies one pixel at a time, even if that means looping byte by byte.

You mean stuff likethis file? I wonder if there are any benchmarks for this; it's a lot of extra code to maintain if it doesn't deliver much!

I checked SDL performance on OSX some time ago; it's quite a lot faster, partly because it 'cheats' - it locks the QuickDraw port and never releases it. It can then do direct access to memory any time it wants. This is not the official, proper way to do things, but it does work! Also IIRC there's a part where something is repeatedly locked with no balancing unlock; I forget the details.

My hope, too, is that 4.3 will be OpenGL based.

Pete

ps.

Quote:

For example - due to a typo where a mutex was unlocked prior to an important function then unlocked again at the end, it didn't work at all on my system until a very recent fix by Peter Hull.

That typo was introduced by the very same Peter Hull :-[

Archon
Member #4,195
January 2004
avatar

Quote:

My hope, too, is that 4.3 will be OpenGL based.

I thought that that would be a major (Allegro 5.x+) upgrade.

HoHo
Member #4,534
April 2004
avatar

Quote:

I thought that that would be a major (Allegro 5.x+) upgrade.

But why wait? Except for remote mindcontrol most of Allegro5 functionality will probably be availiable on 4.4 :)

__________
In theory, there is no difference between theory and practice. But, in practice, there is - Jan L.A. van de Snepscheut
MMORPG's...Many Men Online Role Playing Girls - Radagar
"Is Java REALLY slower? Does STL really bloat your exes? Find out with your friendly host, HoHo, and his benchmarking machine!" - Jakub Wasilewski

Thomas Harte
Member #33
April 2000
avatar

Quote:

You mean stuff like this file [libsdl.org]?

That's the code for blitting surfaces with alpha channels.

Quote:

I wonder if there are any benchmarks for this; it's a lot of extra code to maintain if it doesn't deliver much!

Well it would be hard to do a fair comparison. In Allegro blits take effect immediately, in SDL they have to be flushed with UpdateRect[s]. UpdateRect[s] on the screen are optimised for "once a frame" calling, whereas presumably Allegro's blit is optimised for "lots of times a frame" calling. Similarly, Allegro is forcibly doing all of its event stuff all the time whereas SDL only deals with events when the user specifically tells it to.

Nevertheless, I've done a quick probably unscientific test by blitting from one 32x32 memory buffer to another. SDL does no event handling, so this isn't an indisputably fair comparison. I didn't want to get bogged down into a debate about how many blits is realistic frame on frame.

Code is at the end for both platforms. I'm sure there are a million criticisms that could be levelled at it, so take everything with a pinch of salt.

At 32bpp, SDL beats Allegro by a significant margin, achieving 59295.20 blits/second on my machine versus 40573.54 for Allegro - i.e. about 47% faster. The better news for Allegro was my other test, of 8bpp mode. SDL grows to 167249.80 blits/second while Allegro hits 126534.13, making SDL only around 32% faster.

Because of the larger than expected margin in these numbers, I am going to assume my source is at fault for the time being. A decent test would at least try various sizes of bitmap. Please comment. Note that RAND_MAX on OS X is (2^32 - 1), hence the shifting. Code as pasted below is from 8bpp tests.

1/* Simple program: Create a blank window, wait for keypress, quit.
2
3 Please see the SDL documentation for details on using the SDL API:
4 /Developer/Documentation/SDL/docs.html
5*/
6
7#include <stdio.h>
8#include <stdlib.h>
9#include <string.h>
10#include <math.h>
11#include <time.h>
12 
13#include "SDL.h"
14 
15int main(int argc, char *argv[])
16{
17 Uint32 initflags = SDL_INIT_VIDEO; /* See documentation for details */
18 SDL_Surface *screen, *garbage, *t, *target;
19 Uint32 videoflags = 0;//SDL_ANYFORMAT;
20 int done;
21 SDL_Event event;
22 
23 /* Initialize the SDL library */
24 if ( SDL_Init(initflags) < 0 ) {
25 fprintf(stderr, "Couldn't initialize SDL: %s\n",
26 SDL_GetError());
27 exit(1);
28 }
29 
30 /* Set 640x480 video mode */
31 screen=SDL_SetVideoMode(640,480, 8, videoflags);
32 if (screen == NULL) {
33 fprintf(stderr, "Couldn't set video mode: %s\n", SDL_GetError());
34 SDL_Quit();
35 exit(2);
36 }
37 
38 t = SDL_CreateRGBSurface(SDL_SWSURFACE, 32, 32, 8, 0, 0, 0, 0);
39 garbage = SDL_DisplayFormat(t);
40 SDL_FreeSurface(t);
41 
42 t = SDL_CreateRGBSurface(SDL_SWSURFACE, screen->w, screen->h, 8, 0, 0, 0, 0);
43 target = SDL_DisplayFormat(t);
44 SDL_FreeSurface(t);
45 
46 int blits = 0, countedblits, countedseconds = 0;
47 time_t stime, etime;
48 
49 etime = time(NULL);
50 /* try and align to a second */
51 do
52 {
53 stime = time(NULL);
54 }
55 while(etime == stime);
56 
57 done = 0;
58 while ( !done ) {
59 SDL_Rect Pos;
60
61 Pos.x = ((rand() >> 16) * 640) / (RAND_MAX >> 16);
62 Pos.y = ((rand() >> 16) * 480) / (RAND_MAX >> 16);
63 SDL_BlitSurface(garbage, NULL, target, &Pos);
64 SDL_UpdateRect(target, Pos.x, Pos.y, Pos.x+garbage->w, Pos.y+garbage->h);
65 blits++;
66 
67 etime = time(NULL);
68 if(etime != stime)
69 {
70 countedblits = blits;
71 countedseconds++;
72 stime = etime;
73
74 if(countedseconds == 30)
75 break;
76 }
77 
78 /* Check for events */
79/* while ( SDL_PollEvent(&event) ) {
80 switch (event.type) {
81
82 case SDL_KEYDOWN:
83 case SDL_QUIT:
84 done = 1;
85 break;
86 default:
87 break;
88 }
89 }*/
90 }
91 
92 printf("%d counted seconds, %d counted blits => %0.2f blits/second\n", countedseconds, countedblits, (float)countedblits / countedseconds);
93 
94 /* Clean up the SDL library */
95 SDL_FreeSurface(garbage);
96 SDL_FreeSurface(target);
97 SDL_Quit();
98 return(0);
99}

1/*
2 * BlitTest
3 *
4 * Created by Thomas Harte on 26/01/2006.
5 * Copyright (c) 2006 __MyCompanyName__. All rights reserved.
6 */
7 
8#include <Allegro/allegro.h>
9 
10 
11int main(int argc, const char *argv[])
12{
13 BITMAP *garbage, *target;
14 
15 allegro_init();
16 install_timer();
17 install_keyboard();
18
19// set_color_depth(desktop_color_depth());
20 if (set_gfx_mode(GFX_AUTODETECT_WINDOWED, 640, 480, 0, 0))
21 {
22 allegro_message("Error setting 320x200x8 gfx mode:\n%s\n", allegro_error);
23 return -1;
24 }
25 target = create_bitmap(SCREEN_W, SCREEN_H);
26 garbage = create_bitmap(32, 32);
27 srand(time(NULL));
28
29 clear_to_color(screen, 0);
30 int blits = 0, countedblits, countedseconds = 0;
31 time_t stime, etime;
32 
33 etime = time(NULL);
34 /* try and align to a second */
35 do
36 {
37 stime = time(NULL);
38 }
39 while(etime == stime);
40 
41 while(!key[KEY_ESC])
42 {
43 int x, y;
44
45 x = ((rand() >> 16) * 640) / (RAND_MAX >> 16);
46 y = ((rand() >> 16) * 480) / (RAND_MAX >> 16);
47 blit(garbage, target, 0, 0, x, y, garbage->w, garbage->h);
48 blits++;
49 
50 etime = time(NULL);
51 if(etime != stime)
52 {
53 countedblits = blits;
54 countedseconds++;
55 stime = etime;
56
57 if(countedseconds == 30)
58 break;
59 }
60 }
61 
62 printf("%d counted seconds, %d counted blits => %0.2f blits/second\n", countedseconds, countedblits, (float)countedblits / countedseconds);
63 
64 destroy_bitmap(garbage);
65 destroy_bitmap(target);
66 return 0;
67}
68END_OF_MAIN();

Onewing
Member #6,152
August 2005
avatar

Quote:

A thread topic that sounds less like flamebait would have been better, I think.

My apologies.

Thanks to all the replies (especially Thomas for in-depth explanations and code sample). I feel like I could actually converse with a SDLian in peace without starting a war with us Allegrites...I've been playing Civ a lot lately.
;)

------------
Solo-Games.org | My Tech Blog: The Digital Helm

Matthew Leverton
Supreme Loser
January 1999
avatar

Running TH's code on my Windows computer:

  • 8-Bit

  • SDL with events: 30 counted seconds, 9926271 counted blits => 330875.70 blits/second

  • SDL without events: 30 counted seconds, 124681183 counted blits => 4156039.43 blits/second

  • Allegro: 30 counted seconds, 145440045 counted blits => 4848001.50 blits/second

  • 32-bit
    • SDL with events: 30 counted seconds, 9931946 counted blits => 331064.87 blits/second

    • SDL without events: 30 counted seconds, 124320408 counted blits => 4144013.60 blits/second

    • Allegro: 30 counted seconds, 142063774 counted blits => 4735459.13 blits/second

    [/list]
    But the real test would simply be: Does your game run fast enough on whatever hardware you are targeting?

    Thomas Harte
    Member #33
    April 2000
    avatar

    Those are interesting results because they show Allegro being 16% (8-bit) and 14% (32-bit) than SDL "without events" - which is almost certainly the "fair" way to do it in that putting an event check in every loop probably requires a mutex acquire/release every loop which just isn't realistic.

    The main point of interest is that it strongly suggests that the 47/32% speed advantage of SDL over Allegro on the minority use OS X isn't due to me having made some dumb error in the source. It certain inspires me to see if I can't get a decent OS X 10.4+ port out of Core Image!

    Peter Hull
    Member #1,136
    March 2001

    These results are very strange. I got the same kind of speed differential as Thomas, but I have a G3, so it can't be SDL's altivec code making the difference. It would be interesting to see results on Windows with ALLEGRO_USE_C defined. Is there something inefficient in the C blitters?

    I tried putting acquire_screen()/release_screen() either side of the loop. This should cause the main thread to block when it tries to acquire the window mutex, hence removing any overhead from event processing. This had very little effect on the numbers.

    I’d be interested to see what happens if you use CoreImage to manipulate memory bitmaps. My gut feeling is that it won’t be faster, as it will be general-purpose, robust code, whereas Allegro’s code is optimised for a specific purpose. If it is faster, I would take that to mean that there’s something wrong with Allegro.

    Pete

    Evert
    Member #794
    November 2000
    avatar

    I'd be curious to see what you Mac people get when you compare Allegro's stock blitter with a memcpy (or memmove) based one (patch attached). Personally I don't see any difference at all on my machine, and I think AJ did a like benchmark along with his SSE blitting functions (for which I haven't seen a patch, by the way) that showed the same thing. On the other hand, George Foot reported a huge boost in speed on the GP2X using memmove/memcpy.

    Thomas Harte
    Member #33
    April 2000
    avatar

    With memmove patch applied I got 140504.09 blits/sec in 8bpp mode, 55492.87 in 32bpp mode versus 126534.13 and 40573.54 before and SDL's 167249.80 and 59295.20.

    So, with memmove I see an 11% improvement in 8bpp mode and a 37% improvement in 32bpp mode. OS X SDL now only beats Allegro by 19% in 8bpp mode and around 6% in 32bpp mode, versus 47% and 32% without the patch.

    Tero Laxström
    Member #2,589
    July 2002
    avatar

    I made a bit of testing on my linux machine, I also timed the tests to see that the processor is used where it is supposed to. What's odd, is that the sdl seems to gain almost no speed advance with -O3 enabled. -Os seems to slow it with sdl like you would guess but with allegro it speeds up. :)

    Dunno what you can make of this, but just to show, that on linux allegro loses by not even a notable difference. If you ask from me :)

    Allegro> no parameters:
    30 counted seconds, 1539124 counted blits => 51304.13 blits/second
    real 0m30.975s user 0m24.842s sys 0m2.020s

    Allegro> -Os:
    30 counted seconds, 1592447 counted blits => 53081.57 blits/second
    real 0m30.990s user 0m28.754s sys 0m2.000s

    Allegro> -O3:
    30 counted seconds, 1784919 counted blits => 59497.30 blits/second
    real 0m31.013s user 0m28.434s sys 0m2.320s

    SDL> no parameters:
    30 counted seconds, 1937100 counted blits => 64570.00 blits/second
    real 0m30.972s user 0m28.618s sys 0m2.216s

    SDL> -Os:
    30 counted seconds, 1708026 counted blits => 56934.20 blits/second
    real 0m31.001s user 0m25.726s sys 0m1.840s

    SDL> -O3:
    30 counted seconds, 1940967 counted blits => 64698.90 blits/second
    real 0m30.999s user 0m28.614s sys 0m2.148s

    --
    tlax

    Simon Parzer
    Member #3,330
    March 2003
    avatar

    "Allegro vs SDL" benchmarks are more than useless. The speed is comparable and the differences are mainly results of your specific hardware combination/drivers.

    Peter Hull
    Member #1,136
    March 2001

    Quote:

    more than useless

    i.e. useful?

    I agree that these simple synthetic benchmarks are not the most important thing in the world, but I think in this case it's pointing to something that can be improved in Allegro.

    Pete

    HoHo
    Member #4,534
    April 2004
    avatar

    TH code on My P4, Linux. Currently only 8bit results:

    SDL emerged with GCC 3.4.4, flags in make.conf: CFLAGS="-O2 -march=pentium4 -pipe -fforce-addr -momit-leaf-frame-pointer -fomit-frame-pointer -ftracer -pipe"
    CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"

    30 counted seconds, 10002756 counted blits => 333425.20 blits/second

    Allegro
    GCC 3.4.5 with no extra flags to configure:
    30 counted seconds, 16189763 counted blits => 539658.77 blits/second

    GCC 3.4.5, --enable-asm=no:
    30 counted seconds, 12980463 counted blits => 432682.10 blits/second

    GCC 4.1.0, no extra flags:
    30 counted seconds, 15985689 counted blits => 532856.30 blits/second

    GCC 4.1.0, --enable-asm=no:
    30 counted seconds, 13229992 counted blits => 440999.73 blits/second

    I know comparing to SDL is quite difficult considering it probably had better compile flags but I doubt it would change a lot if I would use the same flags for both of them.

    Seems like for some weird reason ASM version is a bit faster than C code allthough my previous tests have said otherwise.

    If anyone wants to I could run allegro through all kinds of tests on my machine. Just tell me what compiler flags to use or what program to run and I will do it :)

    __________
    In theory, there is no difference between theory and practice. But, in practice, there is - Jan L.A. van de Snepscheut
    MMORPG's...Many Men Online Role Playing Girls - Radagar
    "Is Java REALLY slower? Does STL really bloat your exes? Find out with your friendly host, HoHo, and his benchmarking machine!" - Jakub Wasilewski

     1   2 


    Go to: