cvs.gedasymbols.org/archives/browse.cgi   search  
Mail Archives: djgpp/1997/10/22/21:16:20

From: Shawn Hargreaves <Shawn AT talula DOT demon DOT co DOT uk>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Allegro 3
Date: Mon, 20 Oct 1997 20:08:43 +0100
Organization: None
Distribution: world
Message-ID: <gfR7zDA7w6S0Ewdo@talula.demon.co.uk>
References: <62e9jj$6qc$1 AT news DOT interlog DOT com>
NNTP-Posting-Host: talula.demon.co.uk
MIME-Version: 1.0
Lines: 58
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

Gautam N. Lad writes:
>First, of all, what will be the (approx.) final size of the Allegro 3 
>package (Zipped up and the extracted data)? 

The current WIP .zip file is 1.2 megs. My Allegro dir (including all the
object files and compiled test programs) is around 20 megs, but there is
a fair amount of crap in there at the moment that isn't actually part of
the lib.

>And the hopeful release date?

I've no idea: hopefully very soon, but I've been saying that for nearly
a year now :-) Whenever it is finished!

The WIP version currently on my website is very close to being a 3.0
beta, so you can use that if you don't like to wait.

>Also, are there any plans to make 'Lite' or separate libraries of 
>Allegro. What I mean is certain Library will have certain functions 
>(eg. One that's 3D will have the 2D+3D drawing capabilities). 

I don't think so. I'm gradually trying to make things more modular, and
to split off optional functionality from the main lib: if you look on my
website you will see there are growing numbers of add-on packages that
provide things like better GUI routines and JPEG loading. But IMHO it
would be a mistake to go too far down that route. Having a core lib
(maintained by me) plus various optional packages (maintained by other
people) is relatively simple and robust, but splitting off parts of the
core routines would cause a lot of problems with interdependencies
between various parts of the code, and probably a lot of duplication of
the same routines in different places. I don't have the time or energy
to maintain something like that...

>I know this is a bad idea, but what about a library that can be 
>compiled (easily by anyone) to only include certain features, thus, if 
>any, improve speed.

The speed wouldn't be affected by how much code is present in the lib.
The only real reason for doing such a thing would be to reduce the size
of the liballeg.a file, and how long it takes to compile. But I don't
think that is such a big problem: a complete build takes about 10 mins
on my p133, so it is hardly a "leave running overnight" task :-)

The other issue is executable size, but that also wouldn't be affected
by splitting up the lib. Just because things like the FLIC player and
sound code are included in your liballeg.a, does not mean they will be
linked into your program if you only call the graphics functions. Some
unused code is included, but that is inevitable because of the way
Allegro uses tables of function pointers for most of the graphics code.
The latest code also has some macros which you can use to conditionally
include the various graphics and sound drivers, so you can for example
leave out all the mode-X and SVGA drivers if you only use the 320x200
mode...


--
Shawn Hargreaves - shawn AT talula DOT demon DOT co DOT uk - http://www.talula.demon.co.uk/
Beauty is a French phonetic corruption of a short cloth neck ornament.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019