From: Shawn Hargreaves Newsgroups: comp.os.msdos.djgpp Subject: Z-buffering for Allegro (long) Date: Mon, 8 Sep 1997 22:41:59 +0100 Organization: None Distribution: world Message-ID: References: <34145012 DOT D39BD118 AT xs4all DOT nl> NNTP-Posting-Host: talula.demon.co.uk MIME-Version: 1.0 Lines: 145 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk Andrei 'old boy' Ellman writes: >For some time, I've been hacking Allegro's polygon drawing routines and have >added Z-buffering to them, and I was hoping that Shawn would add them to the >next version of Allegro. When I first got Z-buffering to work Shawn seemed >enthisiastic, but unfortunately, I have not had any e-mail from him in ages, >and when I checked the Allegro WIP things todo list, I noticed the absence of >Z-buffering. Hi, Andrei! I'm very, very sorry about the lack of any recent replies from me. I feel terrible about it, and I suspect that if anyone did that to me I would never speak to them again, so I hope you can be a bit more forgiving:-) I don't have a particularly good excuse, either. For a couple of months I was simply snowed under at work, but things have mostly returned to normal now. The trouble is that my job just doesn't leave me as much time as I need for the rest of my life. I can answer email, and work on Allegro, and have a social life, and maybe even sleep every now and then, but unfortunately not all at the same time :-) I try to average things out between these different areas, but when it comes to the answering of email I have a bad habit of responding to the easy, don't-have-to-think messages, and leaving the more complex issues until later. Then I start to feel bad about leaving them so long, and the need to apologise makes them even more difficult to answer, so I leave them even longer, etc, etc. Please accept my apologies: I never meant to ignore your letter for more than a few days! You might not believe this, but I was actually just sitting down to reply to your last message when this post arrived. I'll respond here, and then send you some more detailed comments by private email... >I would appreciate any comments anyone has of my demos. Should I release my >sourcecode as freeware, or just wait and hope that some of it gets included in >the next release of Allegro? This is a difficult issue. A year ago, I would unhesitatingly have said send me the code, and I will add it to Allegro. But recently I've been finding more and more problems with that approach... 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... But more seriously, this issue ties in with my lack of time for Allegro work. The more contributions I get from other programmers, the more time I have to spend merging sources, coordinating things with various different authors, and maintaining other people's code. On one level I love that: I enjoy working with other coders, and I'm delighted and very flattered by the number of people who are interested in improving and extending my code. At the moment, though, this sort of administrative work is not far off becoming a full time job (which sounds crazy, and I don't really understand why it takes so long, but little things add up very quickly...). When I start running out of time for coding new things of my own, I begin to think that there is a problem... What the solution is, I don't know. Maybe someone else could take over the organisational side of things, but I'm not sure how well that would work, and I have to admit I feel a bit too proprietorial to like the idea of delegating that responsibility (yeah, I admit it: I'm a terrible control freak :-) The other obvious approach is for each different author to release their work as seperate add-on packages, designed to be used together with the core library routines. That obviously wouldn't work for some things that are direct extensions or modifications of existing routines (eg. at the moment George Foot is working on an AWE32 driver, and Michal Mertl recently finished implementing 24 bit graphics modes), but where the addition is more of a sidestep or a totally new area of functionality, I think it could be quite successful. In fact some people are already doing things along these lines, eg. Doug Eleveld with his C++ GUI code, Dim Zegebart with the DZComm serial port routines, etc. Some of my thoughts about the idea: Pros: - Cuts out all the work at my end. - Makes things more modular, giving the user more choice about what types of functionality they want to install. - Maintenence is _much_ simpler. It is obvious who to contact about each different package, and new versions can be released whenever they are ready, without having to coordinate with lots of other programmers. - Potentially greater flexibility. as it would discourage people from relying too much on the inner details of different modules. - Gives you total control of your own code, release dates, etc. No need to worry about me not replying to your emails :-) Cons: - Some people maybe like the "all-in-one" approach (but just look at Emacs or djgpp: they do everything you could ever want but are implemented in many different pieces...) - Potential problems with bugs introduced by versions being out of sync. I don't think this would be too bad, though: I certainly take great care not to do anything in my code that might break other routines which use it (a little boast: after adding truecolor modes, when I wanted to change the grabber to support truecolor data, I only had to add a single line to make it use a 32 bit vide mode, and everything worked perfectly...) - Authors might prefer their code to be added to the core library, and feel that being a seperate package meant it was somehow less official or that I was rejecting it. In a way I guess that is true (it would be released as your package, not mine...) but I think that feeling would quickly pass, if we can make the transition from Allegro being a single monolithic library to a set of core routines plus various extension modules. One thing that would help with this is if there was a standard way of distributing these Allegro packages, so that they all clearly belonged together, such as an allegro/ directory on the SimTel sites. DJ? Is that a possibility, and if so how would it be organised? And does Allegro really even belong under the djgpp hierarchy, or would some other location be more appropriate? I don't really care where it goes as long as people can find it, but some people take these things very seriously, and I don't want to upset anybody :-) Ok folks. What essential points have I forgotten? Does this make sense to you, or am I talking nonsense? Andrei: it's really all down to you. Do you feel like pioneering this kind of semiofficial add-on approach, or are you horribly offended by the whole idea of not having your stuff put directly into my distribution? I say "semiofficial" because while these packages would be considered as parts of Allegro, I'm not interested in doing any kind of vetting or testing of them, so the responsibility for them would rest entirely with you. What do you think? It's your decision... Oh yeah. For the record, what I've seen of your zbuffer code looks really nice, and I think will be a valuable extension to Allegro. Don't worry: this post is about the best way to release it, and not just a polite way of saying that I don't want your code! :-) Sorry about the length of this post, but I think it is an issue that will be of interest to many people on this group. I'd be very interested in hearing your reactions... -- 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.