The Ur-Quan Masters Home Page Welcome, Guest. Please login or register.
Did you miss your activation email?
August 15, 2022, 03:37:05 pm
Home Help Search Login Register
News: Paul & Fred have reached a settlement with Stardock!

+  The Ur-Quan Masters Discussion Forum
|-+  The Ur-Quan Masters Re-Release
| |-+  Starbase Café (Moderator: Death 999)
| | |-+  Project Aqua: SDL vs. Allegro
« previous next »
Pages: [1] 2 Print
Author Topic: Project Aqua: SDL vs. Allegro  (Read 10065 times)
muller
Zebranky food
*
Offline Offline

Posts: 9


Project Aqua Lead Developer


View Profile
Project Aqua: SDL vs. Allegro
« on: June 27, 2006, 04:51:42 am »

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 Offline

Gender: Male
Posts: 1387



View Profile
Re: Project Aqua: SDL vs. Allegro
« Reply #1 on: June 27, 2006, 05:39:00 am »

Have you looked at using Clan or pure OpenGL, as well?
Logged
muller
Zebranky food
*
Offline Offline

Posts: 9


Project Aqua Lead Developer


View Profile
Re: Project Aqua: SDL vs. Allegro
« Reply #2 on: June 27, 2006, 06:43:09 am »

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
JonoPorter
Enlightened
*****
Offline Offline

Gender: Male
Posts: 656


Don't mess with the US.


View Profile WWW
Re: Project Aqua: SDL vs. Allegro
« Reply #3 on: June 27, 2006, 08:04:16 am »

Instead of rewriting it into C you could try converting it into C# and develop it on the mono platform. There are automated tools for converting java code to C# code and C# is very similar to java so you won’t have that much of a learning curve.

There are also many implementations of OpenGL for C#, and you can use SDL in C# as well. There also appears to be a version of allegro for C#.
Logged

There are none so blind as those who will not see. — Jonathan Swift

My Remake of UQM.
My 2D physics engine
Both are written in C#.
Halleck
Enlightened
*****
Offline Offline

Gender: Male
Posts: 750


Personal Text


View Profile WWW
Re: Project Aqua: SDL vs. Allegro
« Reply #4 on: June 27, 2006, 08:33:28 am »

Instead of rewriting it into C you could try converting it into C# and develop it on the mono platform.
Meh... maybe if crossplatform support was better, and if it wasn't controlled by the big M$.

Also, I recall you saying that the support for OpenGL in C# was "depressing", although things may have changed since them.
« Last Edit: June 27, 2006, 09:14:35 am by Halleck » Logged


Currently working on: Going outside more

Game projects: Vega Strike / Elite Strike
JonoPorter
Enlightened
*****
Offline Offline

Gender: Male
Posts: 656


Don't mess with the US.


View Profile WWW
Re: Project Aqua: SDL vs. Allegro
« Reply #5 on: June 27, 2006, 09:45:25 am »

Meh... maybe if crossplatform support was better, and if it wasn't controlled by the big M$.

Also, I recall you saying that the support for OpenGL in C# was "depressing", although things may have changed since them.
What i said was:
Quote from: BioSlayer
The lack of OpenGl stuff for C# is also depressing.
What I meant by that is that the lack of anything higher level then OpenGL is depressing.
What I wanted is something where I can load a mesh, give it a texture, and give it position and orientation and its there. No graphics API is that simple (that I know of).

There have been some changes in that department though. You should check out:
http://irrlicht.sourceforge.net/
Also Axiom is starting to move as well.

I haven’t worked on my own game much or investigated further into more 3D graphics engines since I’m busy working on other business stuff.

you can also look at these 2 cool things:
http://scsharp.org/
http://alpha.devnet.ro/
Logged

There are none so blind as those who will not see. — Jonathan Swift

My Remake of UQM.
My 2D physics engine
Both are written in C#.
GeomanNL
*Many bubbles*
***
Offline Offline

Gender: Male
Posts: 167


I love YaBB 1G - SP1!


View Profile
Re: Project Aqua: SDL vs. Allegro
« Reply #6 on: June 27, 2006, 11:42:59 am »

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 Offline

Gender: Male
Posts: 1938


Fot or not?


View Profile
Re: Project Aqua: SDL vs. Allegro
« Reply #7 on: June 27, 2006, 12:54:47 pm »

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

RTFM = Read the fine manual.
RTTFAQ = Read the Ur-Quan Masters Technical FAQ.
Deus Siddis
Enlightened
*****
Offline Offline

Gender: Male
Posts: 1387



View Profile
Re: Project Aqua: SDL vs. Allegro
« Reply #8 on: June 27, 2006, 03:44:55 pm »

Quote
I'm curious to what clan is so if you could elaborate that would be great!

Wiki has an article on it (I found it from a link on their allegro page):

http://en.wikipedia.org/wiki/ClanLib

And their site has a good list of games made with it:

http://www.clanlib.org/games.html


About the Allegro Vs. SDL, is it true that allegro is easier to use, or does SDL get you just as far with the same effort/expertise?
Logged
Death 999
Global Moderator
Enlightened
*****
Offline Offline

Gender: Male
Posts: 3866


We did. You did. Yes we can. No.


View Profile
Re: Project Aqua: SDL vs. Allegro
« Reply #9 on: June 27, 2006, 04:27:46 pm »

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
Novus
Enlightened
*****
Offline Offline

Gender: Male
Posts: 1938


Fot or not?


View Profile
Re: Project Aqua: SDL vs. Allegro
« Reply #10 on: June 27, 2006, 05:34:32 pm »

About the Allegro Vs. SDL, is it true that allegro is easier to use, or does SDL get you just as far with the same effort/expertise?
Roughly the same in my experience, SDL just does more things useful to modern games while Allegro was well adapted to the scene in 1995 and lacks some new things that SDL does.
Logged

RTFM = Read the fine manual.
RTTFAQ = Read the Ur-Quan Masters Technical FAQ.
Zeep-Eeep
Enlightened
*****
Offline Offline

Gender: Male
Posts: 917


Good Grief


View Profile WWW
Re: Project Aqua: SDL vs. Allegro
« Reply #11 on: June 27, 2006, 07:47:55 pm »

I have not done much graphics programming (at least no cross-platform)
but I found the Allegro library easy to use and to learn. They have some excellent
docs and the functions calls are pretty simple. SDL also comes
in multiple parts, which can be a headache when chasing down dependancies
on a Linux box. Allergo, as someone already mentioned, comes in
one, big library.
Logged

What sound does a penguin make?
Culture20
Enlightened
*****
Offline Offline

Posts: 917


Thraddash Flower Child


View Profile
Re: Project Aqua: SDL vs. Allegro
« Reply #12 on: June 28, 2006, 02:40:15 am »

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 Offline

Posts: 9


Project Aqua Lead Developer


View Profile
Re: Project Aqua: SDL vs. Allegro
« Reply #13 on: June 28, 2006, 04:12:08 am »

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 Offline

Gender: Male
Posts: 167


I love YaBB 1G - SP1!


View Profile
Re: Project Aqua: SDL vs. Allegro
« Reply #14 on: June 28, 2006, 08:59:02 am »

Quote
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.

Quote
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 Print 
« previous next »
Jump to:  


Login with username, password and session length

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!