[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
I'm trying to figure out exactly how much work remains to be done before we
can call this a 4.0 final version, and came up with the following. Any
additions, removals, or other suggestions would be most welcome (and no, I
don't have any fixed timeline on this, just trying to decide how much stuff
needs fixing before we will be there).
General Stuff
-------------
Most of the framework code seems fairly solid at the moment. Here are a few
relevant things from my todo.txt file (ignoring some others which are
longterm nice ideas but I'm not fussed about having done in 4.0).
Functions to draw alpha channels onto existing bitmaps. This is trivial,
just a new blender mode and a special case routine that allows
draw_trans_sprite() to use this blender mode to overlay an existing 8 bit
greyscale bitmap onto the alpha channel of a 32 bit destination image. I'll
add this sometime, it's not a big job.
George, if you are reading this: we were talking about inconsistencies with
nested datafiles and individual object access, but I forget what we decided.
Also, my todo list reminds me that I need to try to find some way of fixing
the fact that datafile password encyrption isn't very smart, and I have a
feeling that these two jobs might have a common solution. I'm not hugely
fussed about getting this done for 4.0, but it would be nice to sort out.
quantize.c is not portable (endianess and integer size issues), and also
crashes on some obscure input images. I'm not sure what to do about this: it
will require a fair bit of time to understand the existing code well enough
to fix it, but I hate to reimplement stuff that basically already works.
Anyway, this needs to be looked at, as it is the only major piece of
nonportable code left.
Calin, if you are reading this: my todo has a note to check with you about
merging the latest P3D rendering stuff. How goes that, do you have
interesting things that would be good to merge? If so, fire away: I'll leave
this one up to you to decide what (if anything) you want to do with it. The
current WIP code in iscan.s is more or less that same as you last sent me,
but I made some minor portability tweaks to the asm syntax (using the FUNC()
macro for entry points, _align_ to align things, GLOBL() around any
references to global symbols, and FSEG instead of %fs for selector overrides
(because you don't need those on Windows or Linux). Also, you can't declare
global variables in asm files (doesn't work with MSVC or Watcom), so I moved
the MMX mask tables into poly3d.c. As long as you bear these portability
things in mind you are welcome to change whatever you like in here, but bear
in mind that if you add new features to it, they need to be duplicated in
the C drawing code as well (src/c/cscan*).
Documentation needs to be updated, mostly the platform specific readmes need
to give a better introduction for people who don't have an Allegro/djgpp
background, the main docs need to have more detail about particular drivers
and system quirks in the platform specific sections, and we need a new
section that gives an overview of what to bear in mind when porting or
trying to write portable code.
DOS
---
I'm happy with the current DOS code, and don't mind calling this a finished
version whenever the other platforms are ready. The only things being worked
on at the moment are periphery like joystick drivers, that don't hurt
anything too much.
I do need to fix some stuff to make it compile with gcc 2.95 and WARNMODE=1,
but that is just a matter of sorting out some warnings about structures that
are only being partially initialised (I wish gcc wouldn't warn about these
at all, but I'd rather fix it than ignore it).
Windows
-------
Hardware accelerated drawing functions don't work on screen sub-bitmaps.
I'll look into this.
The overlay (windowed) modes are incomplete, but I don't know enough to do
any work on them, and I don't think they are essential in any case: as long
as the fullscreen mode works ok, I'm happy to call that a 4.0 release.
Stefan, if you are reading this: are you still around, or just busy with
other stuff, or lost interest altogether? No pressure, but it would be
useful to know whether I should expect you to write more stuff at some point
in the future, or whether I have to find someone else to take care of it :-)
Audio streams don't seem to work properly. There are two problems here: the
framework code isn't good about different soundcard buffer sizes (I can fix
that), and DirectSound isn't being notified when we change the buffer
contents (I can try to fix this, but am not sure I know enough about
DirectSound to follow what is going on. If any more knowledgeable people
want to look at it, that would be great).
We still have a difference of opinion between Windows and DOS/Linux about
how video bitmaps are supposed to be allocated (whether they extend or
overlap with the existing screen surface). I don't think there is any good
solution for this, so I'm just going to have to sort it out and put up with
it not being very elegant. I think that the Windows version will have to
give way here, since it is outnumbered by the way that other platforms want
to behave.
What other problems have I forgotten about, or is it really this close to
perfection? :-)
It would be nice, now that the code has stabilised a bit, to get Mingw32
building a native version of the DLL. Not essential for a release, but I
think it would be a good thing to have it all buildable using free tools,
and it has a lot of hack value. I might work on it if I get bored with other
stuff, but otherwise it would be great if someone else wanted to investigate
this (Michael Rickmann did get the DLL building natively back when he did
the original Mingw32 port, so it certainly is feasible).
Linux
-----
Most of the remaining problems are to do with graphics modes, but that isn't
really our fault: the Linux console just doesn't have any standard graphics
driver systems, so often there simply isn't anything there for Allegro to
use. We do now support all the common standards, some quite well (VGA,
mode-X, fbcon, VBE/AF) and others more experimentally (SVGAlib and GGI). I'm
sure that the latter will stabilise as more people help to fix problems with
them (unfortunately all SVGAlib programs crash at random points on my TNT
card, so I can't really tell what problems are Allegro and which are SVGAlib
:-)
The biggie is X support. Michael: care to give us a quick progress report on
this? This would be a really nice thing to have in because it would make
sure that just about every Linux user has a way to get graphics working no
matter what their hardware. I've never programmed X before, but I'd be happy
to help out if you can point me in the right direction, or otherwise I'll
just shut up and let you get on with it: whatever you prefer :-) If you are
busy with other stuff and a long way short of having any finished X graphics
code, how long would it take to do a quick bodge and just copy across the
graphics stuff from the existing XWinAllegro package?
The Linux readme is very complete, but I think could perhaps be even a bit
more obvious about the security implications of being suid root. Allegro was
never written with security in mind, and although it is much better since
Michael Bukin added overflow checking to all the filename manipulations,
there are still no doubt a million ways that a clever person could trick it
into giving them root access. At some point we will no doubt come under
pressure to do a proper security audit and deal with all such problems
(personally I can't think of anything more boring :-) but for now we just
need to be very clear about telling people that exploits almost certainly
exist, so if this might be a problem, you must not give people access to
suid Allegro binaries.
On my machine, the OSS sound driver fragment size defaults to 4096, but that
results in about a 2 second delay before sound is heard. I can decrease it
down to about 128 without any problems, and with that value, even DIGMID
music works perfectly, but presumably this will depend on the machine and
soundcard type. How carefully chosen is the 4096 value? If that was just a
guess, should we perhaps try to collect data about what values work best for
a range of different people, or maybe try to calibrate it based on processor
speed?
Is there any way to autodetect OSS support for mono/stereo and 8/16 bits, or
do we need people to configure this manually? On my machine I get a vast
quality improvement (obviously) after I change from mono 8 bit to stereo 16,
but experience on DOS shows that most people will never bother changing this
sort of config setting, so if we can't autodetect it, they will be stuck
with poor quality sound. That's their fault for being dumb, of course, but
it would still be nice to do the right thing by default :-)
There is no MIDI support at the moment: how hard would this be to add?
Anything else?
BeOS
----
Jason, if you are reading this: I presume that the BeOS version is unlikely
to be completed especially soon? Unless you feel like pulling off some magic
tricks I expect that this will still be in-progress by the time we hit 4.0,
but I thought I'd include it just for the sake of being complete.
Distribution
------------
It's probably not too early to start thinking about how we are going to
distribute all this stuff. I did at one point think about making cutdown
versions for each platform, but looking at it now, the platform specific
code is only a small fraction of the total size, so I don't think that is
such a useful thing to do (it more important that all versions of it be
complete and self contained).
What I think is useful, is to make a distinction between developer
distributions (for use by people who are writing Allegro programs), and end
user distributions (which contain shared libs for use by people who just
want to run Allegro programs).
The shared lib distribution is easy: we just get someone to compile a DLL,
build some .so files, package them up with a setup.exe or RPM, and there we
have it. I tend to think that binary distributions will work better on
Windows than they do on Linux, but either way, this can come along after the
official release, and people can always fall back on the full source version
if things go wrong with the binaries.
The interesting thing is how do we distribute it for use by developers.
djgpp is no problem: the source zip is proven to work nicely. Linux is also
no problem: we take exactly the same files as for djgpp, run them through
fixunix.sh, and turn them into a tarball. I don't think it is even worth
making an RPM for the source version (although RPM is certainly good if we
start distributing binaries), since the standard "tar -xvzf allegro.tgz; cd
allegro; configure; make; su -c "make install" works exactly the same as
everyone will expect, and I think it actually does more harm than good to
start breaking established conventions by using some other package format.
Watcom is more interesting: the build process there is quite twisted. But I
don't care very much: nobody is using the Watcom version anyway (there is no
reason to when the djgpp code runs faster), and it isn't hard to build, just
awkward because you have to install djgpp as well as Watcom.
The really interesting thing is MSVC. You need djgpp installed in order to
build this code, and there is no easy way around that (MSVC lacks an AT&T
compatible assembler, and also has no good make program, and you can't
distribute source as VC project files because the project file syntax isn't
compatible across different versions of MSVC). For serious developers it is
no problem having to install GNU make and as, but for a lot of people who
just want to use Allegro, I think this can be a nasty stumbling block. But,
we can't just distribute binaries, because those would be huge! It seems to
me that it would be useful to make an "MSVC lite" distribution, where we
have done all the awkward parts that require gcc (build the DLL, converted
the docs, etc), but still just include the examples and test programs as
sources along with some simple way (perhaps even just a batch file) to
compile them in-situ. I don't really like this idea (it goes against the
grain to have this sort of bodged partial-build system, and would lose some
features like support for source plugins in the grabber, that need a true
makefile), but I think it is worth doing for practical reasons. Any specific
ideas about exactly how we might go about this would be most welcome...
Ok, what did I forget? And most importantly, who volunteers to do which
parts of the above list? If there aren't any other takers I'll probably get
it finished sometime over the next year or so, but the more people are
involved, the faster it will go (and judging by my recent slow performance
with WIP uploads, the more non-me people are working on it, the better :-)
--
Shawn Hargreaves - shawn@xxxxxxxxxx - http://www.talula.demon.co.uk/
"A binary is barely software: it's more like hardware on a floppy disk."