A programmer friend of mine recommended I switch to SDL, after reading a bit about it and seeing that I can actually switch without too much trouble in configurating compilers and compiling libraries and stuff, I decided to see which one is better before coming to any decision.
So I ran a search for "allegro VS SDL" on these forums, and after reading all sorts of things I found this post that suggested a benchmark for comparing the two, and decided to run it myself.
I copy pasted the code, and modified it a bit since it made the program crash :S
I ended up with:
Allegro: (the allegro messages were to help me find out what was causing it to crash, which was the commented-out rand()s)

And for SDL:

The results were quite surprising, considering the results reported in that thread;
SDL came up with "30 counted seconds, 185213878 counted blits => 6173795.93 blits/second", compared to allegro's 13361577 => 445385.9, ~13-14 times faster
Does this even make sense? Did I perhaps make a mistake?
(The test was run on Allegro 4.2.1 and the latest SDL if I'm not mistaken. On an Athalon 64 3000+ and a geforce 4 MX420)
My main beef with allegro is its poor performance, which means that any high-resolution games are impossible to make if you have many objects onscreen (when a dirty rectangle system just won't help), so this is quite interesting to me.

For hires games, hardware-accelerated is the way to go anyway, so why not switch to AllegroGL (and maybe OpenLayer)? It's not hard, and it's supported on virtually anything capable of decent hires performance anyway.
Also, Allegro is not made for cutting-edge performance, but rather for solid multiplatform programming with a relatively easy-to-use interface with decent performance. Since Allegro doesn't use any graphics hardware acceleration except the very basic ones (vram -> vram blits), you can't compare its performance to anything truly accelerated. OTOH, if you run that benchmark on an ancient machine, maybe even under MS-DOS, the outcome may be very different.

Well, first of all its mostly hires 2D games, nothing too complicated, but just clearing a 1280x1024 bitmap in allegro takes too long. (Not sure how much time it takes on SDL, but if its 15 times faster its definitely good).
Switching to AllegroGL however would require learning OpenGL, which is more complicated, and is a bit much for 2d games.
Also, I'm not really interested in multiplatform support since I can't compile my stuff under anything but windows anyway (I don't even have enough free room on my HD to dualboot), but even so I hear that SDL supports more OS's. (which is of course
irrelevant)

I don't know much about SDL, but I was under the impression that you can get "hardware surfaces" which allow hardware accelerated 2D drawing, which would be sufficient for 2D games.

Learning OpenGL ? With AllegoGL ?

Not really a need.

Check dumbtest:

All you need is allegro_gl_set/unset_allegro_mode();

You're not really required to learn any OpenGL, as Gull stated; and if you do, you'll find it's not really hard. It's also very suitable for 2D applications: You just need to set up a proper ortho projection and make a wrapper to draw a sprite, which is pretty much this:

render_sprite(GLuint texhandle) {
  glBindTexture(GL_TEXTURE_2D, texhandle);
  glEnable(GL_TEXTURE_2D);
  glBegin(GL_QUADS);
  glTexCoords2f(0, 0);
  glVertex2f(0, 0);
  glTexCoords2f(1, 0);
  glVertex2f(1, 0);
  glTexCoords2f(1, 1);
  glVertex2f(1, 1);
  glTexCoords2f(0, 1);
  glVertex2f(0, 1);
  glEnd();
}

...which renders a sprite at (0, 0), sized 1x1. You can use all sorts of matrix transformations (less frightening than it sounds) to put the sprite wherever you want.

To the OP:

Allegro SDL Alle SD is faster!!!11

Seriously: the two libraries have different purposes. Allegro is a game library with loads of useful functions (especially for retro-games).
SDL is a hardware abstraction library. It just gives you cross-platform low-level access to the hardware and that's it. SDL doesn't even have a software mixer or drawing primitives. All you can do is putting out ONE stream of audio and accessing the frame buffer. And about the extension libraries, like SDL_image, SDL_mixer and SDL_ttf -- they are crap.

Why not benchmark OpenLayer together with Allegro and SDL

Because the results would blow our minds and break the universe;)

I was thinking of switching over to SDL a couple years ago, but then I decided against because I was/am lazy that way.

The main difference I can see between your two code snippets is that the SDL has an explicit SDL_UpdateRects, which is a call that Allegro has no analogue to. In SDL terms, it says "I've changed this part of the display, please ensure my change was processed" - which is extremely handy when your program only outputs in one colour depth/format and SDL is displaying your output on a screen with a different colour depth/format because it severely cuts down the amount of work that has to be done. Partly because you don't necessarily want the entire screen to be updated, but mostly because it gives you a chance to explicitly say "the drawing is done now, update the real display if you need to".

That said, you've mangled the call to SDL_UpdateRect (why change it from (target, x, y, x+garbage->w, y+garbage->h) to (target, x, x, y+garbage->w, y+garbage->h)?) so if the demo is still appearing correctly then it seems there is no colour conversion required and the call has no effect in this particular program versus your particular display.

But overall, I agree with everyone else. Use a proper hardware API like OpenGL if you actually care at all about performance. And for god's sake, please remember not to use 100% CPU if you don't need to. And rest(1) is not sufficient!

This is something of a reimagining, isn't it? Allegro is made for cutting-edge 1994 performance and retains lots of exciting ASM optimisations for 486 processors. It has a complicated API that's designed for the world of MS-DOS, though it has some extensions that can, sometimes, provide decent performance on Windows computers. Software rendering performs reasonably well on Windows versions prior to Vista, on all other operating systems it is extremely slow.

It doesn't matter how you get there, and I'm repeating myself and everyone above me, but I can't see that it makes any sense to plan anything other than an OpenGL route nowadays.

Even Allegro's 'poor' 445385 blits per second would let you have 9000 sprites on the screen running at 50fps. Is that not enough?

I'm not an SDL expert but, in your SDL benchmark, you're not initialising Pos. So Pos.x and .y might well be offscreen, which means that SDL_BlitSurface will return very quickly without doing anything. Likewise SDL_UpdateRect - I guess that will also do nothing if if y+garbage->w <= x. Thomas can probably comment.

Last time I checked, Allegro's exciting asm code did make it faster than SDL in some circumstances (memory blits with colour conversion IIRC) but I think modern compilers have made Allegro's C version as good as the asm, so that probably no longer applies.

Allegro's good because it includes a lot (SDL doesn't even have putpixel) but bad because it's hard to make proper use of modern hardware. The API choice is more a matter of personal preference. IMO.

Pete

Well, I've recently switched from Allegro to SDL, and I'm quite happy with the switch. However, I did it precisely because I needed less and less of Allegro, until all that was left could easily be provided by SDL (or either SDL_image, SDL_mixer, SDL_ttf).

In my opinion SDL allows for cleaner code when used only as a basis for and engine and (whether we like it or not) it has a bigger user base and wider cross-platform capabilities, which is always nice.

On the other hand, Allegro is way better for people who are still learning exactly because of its all-in-one approach, and newbies are likely to be satisfied by what Allegro offers out of the box. However, when you start needing more, you are forced to use a lot of add-ons (AllegroGL for graphics, AlOgg for music, something for PNGs and JPGs, something for TTF fonts etc.) and this advantage is lost, as you can just as easily find similar add-ons built on top of SDL.

I see an openning for a Douglas Adams quote!

I wasn't thinking of the Hitch Hiker's Guide to the Galaxy, but props to you! It's all good!

... I mean, yes. Congratulations on picking up on my (thinly) veiled reference to a great work of art

It's my own fault for misreading the documentation, writing the original comparison incorrectly and posting incorrectly on this thread, but arguments to UpdateRect are (x, y, width, height). So whether y+garbage->w should always do at least as much as you want depends on whether y is always positive. Since it seems not to be set, I guess it's hard to be sure!

To further this comment, SDL was designed as a hardware API abstraction layer. It's pretty much a subset of DirectDraw with a much nicer API. It's a conduit to blitter hardware. If you want anything more than that then it also encapsulates OpenGL.

Allegro is an "everything you could ever want" library from the DOS era. So it has a million different functions, and a million ways of doing any single thing. It is extremely difficult to adapt to any hardware API in particular and no longer provides anything like "everything you could ever want" as people have stopped storing their graphics in PCX files, using bitmapped fonts and playing their music from MIDIs.

I think Peter has a good point re:9000 sprites at 50 fps. Though I would prefer a CPU + GPU solution (e.g. SDL in OpenGL mode, AllegroGL, OpenLayer) because it distributes the processing across the computer and thus distributes the heat, meaning that fans are less likely to come on. That is, provided you don't do some 80s style busy waiting!

I'm tempted to switch to SDL too, I use OpenGL for graphics and allegro for everything else (except GUI and 3D), I have a few questions for those who already use SDL:

- what compilers it supports ?
- does it use OpenGL natively or it has an add-on ?
- for what Jakub said, are those add-ons (PNG, OGG, TTF) easier/better than allegro's ?
- does it have a GUI API ?
- does it have a datafile/resource API ?
- for Mac OS, is it easier/better supported than allegro ?
- and same question for networking..

Much the same as Allegro, with some more diverse 'unsupported' targets (Dreamcast, Symbian, etc)

Natively, but all it will help you do graphics wise is create the OpenGL window (or full screen mode, obviously) — it's not going to open PNG files and repackage them into GL textures on its own, for example. Which OpenLayer will.

They're probably much the same. There's no 'PNG' or 'OGG' add-ons in that sense though. SDL_image handles loading image files (other than BMP, which is built into the base library) — which includes PNG. And JPEG. And a bunch of others. Similarly SDL_mixer provides a bunch of helpful stuff for sound and music files.

No.

No.

It's better supported. The API is the same on OS X as the other platforms, so I guess the answer to the rest of the question depends on your perspective on that.

It has a built in thread-safe message passing system which in my opinion makes it easier to combine SDL programs with native GUIs than Allegro, if you're talking about putting a cocoa front-end on a program or something like that.

There's no networking built into SDL, much as there isn't any networking built into Allegro.

SDL also provides low-level interfaces to most other hardware a game would need - keyboard/mouse/joystick input, audio and video output. It also includes threading (something that I consider a big gap in Allegro's API) and timing.

Yup, it's great while you think simple - but let us remember that these are raw blit()'s, no masking, no blending, no transformations. The practical number is likely to be lower, and once you start talking about 100FPS (my refresh rate while I was still using a CRT) it does become annoying. Likewise when you would like to run in 1680x1050 (my LCD's native resolution) with double-buffering.

Nope, but that is its advantage for me - it's smaller and cleaner because of this, and allows you to mix and match until you're happy. That was the main reason I started considering SDL instead of Allegro - I realised that aside for initialization, I use about 10 functions total from Allegro since I replaced almost everything for one reason or another . And most of those functions left were hidden under a wrapper of sort, which made it easier to replace them.

While they are not easier or better per se, they are much more stable on average. Don't get me wrong, I'm very impressed with the consistent updates of some of Allegro add-ons (for example, lillo was always doing a great job on JPGAlleg), but some are notorious for being buggy and/or out of date. I can think of about five different TTF libs for Allegro, most of which either are no longer compatible with newer versions of Allegro, have weird installation issues with newer compilers, or are just plain buggy. SDL_ttf on the other hand is (as far as I can tell) well-maintained and up to date.

As Thomas said, there is a large array of unofficial ports, which are less frequently updated - but you can usually find a stable if a bit dated version for most hardware. Still, both are portable enough across the popular platforms, with SDL probably having a bit of an edge on Macs. Also, there are some notable advantages in Windows joystick handling (Allegro sometimes reports incorrect/incomplete stick data).

This enlightened my mind. Thank you and bye.
I must do this now that my program's development is frozen due to lack of inspiration.

thanks for the replies guys, I think I must try it.

in my case, the only downside I see now, is the lack of a datafile and packfiles, but I guess that can be implemented without much trouble or perhaps rip it off from allegro.

Re: my example is flawed responses.
Well, I don't know any SDL, I just copied the code I link to, and then messed with it a bit to find out why it was crashing, so I have no idea if it is a fair or unfair benchmark. Which is also why I posted this thread in the first place.

Re: 9000 sprites at 50 fps
Those are 32x32 sprites. If there's 0 overlap there are 1280 of those onscreen at a time. I agree this should definitely be enough, however the problems start when you add logic into it, because the drawing+logic take a serious toll on the CPU, which is why having "lighter" drawing is nicer.
I was particularily crossed by the "Tiny new physicsy game" I posted a while back. When I ran that on 1280x1024 with memory bitmaps it ran like crap, even though its only a black background and a couple of lines and filled circles (oh, and some text), I admit there's no clever dirty rectangles or any other performance boosters, but its a fact that my CPU was unable to run that game properly. (It actually ran perfectly fine when I switched to video bitmaps [which I forgot about ], but I understand those don't work perfectly yet [or even worse than memory bitmaps in some/most? cases])

Re: Not use 100% CPU
That was just a test to see how it performed under pressure. Obviously I don't use 100% CPU for games most of the time.

IMO SDL is nice, but when you use it, consider doing the gfx with OpenGL.
What I don't like are the "addon" libraries like SDL_mixer, SDL_image or SDL_ttf. They are bloated and not implemented very well. I mean, in a game where I only need to open PNG files, SDL_image forces me to include a whole JPEG library. In a game where I write my own music engine SDL_mixer forces me to include MP3 (libmad), OGG (libvorbis), MOD (mikmod ) and MIDI (timidity) libraries. And SDL_ttf is just a thin wrapper around the freetype library, no need for an extra DLL.

Okay, I'm wondering what else needs to be done to prevent a 100% CPU usage outside of using rest(1).

Simon Parzer: You can always grab that code, reuse it and put it as part of your application, as I did with AlOgg and loadpng for Allegro in mine. That way, you can pick which features you like/need from the original libraries. Unless, of course, they are maintained on a monthly or more frequent basis, which seems not to be the case anymore.

Well, actually, both SDL_image and SDL_mixer allow you to choose the formats you want to support when compiling, and IIRC they even handle this automatically. That is if you don't have a dependency needed for a given format, support for it is dropped during ./configure.

I compiled my SDL_mixer to only support OGGs.

But hey, I'm not claiming SDL or its addons don't have any flaws. I'm just liking it more so far, that's all.

me too.

I think that it should also be mentioned that Allegro is essentially public domain while SDL is LGPL. I've also considered many times using SDL, simply because I prefer using OpenGL, anyway, and don't need the vast majority of Allegro's functions... I just haven't managed to take that step yet.

[EDIT] Besides, Allegro has the Speedhack... that alone should be worth it, right?

Whats wrong with the LGPL? You dont have to include the license if your program is closed source. You can sell your program. LGPL FTW!

P.S. Still, no license is better than any license

No licence means its 100% proprietary, and no one is technically aloud to use, or distribute it.

A licence is just an "easy" way of giving broad permission to "people" to use and/or distribute your work.

I'm now using PTK instead of Allegro, and even though it's a bit buggy and I'm not that fond of the API, it gives me all the basics needed and hardware acceleration (via OpenGL or DirectD3D).

I'm about to run for a train, so no time to post at length. Apologies for that, keep in mind that I'm not being deliberately short.

Oh, I didn't mean the example specifically. It's clearly meant to be a stress test, so 100% CPU is appropriate.

No it doesn't. It can load the LibJPEG (or whatever its called) DLL at runtime, and simply not load JPEGs if the DLL isn't present.

Implementations vary, but the basic idea is that you either (a) use a vsync that sleeps properly (Allegro's may work, it's written in such a way that it may also silently fail); or (b) apply some simple timing logic.

You know how many FPS your game is supposed to work at. So you can work out how long each frame should take. You can also use timing to work out how long each frame has taken. And you can use rest to sleep for the number of milliseconds you specify. So you don't need to use 100% CPU.

We discussed this quite loudly recently, and opinions clearly vary, but for 'pure Allegro' (i.e. no extra libraries), I like this:

Apologies, the above is just typed from the top of my mind, it isn't thoroughly checked.

I haven't read every message and don't know SDL, but surely SDL is using video and the allegro code is using memory buffers, which means the tests aren't equal in any way. Change the create_bitmap to create_video_bitmap and try it again.

I don't think so — "SDL_CreateRGBSurface(SDL_SWSURFACE...)" means create a surface for the fastest possible software blitting, which on a PC means the same as creating a memory bitmap in Allegro. The DisplayFormat thing just makes sure that all the bytes/depths/etc are the same as the display buffer. So it creates a new surface, does a colour conversion blit to it from your original, and returns it.

EDIT: I spotted a logical error in the not-100% CPU code I posted above. You should probably change this bit:

      else
      {
         we're too slow, just jump up to date
         skip next frame;
         framestart = my_timer_var;
      }

To something like:

      else
      {
         we're too slow, just jump up to date
         skipped_count++;
         if(skipped_count&7) skip next frame;
         framestart = my_timer_var;
      }

So that if the computer in question just is too slow to play your game, you still display something, allowing the user to realise what is going on. In this case you'll display every 8th frame, still going too slowly.

Allegro is good for: one-hour hacking, simple testing, games, learning(?); you can scrape something together fairly fast from scratch or mod a previous project without too much thinking about hardware-level.

SDL is good for: providing an engine layer for a semi-serious (gamedev?) project. What you basically do when using SDL is to re-code Allegro as far as you need it. Of course it's faster etc., and combined with OpenGL also more powerful; nothing stops you from actually achiving commercial outlook with some labour (scenegraphs etc are available, OI e.g.). Now once you have a basecode set up, engine ready, SDL is as easy as you make it; possibly easier than Allegro.

Allegro is a general-purpose gamedev lib for simple apps and has primarily hacking interest to me (although there are impressive Allegro projects as well, of course).

Oh no! EVERYBODY'S LEAVING! COME BACK! COME BACK TO UNCLE ALLEGRO!

When I switched to SDL the graphics got way better, I finished all of my games, and millions of people started playing them.

If you like SDL, you should try programming in HTML.

Naw, Matthew doesn't like to use variables..

In that case, he should use create_system_bitmap

Is this why www.sdl.cc redirects to allegro.cc, is there something you haven't told us Matthew

Incredibly it is the case ! I'm dumb! ! ! !

For all those SDL's addict: don't they have a forum for SDL related things ? Didn't you noticed that there is the word 'allegro' in each page of allegro.cc website ?

PS: The last comment is just pure jerk.

There is no such thing as an SDL community. There is only a mailing list for technical problems related to SDL.

So, just for that, SDL sucks.

A project without a community is / not fun / boring / pure shit .

productive