Mail Archives: djgpp/1998/03/23/05:06:09
D. Huizenga writes:
> I just went to Shawn's home page, and I notice a new
> WIP of Allegro 3.0 is out. Good work, guys! I began thinking,
> why not start a "wish list", so that we have ideas of things
> to add.
Sounds like a good plan. Of course I can't promise that I will
actually implement any of these suggestions (it is much easier
just to ignore them :-) but I'm always interested to hear what
you want adding, and I will always at least consider anything
that you can suggest...
> 1. A windowing system in which each window contains a
> "standard" allegro dialog (using pointers). (I am already
> working on this, but it isn't going well).
There are already several addon packages that provide enhanced
GUI routines. In particular, take a look at:
http://huizen.dds.nl/~deleveld/degui.htm
http://moopws.csse.muroran-it.ac.jp/~kutch/mtd.htm
http://www.cpedu.rug.nl/~N0772984/
> 2. Serial support.
Already done! See:
ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v2tk/allegro/dzcom052.zip
> 3. Integrated CD-Audio routines (Maybe merge it with BCD?). This
> would be _really_ cool if it was set up so that the new audio
> input routines could be used to record from the cd.. Or maybe
> just mix CD and audio at the same time (Actually, since the
> cd usually goes straight to the sound card, this would be
> automatic..) in at the same time.. Karaoke anybody? :-)
In terms of recording sound from the CD, this is just a matter of
setting the input select bits in the soundcard register. That isn't
supported by the WIP version on my website, but has since been
implemented and will be included in the next update.
When it comes to controlling the CD, what would be the point of
adding this to Allegro when BCD already does such a great job of
it? I know it is a different library, but it is very reliable and
easy to use, which would make it rather redundant to put this code
in Allegro as well.
> 4. This is probably a bit unreasonable, and not really necessary
> in a "game library", but why not include printer drivers that
> could print bitmaps? Perhaps they could be used to print score
> cards.. (This is actually a pretty stupid idea, IMHO).
There was some talk about this on the Allegro mailing list a while
ago (have a look through the archives on
http://www.canvaslink.com/allegro/search.htm), but I think it is
very much an addon kind of functionality rather than something that
should be included in the core lib.
In terms of practicality, there are a huge number of different
printers and no standard way to access them all. I think a much
easier solution would be to write a bitmap -> Postscript
converter and then use Ghostscript to print out the .ps file,
or perhaps just save the image into a .bmp which you can then
print using Windows Paint.
> 5. Maybe i'll do this.. I think it would be nice to have an
> "installer creator". It could put all of the files in a data
> file, and have the first element be something similar to a windows
> .inf installation file. Then there could be a "standard" Allegro
> Installer that read the file and installed the program.
That could be useful, if you want to write it. But is this really
needed? Given that a program can be written to extract all its
resources from a single datafile at runtime, and the exedat utility
can then be used to merge this datafile with your program executable,
why not just make your program so that it can be distributed as a
single, directly runnable binary?
> 6. Anyone care to write a short tutorial for newbies? (Hmmm.. Funny..
> I find myself thinking that maybe I would read it through a couple
> of times.. Help myself to quit making these hard to track down
> bugs in my programs... ;-)
Check out:
http://www.canvaslink.com/gfoot/vivace/
http://www.arcticnet.no/~ovek/allegro/
Of course, more documentation is always a good thing, so it would be
fantastic if you want to write any more such tutorials, perhaps focusing
on more specific aspects of Allegro...
> 1. Fix the scroll bars on list boxes so that they look like the ones
> on an Atari STe. Right now they are inverted from a normal ST.
Are they? It is so long since I used an Atari that I don't remember :-)
I'm not sure I agree with you on aesthetic grounds, though. If the
Atari did use white on grey, I think it got it the wrong way round!
(the dialog background is white, so it makes sense to me for the scroll
bar background to be white as well). And in Windows, the default color
scheme has darker sliders on a pale background.
Shawn Hargreaves.
- Raw text -