From: Shawn Hargreaves Newsgroups: comp.os.msdos.djgpp Subject: Re: Z-buffering for Allegro (long) Date: Fri, 12 Sep 1997 00:01:39 +0100 Organization: None Distribution: world Message-ID: References: <34145012 DOT D39BD118 AT xs4all DOT nl> <3415892c DOT 870208 AT news DOT eunet DOT be> NNTP-Posting-Host: talula.demon.co.uk MIME-Version: 1.0 Lines: 71 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk Dominique Biesmans writes: >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. Perhaps. But the big distinction is, it would be the authors of the individual modules doing this work, rather than me :-) Presently, other people write code that works with their copy of Allegro, and send it to me. I then have to merge it with my latest version (often a lengthy task since I have sometimes changed things since the version that they were working from), and from that point onwards I am in charge of documenting and maintaining the new code. Technical support questions come to me, further enhancements to it come to me, etc, and if it conflicts with other things at a later date, I have to sort it out. Of course I could just pass these tasks on to whoever originally wrote the code, but in many cases they will have changed address or lost interest and gone on to other projects. In any case, this would involve me in so much coordinating work that it is often easier just to make the changes myself... That makes me sound terribly resentful of all this, which really isn't the case. I don't generally mind this work at all: in fact I really enjoy the chance to work with so many talented programmers, and it is immensely rewarding to watch Allegro grow as people add new features. The trouble is that I am currently having rather too much of a good thing, and I simply can't keep up. A more modular approach might create slightly more work overall, but no one individual will have more than they can deal with. At the moment I am balanced right on the limit of what I can do (witness the appalling delay in my replying to Andrei's email!), so there isn't really any choice: _something_ is going to have to change... >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? Not if it is done properly. I'm not suggestion 100% modularity: there would still be an alleg*.zip which produces the liballeg.a and provides the core graphics routines, I/O functions, etc (basically everything that it does today, and all the stuff that is written by me). And of course I will continue to add whatever improvements people send me as long as they are extensions to this existing body of code rather than a totally new or hugely expanded area if functionality. The important point is that if someone wants to add some major new feature (zbuffered polygons, a fully fledged GUI windowing system, tiled map routines, network support, etc, etc...) it should be done in the form of a seperate package and maintained by someone other than me. Maybe that will lead to some small syncing problems between different versions, but if the programmers are competent nothing too terrible will go wrong. I'm in charge of making sure I don't change the core library in any way that will break other modules that use it, and other people are in charge of making sure their code works both with the core lib and with other addon modules. Put it this way. Say Andrei releases these cool new polygon routines, running in 256 color modes. At the same time I release a new Allegro version that supports truecolor video modes, but of course the zbuffer functions don't work in truecolor modes. Which is better: polygon code that supports a subset of the available modes, and can be extended as and when someone gets around to it, or the truecolor code never being released in the first place because I am too busy trying to make sure that everyone's code fully supports it? -- 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.