Mail Archives: djgpp/1997/09/08/19:03:53
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.
- Raw text -