|
This thread is locked; no one can reply to it. |
1
2
|
Benchmark: Allegro and SDL |
Slartibartfast
Member #8,789
June 2007
|
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.
And for SDL:
The results were quite surprising, considering the results reported in that thread; ---- |
Tobias Dammers
Member #2,604
August 2002
|
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. --- |
Slartibartfast
Member #8,789
June 2007
|
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). 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. ---- |
GullRaDriel
Member #3,861
September 2003
|
Learning OpenGL ? With AllegoGL ? Not really a need. Check dumbtest:
All you need is allegro_gl_set/unset_allegro_mode(); "Code is like shit - it only smells if it is not yours" |
Tobias Dammers
Member #2,604
August 2002
|
Quote: Switching to AllegroGL however would require learning OpenGL, which is more complicated, and is a bit much for 2d games. 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. --- |
Simon Parzer
Member #3,330
March 2003
|
To the OP:
Seriously: the two libraries have different purposes. Allegro is a game library with loads of useful functions (especially for retro-games). |
HoHo
Member #4,534
April 2004
|
Why not benchmark OpenLayer together with Allegro and SDL __________ |
Samuel Henderson
Member #3,757
August 2003
|
Quote: 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. ================================================= |
Thomas Harte
Member #33
April 2000
|
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! Quote: Allegro is not made for cutting-edge performance, but rather for solid multiplatform programming with a relatively easy-to-use interface with decent performance 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. [My site] [Tetrominoes] |
Peter Hull
Member #1,136
March 2001
|
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
|
Jakub Wasilewski
Member #3,653
June 2003
|
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. --------------------------- |
Neil Black
Member #7,867
October 2006
|
Quote: break the universe I see an openning for a Douglas Adams quote! Douglas Adams said: There is a theory which states that if ever anybody discovers exactly what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable. There is another theory which states that this has already happened.
|
Samuel Henderson
Member #3,757
August 2003
|
Quote: I see an openning for a Douglas Adams quote! Douglas Adams said: There is a theory which states that if ever anybody discovers exactly what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable. There is another theory which states that this has already happened.
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 ================================================= |
Thomas Harte
Member #33
April 2000
|
Quote: 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. 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! Quote: 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. 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! [My site] [Tetrominoes] |
vbovio
Member #8,283
January 2007
|
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 ? --------------- |
Thomas Harte
Member #33
April 2000
|
Quote: what compilers it supports Much the same as Allegro, with some more diverse 'unsupported' targets (Dreamcast, Symbian, etc) Quote: does it use OpenGL natively or it has an add-on 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. Quote: for what Jakub said, are those add-ons (PNG, OGG, TTF) easier/better than allegro's ? 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. Quote: does it have a GUI API No. Quote: does it have a datafile/resource API No. Quote: for Mac OS, is it easier/better supported than allegro 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. Quote: and same question for networking There's no networking built into SDL, much as there isn't any networking built into Allegro. [My site] [Tetrominoes] |
Jakub Wasilewski
Member #3,653
June 2003
|
Quote: [...] 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. 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. Quote: I think Peter has a good point re:9000 sprites at 50 fps. 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. Quote:
- does it have a GUI API ? 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. Quote: for what Jakub said, are those add-ons (PNG, OGG, TTF) easier/better than allegro's 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. Quote: what compilers it supports 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). --------------------------- |
Shadow Master
Member #8,176
January 2007
|
This enlightened my mind. Thank you and bye. |
vbovio
Member #8,283
January 2007
|
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. --------------- |
Slartibartfast
Member #8,789
June 2007
|
Re: my example is flawed responses. Re: 9000 sprites at 50 fps Re: Not use 100% CPU ---- |
Simon Parzer
Member #3,330
March 2003
|
IMO SDL is nice, but when you use it, consider doing the gfx with OpenGL. |
MiquelFire
Member #3,110
January 2003
|
Okay, I'm wondering what else needs to be done to prevent a 100% CPU usage outside of using rest(1). --- |
Shadow Master
Member #8,176
January 2007
|
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. |
Jakub Wasilewski
Member #3,653
June 2003
|
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. --------------------------- |
vbovio
Member #8,283
January 2007
|
Quote: Okay, I'm wondering what else needs to be done to prevent a 100% CPU usage outside of using rest(1). me too. --------------- |
|
1
2
|