Message-Id: <199709100837.SAA23409@rabble.uow.edu.au>
Subject: Re: Z-buffering for Allegro (long)
To: Dominique DOT Biesmans AT ping DOT be
Date: Wed, 10 Sep 1997 18:37:16 +1000 (EST)
Cc: djgpp AT delorie DOT com (DJGPP)
In-Reply-To: <3415892c.870208@news.eunet.be> from Dominique Biesmans at "Sep 9, 97 05:53:36 pm"
From: *** Brett *** <bporter AT rabble DOT uow DOT edu DOT au>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

> 
> >Partly, I'm worried that Allegro is just getting too big, and that many
> >people only need a small subset of what it provides. Modularity, and
> >optional downloading of components, can only be a good thing...
> 
> OTOH. I think the fact that Allegro is one 'big' (big? a little over
> 1Mb? Look at the DirectX SDK, a -not even complete- distribution is
I think he means big in the concept of what it does, not source code size.
The game quake has source of under 2Mb, and you can hardly say that it is
not big. In relation to DirectX SDK, it includes a lot of binaries, not just
the source code like Allegro. And anything that touches windows puts on a
few meg of weight :)

> about 30Mb) library with a simple, but more importantly -consequent-
> interface, is one of it's strongest points. 
> 
Do you mean consistent? Anyway, it wouldn't be inconsistent, as each module
could be designed in the same fashion. You would most likely have a base
module that had the most important stuff that everything needs, and then
seperate modules for sound, 3D, and so on.

> If you want that advantage with a modular version, you'd still need
> someone to do the 'administrative' work of making sure that everything
> still works together. The total work load would even increase, since
> you'd have several packages to be maintained, instead of one.
> 
This is how DJGPP is maintained: mostly in a modular fashion, and it seems
to be put together alright :)

> And in the end, you'de have several Allegro versions. One modified
> version that works together with this package, and another one that
> doesn't, but supports true color modes, execept for the 3D part,
> therefore you'd need ... etc ... catch my drift?
> 
It isn't that hard to solve these small problems. Calling truecolour
routines for example, could always be allowed in the 3D part, just that if
you didn't download the truecolour module, you wont have te functions
present so you get link errors.

I think modularity would be a good idea, because I can see a couple of
things in Allegro already that I will never use, and as the package grows it
may be a case of downloading a large file that you only use 50% of.

A quick note to the original poster: I almost didn't notice the nospam part
in your email address. I always just use reply to mail and news, and if you
have a nospam address, I just get it sent back again. Have you found that
you have really avoid much spam by using that type of address?

Just my thoughts
Brett

-- 
Brett Porter
bporter AT rabble DOT uow DOT edu DOT au

http://www.geocities.com/CollegePark/Union/3596
	Humour, Programming, and more.