[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
... is in the usual place.
I have a really good feeling about this version. It adds the dozen or so
things that were at the top on my wishlist, and fixes all the bugs that I
know about, so that the todo list is getting scarily small. I smell a 4.0
release somewhere in the not-too-distant future...
I think it might be time to announce this in some Windows and Linux places,
since it seems stable enough to have lots of newcomers start pounding on it
(at the moment we are mostly getting testing from old djgpp people, and it
would be nice to start spreading a bit outside that). Would any of you other
developer type people be horrified at the idea of a Freshmeat announcement?
And what about the Windows version? I have no idea where Windows game coders
tend to hang out, but if anyone can point me towards what sort of places
this would be suitable, we could announce it there as well.
I've done some minor twiddling of readme files and manuals, trying to get
all that stuff sorted out ready for a release version. So if you spot
anything important that isn't in the manual, or any outdated material,
please let me know. Also if your cool driver has some options that aren't
listed in allegro.txt, the sample allegro.cfg, or the setup program, please
complain loudly about this until I fix it.
The setup program should now be able to autodetect things like the output
frequency, stereo vs. mono, and 8 vs. 16 bits, for the Unix OSS sound
driver. But I've only been able to test this on my card, so the more people
who can try it, the better. Run the setup program, click "Autodetect", then
go into the "Digital Driver" / "Open Sound System" box, and make sure that
all the values look good. And of course, make sure that sounds play
correctly in the test menu :-)
Audiostreams have been revamped so that the sound drivers can tell them what
buffer size is in use, which allows them to avoid sending any stream buffers
smaller than this. In theory this means that you can now use any stream
buffer size you like, rather than having to keep it in the 1k or 2k range,
without getting any distortion. If you've written any programs that use
streams, try knocking the buffer size way down and see what happens: if this
doesn't work, please let me know (at least assuming that you are refilling
the buffers regularly enough: if the soundcard is playing at 44100 and your
buffer is 16 bytes long, you'll have to refill it 2756 times a second in
order to keep up :-)
I've simplified the sound config parameters in an attempt to reduce the
proliferation of config file variables, but have no way of testing this with
the ESD or ALSA drivers: it would be cool if someone could check that these
still compile, still play sound, and that the setup program still knows what
to do with them.
Teijo Hakala added support for a third mouse button, and for wheel input, to
the Windows mouse code, but this didn't work for me. I have a three button
mouse with no wheel, and his code generated frantic z axis movements, but no
middle button clicks. Urgh. So I changed it a bit, but I was mostly guessing
how to do that :-) The current Windows wheel code might be ok, but I have no
way of testing it (at least it stays clamped to zero on my wheeless system
now, though). If any wheel users can test this, that would be most useful
(run examples/exmouse and see if the z value moves). Also, if anyone has a
three button mouse and can get the middle button to show up in Windows, that
would be very interesting, since it doesn't work at all for me, but the code
looks quite plausible so I don't know what is up with that. Final thing
here: I added some code to detect the number of mouse buttons, so if your
test.exe says "mouse has N buttons", where N is wrong, I want to know about
that too.
The demo game now displays author credits along with some floaty names of
all the files that each person has written, but I can't make up my mind
whether these filenames are cool or stupid. Any opinions?
A random comment about text manipulation: in a couple of the Unix sound
drivers, I noticed some code along the lines of:
sprintf(desc, "sample format is %ssigned", (signedmode ? "" : "un"));
Which is all very cool, and it's nicely efficient to avoid duplicating the
same characters for both of the words "signed" and "unsigned", but this will
make life really difficult for any translator-type persons who might want to
replace that text in some language that doesn't negate it by sticking an
"un" on the front :-) So it is better not to do that: pass complete words or
phrases to get_config_text(), in case it wants to come back with a
translated version.
----------------------------------------------------------------
Changes since 3.9.27:
Many improvements by Michael Bukin, in particular enhanced performance in
X, better X mouse behaviour, and DGA graphics support.
Added a manpage output format to the makedoc utility. It doesn't work
terribly well with apropos due to the lack of a one-line summary for each
function, but the basic formatting seems to be ok: please let me know if
you see any problems.
Patches from George Foot for Linux console handing, keyboard, and
filename manipulations.
The audiosteam code is now able to merge multiple buffers into a single
larger one, so it will still work correctly even if the user supplies a
buffer smaller than the current soundcard transfer size. You can even
play streams with single byte buffers now, as long as you refill them
often enough!
Added parameter autodetection to the Unix OSS sound driver.
Made it possible to nest calls to the Unix for_each_file() routine.
Added a load_datafile_callback() function.
Rationalised the sound config variables, so they can be shared between
drivers more easily. For instance sb_freq has been renamed to sound_freq.
Antti Koskipaa added a DOS driver for WSS (Windows Sound System) cards.
Made the Windows timer code more robust, so it will no longer lock up
when you install extremely high frequency callbacks.
Teijo Hakala added wheel support to the Windows mouse driver.
Peter Wang added wheel support to the X mouse driver.
Andrew Geers added -ppassword and -nosound options to the grabber.
Keith Gerdes fixed the DirectDraw overlay mode driver.
Isaac Cruz fixed the bug with accelerated drawing onto sub bitmaps of
DirectDraw surfaces.
Peter Wang added banked mode support to the SVGAlib driver.
Peter Wang fixed some problems with the ESD sound driver, and added an
ALSA driver.
Palette fading speed is now timer regulated, to avoid problems with some
systems (eg. DGA with non-matching color depth) where it can be
excessively slow.
Fixed a couple of different overflow bugs that were causing timers to run
slow on heavily loaded Unix systems.
Added a display of author credits to the demo game.
Changed the info page installation system. It now creates a dir file in
the same directory as the info page, rather than messing around with
symlinks, and autoconf is used to locate the install-info program.
Added an allegro-lib script to the Unix installation, which can be run by
makefiles to find the right linker commandline for building Allegro
programs.
Various documentation updates.
----------------------------------------------------------------
Still todo before 4.0:
Unix MIDI driver.
Add a new blend mode for drawing 8 bit alpha colors onto existing 32 bit
bitmaps, and a special version of draw_sprite() which is able to mix
color depths in this way.
Sort out Windows vs. DOS difference of opinion about video bitmaps (at
the moment, DOS thinks they overlap with the screen, Windows doesn't. I
think DOS is right :-)
Add caching system to speed up filename#object and load_datafile_object().
Try to find some way of fixing datafile password encyrption.
Fix endianess problems and occasional crashes in quantize.c.
Talk to Calin about merging latest P3D rendering stuff.
Native Mingw32 build? Would be cool, but not essential.
--
Shawn Hargreaves - shawn@xxxxxxxxxx - http://www.talula.demon.co.uk/
"A binary is barely software: it's more like hardware on a floppy disk."