The Ur-Quan Masters Discussion Forum

The Ur-Quan Masters Re-Release => Starbase Café => Topic started by: muller on June 27, 2006, 04:51:42 am



Title: Project Aqua: SDL vs. Allegro
Post by: muller 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 (http://www.aethr.net/pa/), an RPG game written in Java. We decided to write our own LGPL'd graphics engine called "SPECTRE (http://spectre.sf.net)" 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.


Title: Re: Project Aqua: SDL vs. Allegro
Post by: Deus Siddis on June 27, 2006, 05:39:00 am
Have you looked at using Clan or pure OpenGL, as well?


Title: Re: Project Aqua: SDL vs. Allegro
Post by: muller 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.


Title: Re: Project Aqua: SDL vs. Allegro
Post by: JonoPorter 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 (http://www.mono-project.com/Main_Page). There are automated tools for converting java code to C# code (http://msdn.microsoft.com/vstudio/downloads/tools/jlca/) 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# (http://sourceforge.net/projects/cs-sdl/) as well. There also appears to be a version of allegro for C#. (http://www.skorzec.com/allegnet/)


Title: Re: Project Aqua: SDL vs. Allegro
Post by: Halleck 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 (http://www.mono-project.com/Main_Page).
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.


Title: Re: Project Aqua: SDL vs. Allegro
Post by: JonoPorter 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/ (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://scsharp.org/)
http://alpha.devnet.ro/ (http://alpha.devnet.ro/)


Title: Re: Project Aqua: SDL vs. Allegro
Post by: GeomanNL 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.


Title: Re: Project Aqua: SDL vs. Allegro
Post by: Novus 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".


Title: Re: Project Aqua: SDL vs. Allegro
Post by: Deus Siddis 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?


Title: Re: Project Aqua: SDL vs. Allegro
Post by: Death 999 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?


Title: Re: Project Aqua: SDL vs. Allegro
Post by: Novus 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.


Title: Re: Project Aqua: SDL vs. Allegro
Post by: Zeep-Eeep 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.


Title: Re: Project Aqua: SDL vs. Allegro
Post by: Culture20 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.


Title: Re: Project Aqua: SDL vs. Allegro
Post by: muller 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.


Title: Re: Project Aqua: SDL vs. Allegro
Post by: GeomanNL 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.


Title: Re: Project Aqua: SDL vs. Allegro
Post by: muller on June 28, 2006, 09:19:06 am
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.

Thats exactly it. When the engine was concieved the game was origonally a tile based engine. We've had tests of up to a thousand independantly rotated and scaled moderately sized images running at 40 fps. But they were referencing the same image.

Our character animation is the worst part. we have at least 300 images per character for 8 directions that can be displayed at any instant so they must be in video memory. Multiply that by 7 or 8 characters and we are screwed.


Title: Re: Project Aqua: SDL vs. Allegro
Post by: GeomanNL on June 28, 2006, 10:57:38 am
How often are all characters displayed at once on your screen, in all 8 directions ?
How often do you actually cycle through all 300 animated frames ?
If you display only a fraction of this each frame, then loading from disk might actually work.

Or are you rendering huge fights with dozens of units displayed on screen ? In this case, you might consider reducing animation detail because the more units are displayed, the less someone will notice the details associated with each unit.

You could even decide to reduce the animation detail only if there are many units displayed, and increase it again if there are fewer units. I doubt anyone will be bothered by such a thing. This would mean, discarding data while the game is running, and reading it back again when needed. Disks are pretty fast, it won't reduce performance much.

Otherwise, you'll have to go 3d and discard a lot of your work. Animation in 3d is less memory intensive. However, 3d is much less efficient in terms of computing power, so you'll not be able to render many detailed units.


Title: Re: Project Aqua: SDL vs. Allegro
Post by: Halleck on June 28, 2006, 12:57:06 pm
Otherwise, you'll have to go 3d and discard a lot of your work. Animation in 3d is less memory intensive. However, 3d is much less efficient in terms of computing power, so you'll not be able to render many detailed units.
We actually haven't generated sprites yet, and (like timewarp) our sprites would just be renders of 3D models. So we won't be losing much dataset work by taking the models we have and optimizing them for use in-game instead of rendering them as a sprite.

We may wind up using a combination of prerendered backgrounds and realtime characters, like in Final Fantasy 7.


Title: Re: Project Aqua: SDL vs. Allegro
Post by: Deus Siddis on June 28, 2006, 03:50:42 pm
Quote
3d is much less efficient in terms of computing power, so you'll not be able to render many detailed units.

With 3D realtime, they must be less detailed as far as geometry, but can be more detailed and smoother as far as animation, for the same system power.  It is a matter vs energy sort of thing. And then you also have the camera rotation and zoom abilities in 3D, that would be very limited in a 2d isometric game.


Quote
So we won't be losing much dataset work by taking the models we have and optimizing them for use in-game instead of rendering them as a sprite.

What is the average poly count for the character models (currently?)


Title: Re: Project Aqua: SDL vs. Allegro
Post by: Halleck on June 28, 2006, 04:13:09 pm
What is the average poly count for the character models (currently?)
Very high. They are currently intented to be used in production renders, not in-game. Lots of subsurfing etc.
Here's an example, the main character mesh which i screencapped in blender (click to enlarge):
(http://img501.imageshack.us/img501/7559/tijonpolies1ed.th.jpg) (http://img501.imageshack.us/my.php?image=tijonpolies1ed.jpg)
and an accompanying render (http://aquarchive.woodbetweenworlds.com/3d_Art/Characters/Tijon/tijon_checkpoint_three1.jpg).
Clearly this is extreme overkill for an in-game model that's probably not going to be larger than two inches on the display. This is great for cutscenes or sprites, but lousy if you want to render it in realtime at more than 15 fps...


Title: Re: Project Aqua: SDL vs. Allegro
Post by: Deus Siddis on June 28, 2006, 08:34:00 pm
Wow, that is a dense mesh.

Was it made entirely in Blender 3D? If so, I wonder if some of your renderings could be submitted as possible blender gallery art. They could maybe have "Project Aqua" in their sigs, as a promotion (if they were accepted.)


Title: Re: Project Aqua: SDL vs. Allegro
Post by: Halleck on June 28, 2006, 11:50:59 pm
Hm, maybe. Our lead character modeller, Lee, (the guy who modelled that) was also a lead artist on blender's project orange (http://orange.blender.org/), so he could probably get a plug for us.  ;D


Title: Re: Project Aqua: SDL vs. Allegro
Post by: Deus Siddis on June 29, 2006, 03:45:18 pm
Oh. . .well nevermind then. :)


Title: Re: Project Aqua: SDL vs. Allegro
Post by: Death 999 on June 30, 2006, 07:24:38 pm
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.

How many Quads are there? I don't know what a Quad is, but it sounds like there are a lot of them. Or are there just a few, and there are a lot of references to each one? If you have millions of identical references, and fewer than 256 distinct Quads, then you could make an array of them and reference them with a byte index rather than  full object reference. That'd shrink their memory footprint by a factor of 4.

Quote
But our Map's alone can take up to 10 MB in memory,

which map? You didn't mention a map. Bitmap?


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

300 images loaded into memory per character...  How many distinct animation actions are they going to be executing? Can you cut out some of the middle animation frames?

Quote
Our engine crashes from an out of memory error when loading our larger sized maps(20 megs uncompressed b/c of animation).

If it depends on map size, your design isn't scaling right. Are you loading the whole map background at once? It seems unlikely that people would be teleporting around a lot, so you can load it in segments, any four of which are small enough to be handled easily.


Title: Re: Project Aqua: SDL vs. Allegro
Post by: Halleck on July 06, 2006, 02:16:11 pm
A little update for those interested...
we are currently prototyping a true 3d engine using irrlicht (http://irrlicht.sourceforge.net/).

Here's a quick hack of a walkaround map with collision detection and a fixed camera angle:
(http://img19.imageshack.us/img19/4814/walkaround9cr.th.png) (http://img19.imageshack.us/my.php?image=walkaround9cr.png)
Most of the game will probably be like this. (Not art-wise, the map and the character are just some stuff from quake.)

Here's the "world map" we've been prototyping, which will allow you to travel between 'floating' continents in an airship:
(http://img239.imageshack.us/img239/892/ludditescreenie29uc.th.png) (http://img239.imageshack.us/my.php?image=ludditescreenie29uc.png) (http://img117.imageshack.us/img117/4057/newsky20qz.th.jpg) (http://img117.imageshack.us/my.php?image=newsky20qz.jpg) (http://img223.imageshack.us/img223/9746/mullercar13ed.th.png) (http://img223.imageshack.us/my.php?image=mullercar13ed.png)
(Muller and I made the crappy looking models, the cool jet is from vegastrike.)

The plan is to finish these prototypes as proof-of-concepts in order to get a better idea of how to pull this off. If we find that we can do everything we need to do with irrlicht, all 2d plans will be scrapped for good.


Title: Project Aqua: Irrlicht vs. OGRE
Post by: Deus Siddis on July 06, 2006, 05:28:05 pm
Cool pics. So now I guess it is Irrlicht vs. OGRE.


Title: Re: Project Aqua: SDL vs. Allegro
Post by: Halleck on July 06, 2006, 07:12:25 pm
Cool pics. So now I guess it is Irrlicht vs. OGRE.
Heh, perhaps. Muller finds irrlicht easier to implement than OGRE, although from what I've seen of the two engines, OGRE's a bit more high-end.

Good news, our prototype now compiles flawlessly on OSX:
(http://img414.imageshack.us/img414/8674/mullercarosx9pf.th.jpg) (http://img414.imageshack.us/my.php?image=mullercarosx9pf.jpg)
Hopefully, the only differences you'll see are the title bar and the jpeg compression!


Title: Re: Project Aqua: SDL vs. Allegro
Post by: GeomanNL on July 07, 2006, 01:21:56 am
Point of caution: a while back I read that irrlicht didn't support certain 3D effects. Perhaps you should check what it's capabilities are. I read it here :
http://www.mpi-inf.mpg.de/~mheinz/microracer-html/index.html (http://www.mpi-inf.mpg.de/~mheinz/microracer-html/index.html)


Title: Re: Project Aqua: SDL vs. Allegro
Post by: Halleck on July 07, 2006, 02:06:03 am
Thanks for the heads up... we'll explore this as we get deeper into the prototyping phase.
Irrlicht has improved since last year's 0.11 release, it's currently at 1.0. Still, some of the major limitations mentioned might still be present.

Also... we don't necessarily need all of the bleeding edge effects, we just need it to look pretty and have reasonable system requirements.