From: Shawn Hargreaves Newsgroups: comp.os.msdos.djgpp Subject: Re: Allegro 3 Date: Mon, 20 Oct 1997 20:08:43 +0100 Organization: None Distribution: world Message-ID: 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 Precedence: bulk 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.