|
Pages: [1] 2
|
 |
|
Author
|
Topic: Project Aqua: SDL vs. Allegro (Read 10450 times)
|
muller
Zebranky food
 Offline
Posts: 9
Project Aqua Lead Developer
|
Hello again.
For the past year I have been working with friends (including Halleck) on Project Aqua, an RPG game written in Java. We decided to write our own LGPL'd graphics engine called "SPECTRE" which uses OpenGL (via JOGL) to render everything.
Unfortunately most of our time is spent coding and debugging our graphics abstraction layer. The increased complexity of the game and the graphics requirements have grown so much that we are forced to keep working on our graphics engine and not the game. We are also running into some major limitations with the Java VM.
So I say "Screw it all!" I think we will get better results with C, especially since we can take advantage of all the free C libraries that are avaliable (whose functionality we've had to recreate from scratch with SPECTRE.)
We were looking into game/graphics libraries and found two that we think would encompass what SPECTRE was trying to accomplish, and more. We would like a cross-platform solution that can handle 2D graphics and input with relative ease.
One of our programmers reccomended Allegro, which looks like it will meet our needs. Halleck said that SDL was a better choice, but that there were experts on both libraries here that could help us decide.
Thanks for any information you can provide.
|
|
|
|
« Last Edit: June 27, 2006, 04:54:25 am by muller »
|
Logged
|
|
|
|
Deus Siddis
Enlightened
Offline
Gender: 
Posts: 1387
|
Have you looked at using Clan or pure OpenGL, as well?
|
|
|
|
|
Logged
|
|
|
|
muller
Zebranky food
Offline
Posts: 9
Project Aqua Lead Developer
|
I'm curious to what clan is so if you could elaborate that would be great! JOGL is what we used to make our own graphics engine and it is essentially OpenGL in Java.
|
|
|
|
|
Logged
|
|
|
|
|
|
|
|
|
|
GeomanNL
*Many bubbles*
Offline
Gender:
Posts: 167
I love YaBB 1G - SP1!
|
Allegro works fine, but it has some limitations:
- very limited support for 3d acceleration options (eg no accelerated blending, no accelerated rotation, no accelerated scaling, no accelerated anti-aliasing, but it does support hardware accelerated blitting if sprites are in video memory)
- poor built-in gui
- C based, no use of OO in the library code
For straightforward blitting of sprites, this library is excellent and if that's what you want (now, and in the future), then this is a good candidate.
|
|
|
|
|
Logged
|
|
|
|
Novus
Enlightened
Offline
Gender:
Posts: 1938
Fot or not?
|
Allegro and SDL may appear to be quite similar at first, but they have some quite notable differences:
- SDL is designed to be lightweight, with much of the functionality in separate libraries. Allegro is one big library (although parts can be removed if not needed). Many of the following points follow from this.
- SDL relies heavily on other libraries, e.g. OpenGL, to get a decent set of graphics primitives (SDL itself only essentially copies rectangular chunks of bitmaps from A to B (but with, for example, YUV acceleration), while Allegro has a large amount of (slow, due to limited acceleration) geometric primitives). Neither provides any higher-level 3D operations (e.g. loading complete models, visibility checking, et.c.) but SDL has a distinct edge in available external libraries. Allegro does integrate with OpenGL (AllegGL), but also supports some MS-DOS-era hardware trickery.
- SDL_mixer beats Allegro in music format support (MP3, Vorbis, various module formats), but lacks hardware MIDI support.
- SDL and many additional libraries are standard in many Linux distributions; Allegro is not as widespread (edit: although it has DOS support and SDL doesn't).
- Allegro has its own datafile format with specialised tools; SDL uses external libraries and ZIP files.
- Allegro has support for Autodesk Animator files, SDL connects to several video playback libraries (edit: including FLI/FLC, MPEG and MJPEG).
- Edit: SDL has TrueType font support (e.g. SDL_ttf); Allegro is limited to bitmap fonts.
In conclusion, I'd have to say that Allegro is the "old goodness" and SDL is the "new goodness".
|
|
|
|
« Last Edit: June 27, 2006, 01:18:32 pm by Novus »
|
Logged
|
|
|
|
|
|
Death 999
Global Moderator
Enlightened
Offline
Gender:
Posts: 3873
We did. You did. Yes we can. No.
|
What do you need out of your graphics abstraction layer? And what were the fundamental limitations of Java that you were running up against? Inconveniently-timed gc inhibiting performance?
|
|
|
|
|
Logged
|
|
|
|
|
|
|
|
Culture20
Enlightened
Offline
Posts: 917
Thraddash Flower Child
|
SDL tends to have more precompiled binaries and source packages for major OS distros, and even minor ones like OE linux. On the other hand, I know for a fact that allegro compiles just fine for just about everything, including OE linux...
SDL has been adopted by many game coders as their display method of choice, and have created other libraries to compliment it.
Allegro is designed as a cross platform game library, and has functions to deal with things other than screen bitmaps. Allegro "plugin" libraries like jgmod and AllegroGL are also written to compliment it.
One benefit I think SDL definitely has over Allegro: If I recall correctly, Allegro can't write to a Qt screen (like a Sharp Zaurus' desktop), while I know for a fact that there is an SDL -> Qt library.
In short, go with what you know. In fact, I'd stick with C++ instead of C unless you're looking for pure performance; translating from Java, you'll be wanting your objects.
|
|
|
|
|
Logged
|
|
|
|
muller
Zebranky food
Offline
Posts: 9
Project Aqua Lead Developer
|
Allright, here's the rundown-
Death 999:
Here is how SPECTRE works and then why it failed-
**Sprite is basically an array of Quads binded to a seperate texture. Offset is an integer that can be set which tells which indice in the quad array to draw. If you want to have animation you change the offset and no slow-down from blitting occurs. Sprite also has its own transform matrix, a ZDrawOrder variable, and other handy flags.
**SpritePipe is just an ArrayList of Sprites to be drawn. it also has a transform matrix and and other handy flags. A SpritePipe is like a layer for Sprites.
**RenderLine(GL/SW) can create a window to draw on as easily as SDL. It has a List of SpritePipes. it applys the tranform and flags of the SpritePipe, then draws each Sprite according to ZDrawOrder with it's transform and flags.
The functionality was that you could load you menu in one SpritePipe, game sprites in another SpritePipe. and you could remove a single Sprite, or a whole SpritePipe, by setting a flag(like to add or remove the menue, or have a sprite remove itself when it dies). or rotate the entire screen or everything in a SpritePipe with one transform... Unfortunately our data structures work in a way that it is very difficult to move one sprite to another SpritePipe. Also this structure would have been fine for a java SC2 clone because of the small demand for large images. But our Map's alone can take up to 10 MB in memory, And then the amount of memory for a single character with up to 300 images loaded into memory times however many characters there are on the screen. Our engine crashes from an out of memory error when loading our larger sized maps(20 megs uncompressed b/c of animation). Add to that bugs that appeared depending on what machine you were on and problems with making the same veiwing area despite screen resolution and you get an engine that would be really good if we had a smaller game and had the time to re-code it.
BioSlayer:
Although I'm definately not going to use C#, I feel you on irrlicht as I have dabbled in it in the past. If I were to do anything truly 3D, it would be in irrlicht.
Novus:
Thanks thanks for the camparison on both engines. SDL seems to be the way to go now because of the vorbis support. One thing that I did for SPECTRE was SoundFile.java, which plays OGG, WAV, and MIDI very easily. You just pass in the name of the file and then use the play, pause, stop, and restart methods and even put sounds to be played in a FIFO queue which is something that I think is nifty.
Deus_Siddis:
Thanks for the suggestion of Clan. I tried to look at the documentation and I couldn't follow it very easily so that rules it out in my mind.
Zeep-Eeep & Culture20:
Thanks for the heads-up on the OSes and dependancies.
~~~~~~~~~~~~~~~~~~
Ok, so heres where I'm at now I've thought about it and it seems that I might just turn project aqua into a 3D game entirely and use Irrlicht for the graphics, and SDL for input and sound. The game world will still be an isometric 2D feel though hopefully to simplify camera and movement. I am not looking to re-write SPECTRE in C/C++, that would only take up more time unless anyone had any suggestions on a better/more flexible engine organization.
Thank you all for you time and please let me know how you would go about this, or have other suggestions.
|
|
|
|
|
Logged
|
|
|
|
GeomanNL
*Many bubbles*
Offline
Gender:
Posts: 167
I love YaBB 1G - SP1!
|
Our engine crashes from an out of memory error when loading our larger sized maps You wrote the game, assuming you could load huge amounts of graphics !
That would be a problem if you'd use another graphics library, too.
Instead, try loading images from disk while the game runs, and discard them when they're not used anymore. I think that will solve most of your problems.
E.g., add a time-tag to your sprites which you update whenever the sprite is used. Every now and then, check all your sprites and unload the color data of the ones that haven't been used for some time.
Also, with each sprite, store the file name so that the color data of the sprite can be reloaded when it's needed again. The file name takes little space, and shouldn't be much of a problem to store in memory.
In that way you get a load-by-demand which is more efficient in terms of memory.
problems with making the same veiwing area despite screen resolution
I don't think using a 3D lib will solve this for you.
You could scale your images when you load (or display) them, and locate them on scaled coordinates on your screen.
|
|
|
|
|
Logged
|
|
|
|
|
Pages: [1] 2
|
|
|
|
|
