Mail Archives: djgpp/1997/09/11/23:04:02
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.
- Raw text -