Message-ID: <000601bda2bf$121ebee0$f34e08c3@arthur>
From: "Arthur" <arfa AT clara DOT net>
To: "DJGPP Mailing List" <djgpp AT delorie DOT com>
Subject: Re: Is Allegro up to speed?
Date: Sun, 28 Jun 1998 18:53:50 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Precedence: bulk

>Much of Allegro's low level functions are inline assembly, but are they
>the fastest available?  For example, the do_line() function is extremely
>fast, assuming that the pixel-plotter is fast.  But is the
>polygon-drawer or any of the other stuff fast enough for commercial use?


Depends on what screen mode you're in and how complex you want to make the
graphics.

You can actually draw a line faster than do_line() but you'll only get a
very small speed benefit. It just relies on a bit of optimising of the code.

As for the polygon routines: I have found them pretty good, comparatively
speaking, to other polygon routines written in C when using complex graphics
(that is, alpha blending, gouraud shading and texture mapping). When just
drawing simple filled polygons, however, I've found them pretty poor.
Especially in mode 13h and mode-x.

This is not a "poor programming" problem - in fact, it's pretty well coded.
It's just that the routine checks for certain variables and parameters to
maintain compatability, then calls separate fill routines depending on the
parameters found. That's a lot of "if..." statements. The upshot is that it
ends up slower than it might if it was specifically written for your program
rather than *every* program. It's also written in C, while do_line() is in
ASM.

I'm pretty sure this applies to other (graphic) functions as well.

There arn't many commercial games which use Allegro to draw graphics,
although there are a few which use it to do other stuff like keyboard
handling etc. There have been several posts on this topic in the past so
check the mailing archives.


James Arthur
jaa AT arfa DOT clara DOT net