|
This thread is locked; no one can reply to it. |
1
2
|
Allegro vs SDL (revisited) |
Onewing
Member #6,152
August 2005
|
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... ------------ |
LennyLen
Member #5,313
December 2004
|
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
|
You should've seen it before I did a spell check. I originally typed insite, which isn't even a word..... ------------ |
Archon
Member #4,195
January 2004
|
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
|
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. 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. 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
|
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
|
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. Of course, needing AllegroGL CVS to work with Allegro 4.2 is a bit annoying. |
Simon Parzer
Member #3,330
March 2003
|
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
|
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). [My site] [Tetrominoes] |
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
|
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
|
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 __________ |
Thomas Harte
Member #33
April 2000
|
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.
[My site] [Tetrominoes] |
Onewing
Member #6,152
August 2005
|
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. ------------ |
Matthew Leverton
Supreme Loser
January 1999
|
Running TH's code on my Windows computer:
[/list] |
Thomas Harte
Member #33
April 2000
|
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! [My site] [Tetrominoes] |
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. Id be interested to see what happens if you use CoreImage to manipulate memory bitmaps. My gut feeling is that it wont be faster, as it will be general-purpose, robust code, whereas Allegros code is optimised for a specific purpose. If it is faster, I would take that to mean that theres something wrong with Allegro. Pete
|
Evert
Member #794
November 2000
|
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
|
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. [My site] [Tetrominoes] |
Tero Laxström
Member #2,589
July 2002
|
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: Allegro> -Os: Allegro> -O3: SDL> no parameters: SDL> -Os: SDL> -O3: -- |
Simon Parzer
Member #3,330
March 2003
|
"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
|
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" 30 counted seconds, 10002756 counted blits => 333425.20 blits/second Allegro GCC 3.4.5, --enable-asm=no: GCC 4.1.0, no extra flags: GCC 4.1.0, --enable-asm=no: 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 __________ |
|
1
2
|