Mail Archives: djgpp/1998/04/06/06:07:46
D. Huizenga writes:
> I will post the latest version of the list here, if you want
> something added, go to my home page and submit the form there.
I must admit that I have quite mixed feelings about this wishlist. On
the one hand, I'm always interested to hear what things people would
like to see added, and good suggestions are invaluable. But this
doesn't mean I will act on all these ideas: in fact I disagree with
probably about half the things in your current wishlist, and of the
remainder I think that most would be far more suitable as addon
packages than as part of the core Allegro library. Of course you are
welcome to wish for anything you like, but I'm not totally happy
with the current presentation of your list, because it puts some
pressure on me to actually implement these things. Listing desired
features is pointless in the absence of a volunteer to code them,
and even more futile in the cases where I wouldn't want that code
even if somebody did write it. Surely it would be more productive
if everyone who sees a need for new features would simply sit down
and implement them as an addon module?
So, I have a couple of suggestions concerning how you present the
wishlist...
I think you should make it clear that this is not an official
todo list, but just the personal opinions of whoever suggested the
ideas. As such, I am quite likely to disagree with some of the
entries.
Also, are you sure it is such a good idea to keep this format of
adding new suggestions to the bottom but never removing old ones
from the top? That seems likely to quickly fill up the list with
a lot of irrelevant or outdated comments: surely it would be
better to move answered suggestions into a different section, or
at the very least to put the answers side-by-side with the original
suggestions?
But that aside, here are my comments on the recent list additions:
> 1. A windowing system in which each window contains
> a "standard" allegro dialog (using pointers).
I think this is best done as an addon package, and as such there are
already several libs that provide exactly this functionality.
> 4. Editable, multi line text box. Like in Visual
> Basic.
Again, better as an addon.
> 7. Dithering support (for 24bpp->8bpp, 24bpp->16bpp,
> and 24bpp->15bpp color conversions).
Ditto.
> 8. Faster (if possible) floodfill() routine.
> (Apparently, he has a game which makes heavy
> use of it and is kind of slow..)
My general advice would be to write the game better: a floodfill is
not something you should be using in realtime code!
Of course it would be cool if someone can speed up the routine, but
I did spend quite a while on it in the first place and I don't think
the current version is too bad.
> 12. Special compression for sound files (LZW + u-law or alike).
I'm not sure about this. I did some experiments a while ago with using
a delta waveform to improve the LZ compression ratio, but this made
very little difference. I think some kind of ADPCM system, or perhaps
delta+huffman coding, would be needed to give useful results: this
might be nice to support, but it would add significant extra code to
the library (it seems kind of backward to make the executables bigger
when your objective is to reduce file sizes :-)
> 13. MPEG or AVI video support (possibly as an addon).
Certainly an addon. This would be a great thing to have, though!
> 14. Locked Interrupt-Driven Stream Callback Sound
> (Wouldn't this be impossible/impractical on some
> sound cards? (If I understand what he wants correctly :-) )
This idea was discussed here a couple of weeks ago. It is basically
possible with the current drivers, but not totally reliable due to
the chance for interrupts to coincide and do nasty things. I'm not
going to allow this in general terms because it might cause major
problems for other soundcard drivers in the future.
> 15. Overridables For Memory-Access
> (like an void*(*allegromalloc)() etc). This would allow
> users to make Allegro use their own memory manager.
Again, this was recently discussed here, and the conclusion was a
resounding no. If people want to write their own memory manager,
it is up to them to make sure the normal C allocation functions will
still work correctly. You cannot get rid of standard language features
and still expect library code to go on functioning (this applies
to libc as much as Allegro).
> 17. In the new WIP, instead of just updating the
> docs, it would be nice to have something like
> an addendum.txt, which contains all of the changes
> to the docs since the last "final" release.
Is this not covered by the ChangeLog and NEWS files?
Shawn Hargreaves.
- Raw text -