Allegro 4.1.17 WIP has been released. Get it from the Allegro SoureForge
page at [url http://sourceforge.net/projects/alleg/]. Also see http://alleg.sourceforge.net/.
This release is a Work-In-Progress release that adds features and corrects problems with regard to the 4.0 codebase. It is API (source) compatible with 4.0.0 on every platform, except for a few minor changes (see docs/html/api.html).
=======================================================================
============ Changes from 4.1.16 to 4.1.17 (December 2004) ============
=======================================================================
Sven Sandberg fixed a few problems with the sprite rotation code.
Sven Sandberg optimized blitting between different colour depths.
Evert Glebbeek added support for the use of native window manager cursors.
Chris Robinson made install_allegro() check if the library version matches
the version of the headerfiles installed.
Peter Wang fixed some problems with rest() on UNIX systems.
Evert Glebbeek added an is_windowed_mode() function.
Elias Pschernig added the scancode_to_name function.
Elias Pschernig made rest use usleep() on MacOSX.
Chris Robinson fixed the incorrect use of -export-dynamic on UNIX
Elias Pschernig, Chris Robinson and Peter Wang fixed XOR mode leaving
droppings in X11.
Elias Pschernig fixed several dependency issues.
James Lohr fixed a problem with mouse acceleration in fullscreen modes under
Windows.
Peter Wang fixed a problem in the TGA loader.
Lennart Steinke contributed keyboard layout detection code for Windows.
Peter Wang fixed a bug that caused Allegro to crash if it failed to
initialize.
Peter Wang fixed a deadlock related to X vsync emulation.
Daniel Schlyder fixed make uninstall with mingw make.
Elias Pschernig fixed QNX issue of not including utimer.c
Angelo Mottola fixed compilation problems on BeOS and fixed the detection
of VRAM.
Evert Glebbeek fixed compilation problems on *BSD.
Elias Pschernig made the X11 window hidden in GFX_TEXT mode.
Peter Wang removed remapping of numpad keys when NumLock was off in Linux
David A. Capello made override_config_file also be used for writing to the
config file.
Julien Cugniere added an X11 message box for allegro_message under X11.
Vitaliy Chetverikov a small bug in the GUI where the return value of
MSG_IDLE was ignored.
Peter Wang made several improvements to the examples.
Grzegorz Adam Hankiewicz made a lot of improvements to the documentation.
Elias Pschernig made make-install not build examples.
Peter Wang fixed several instances of symbols not declared static that should
have been.
Elias Pschernig replaced the X11 keyboard driver with a new XIM driver.
Peter Wang fixed a problem with Linux headers and Allegro headers both
declaring KEY_ constants, as pointed out by David A. Capello.
Elias Pschernig fixed X11 async reply in DGA2 mode detection due to missing
XLOCK/XUNLOCK
Peter Wang fixed problems in ex3buf, which was trying to lock symbols which
had been removed.
Elias Pschernig cleaned up grabber/dat documentation.
Daniel Schlyder added ALLEGRO_LIB_BUILD flag for gcc variants not using
configure.
Elias Pschernig fixed bugs in matrix_to_quat and get_align_matrix.
Evert Glebbeek fixed a problem with the X11 port when
ALLEGRO_MULTITHREADED was not defined.
Matthew Leverton added support for a fourth mouse button to the Windows port.
Michal Molhanec added a faq section about the giftware license.
Elias Pschernig added the license disclaimer to the docs.
Evert Glebbeek added missing vtable entries for AllegroGL, as requested by
Robert Ohannessian.
Dustin Dettmer spotted a typo in save_bitmap.
Sam Hocevar removed deprecated use of init_read_test, test_byte_read, etc.
Peter Wang fixed a bug in the Windows keyboard driver.
This WIP should be reasonably close to what 4.2.0 is going to look like. There are a few things still left to do, but by all means, do test it and report how it works or doesn't work for you!
W00T!!!
Lennart Steinke contributed keyboard layout detection code for Windows.
On some platforms (like DOS and Windows), Allegro requires the user to specify the language of the keyboard mapping because it is impossible to obtain this information from the OS, otherwise the default US keyboard mapping will be used.
Feels like that passage should be changed then
[EDIT]
It seems like scancode_to_name() is broken, unless I'm using it wrong
With regular readkey() and scancode_to_name() the only name I get is "(null)", and with ureadkey() (the docs don't say which of them apply) I get completely nonsensical mappings.
Feels like that passage should be changed then
Indeed. Thanks for spotting that.
It seems like scancode_to_name() is broken, unless I'm using it wrong
With regular readkey() and scancode_to_name() the only name I get is "(null)"
Hmm... just to make sure, you did use scancode_to_name(readkey()>>8)? That's how I think it should work. Best to ask Elias to make sure...
It's also possible that the function doesn't yet work in Windows... but I'm not sure about that.
It should work. And yes, it works with the scancode, so readkey() >> 8. Actually, just run exkeys, the names it displays to the right come from scancode_to_name. If they all says (null), than that needs to be fixed.
[Edit:]
To make this clear, the reason why I think scancode_to_name was needed is, if you have some game, and want keyboard controls to be user configurable. So, what you would do is, let the user select a control, and ask to press the desired key. You can now either use readkey/ureadkey, but then you can't use keys like Left-control or Right-control. Or, you can use key[], but then you don't know what name to display for a key. The KEY_* constants are not accurate, e.g. KEY_TILDE doesn't exist on many keyboard layouts. This is exactly what scancode_to_name is for. It tries to name a key, e.g. scancode_to_name(KEY_F1) will return "F1", and scancode_to_name(KEY_TILDE) should return whatever the OS thinks is the name of the corresponding key.
My bad. I forgot that readkey doesn't return the scancode but instead a value containing both the scancode and the ASCII value
Oh well, I blame it on being in a hurry when testing it...
It refuses to compile for me.
...other stuff here, but no errors or warnings. gcc -DALLEGRO_SRC -DALLEGRO_LIB_BUILD -Wall -Wno-unused -mcpu=pentium -O2 -funro ll-loops -ffast-math -fomit-frame-pointer -I. -I./include -o obj/mingw32/alleg/ wkeybd.o -c src/win/wkeybd.c src/win/wkeybd.c: In function `key_dinput_handle_scancode': src/win/wkeybd.c:174: `DIK_PAUSE' undeclared (first use in this function) src/win/wkeybd.c:174: (Each undeclared identifier is reported only once src/win/wkeybd.c:174: for each function it appears in.) make: *** [obj/mingw32/alleg/wkeybd.o] Error 1
gcc -v says it is gcc version 3.2.3 (mingw special 20030504-1)
make -v is GNU Make 3.80
Compiles for me without problem, so no idea. You have MINGDIR set, and run fix mingw32 before building, right? Just guessing, it works here.
Yes, mingdir is set, and I did run fix mingw32. Haven't had problems compiling allegro for a long time. I also completley removed the old directory, 4.1.16, before I unzipped the new one.
edit: all the other files are compiled without problems, it's just this one that complains.
Edit again:
And when i try to compile it, I do as i always do:
fix mingw32
make
(and here i would run make install, if it wasn't for the error)
The definition is in dinput.h. Do you have the DX headers (I guess so, check that file to see if you find that definition there)?
No, it wasn't in d:\mingw\include\dinput.h
So i guess i should redownload the dx headers from alleg.sf.net then? I will try that.
edit: looks like i used the dx80 headers before. Will try dx70 now
Try downloading the headers for DX 8. I think there is a link at a.cc to those minimun headers as well.
No, i had dx8 before. I am using dx 7 now and it compiles. Thanks for the help.
Any reason for avoiding a proper makefile.mgw update?
Compiling Allegro for MinGW32, optimised. Please wait... gcc -DALLEGRO_SRC -DALLEGRO_LIB_BUILD -Wall -Wno-unused -mcpu=pentium -O2 -funro ll-loops -ffast-math -fomit-frame-pointer -I. -I./include -o obj/mingw32/alleg/ allegro.o -c src/allegro.c `-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
I must say, this is quite lovely. Allegro has been spending almost all of its time on bug fixes making it pretty stable.
Fabiano, which compiler you are using? I would guess GCC 3.4 or something like that. I used 3.2 and compiled without warnings.
Rock. Is it just me, or are there a lot of good fixes/additions with this one?
gcc (GCC) 3.4.2 (mingw-special) Copyright (C) 2004 Free Software Foundation, Inc.
Also, it seems the "-mtune=i686" issue is gone.
I loved that mouse-fix too! (windows version)
EDIT: nope, unfortunately. It still crashes in windowed mode (not on fullscreen though).
Any reason for avoiding a proper makefile.mgw update?
Yes, no one uses Windows so these things tend to go (mostly) unnoticed... ok, I remember that you did point it out.
At the moment, I think changing the flag is not worth it, as it would break older versions of the compiler. For the future, it's something that we should look into though.
Is it just me, or are there a lot of good fixes/additions with this one?
There are quite a few, yes. Part of the reason is that we really want to get Allegro ready for 4.2 so that work can focus on rebuilding the API.
If anyone is interested, here are the library versions I'm using to compile 4.1.17 under msys and mingw without any problems:
MSYS-1.0.10
MinGW-3.1.0-1
msysDTK-1.0.1
msys-libtool-1.5
w32api-3.1
binutils-2.15.91
mingw-runtime-3.5
mingw-utils-0.3
after those are installed I updated the compiler:
gcc-core-3.4.2-20040916
gcc-g++-3.4.2-20040916
DO NOT UPDATE THE AUTOCONF (2.5.9) AND AUTOMAKE (1.8.2) PACKAGES FOR MINGW. THEY ARE BROKEN!>:( I had a lot of problems on another project until I found out from some other users these updated libs are really broken. Even though Allegro doesn't use them, it's better not to install them anyway.
I use Dev-C++ 4.9.9.1 without the integrated mingw option and the DX8_mgw headers from the Allegro site.
Rock. Is it just me, or are there a lot of good fixes/additions with this one?
Its not just you wait for 4.3.* muahaha. Though there (IIRC) WILL be api breakages in 4.3.*.
Though there (IIRC) WILL be api breakages in 4.3.*.
I think 4.2->4.4 will be light enough that there won't. But I can't say for 100% certain.
I'm loving it. ®
Something that isn't made too clear about building Allegro from source:
If you plan on compiling it for MSVC, you of course must use gnu make to do so, but many people use MinGW, while building Allegro requires CR/LF formatting. The tool to do this, UTOD, isn't distributed with MinGW. It's DJGPP.
Just something to ponder for documentation purposes.
The tool to do this, UTOD, isn't distributed with MinGW
Something wrong with unix2dos.exe?
And in any case, what are you saying has to be converted for MinGW?
I thought the make process did that automatically (LF -> CR/LF when fix.bat was run for "ming32")? Either that or the .zip distribution has CR/LF formatting?
From fix.bat:
echo Converting Allegro files to DOS CR/LF format...
utod .../*.bat .../*.sh .../*.c *.cfg .../*.h .../*.inc .../*.rc
utod .../*.rh .../*.inl .../*.s .../*.txt .../*._tx makefile.*
Just saying that by default, allegro uses utod to convert the files. A lot of people don't take time to read. My friend Jeff being one of them. He complained for about 2 hours straight today about not being able to compile this. After getting on my last nerve, I finally, sent him utod.exe. He was using MinGW.
i have been using msvc and mingw for a long time now..
and each time it issues the utod command i get an error.
i just ignore it and everything compiles fine.
it would be nice to fix it .. i guess.
what are the main reasons why MSVC's make can not be used ?
It doesn't use the same symantics and syntax as GNU make, and I don't think we have any devs that understand it and could keep it up to date. The good thing about GNU make is that, even across different platforms, the symantics are the same.. you just use different OS calls.
If you plan on compiling it for MSVC, you of course must use gnu make to do so, but many people use MinGW, while building Allegro requires CR/LF formatting. The tool to do this, UTOD, isn't distributed with MinGW. It's DJGPP.
Well, the compiler should be able to handle both formats. The only program that I know of that is too broken to recognize both is notepad. Besides, the files in the ZIP archive already contain CR/LF endings. This is the only difference (contents-wise) between the .zip and .tar.gz source distributions.
Just pass the --quick flag on the fix command line to disable the conversion. Maybe this could be the default on DOS/Windows?
is there a way to test for the presence of utod ?
is there such a thing as a file_exists() for makefiles ?
that searches the path ?
IIRC, there's an executable in the Allegro distribution that does just that. (I must use someone else's computer for internet access, and there's no Allegro so I can't check.)
Hi,
On a Mandrake 10.0 official, gcc 3.3.2 (mdk), linked with aastr and almp3
each time I'm trying to use allegro_message(..) it return
'broken pipe'
Any idea ? Is there an exemple that use allegro_message ?
Thanks for the help, good job anyway (was hoping a lot of an Allegro_message in a X Box)
Do you have xmessage installed on your system?
The relevant code is in the _xwin_sysdrv_message() in src/x/xsystem.c, if you could help pin point where the crash happens exactly, that would be very helpful. Needless to say, it works fine here (although this does remind me that I want to make the message box a configure option; I prefer the terminal myself).
Seems xmessage isn't installed by default on Mandrake 10.0 .
I've tried to install via rpmdrake (Xform package), install is fine but it didn't work anymore.
Guess I'will not allegro_message for a few.
Thanks for the answer.
Maybe we should use a simple system() call as in Julien's original patch? Either that, or Peter will have to fix it and handle SIGPIPE or something properly
Maybe we should use a simple system() call as in Julien's original patch?
I'd try to use popen if I wanted to use pipes personally, although I'm not sure why pipes are the way to go in this case.
Either that, or Peter will have to fix it and handle SIGPIPE or something properly
Well, yes, I suppose we have to do that if we want to use pipes like this. Hmm... there could be a potential similar problem with get_executable_name() in rare circumstances I suppose...
The only reason for pipe's was a security concern, with system("xmessage blah") the "blah" apparently gets visibles somewhere in the /proc filesystem. As I said on [AD].. I don't really see a problem with that personally.
system also goes through your shell, so "blah" should be escaped for shell meta characters.
Yes, it was execvlp or something, not system, sorry. See the patch by KittyCat on [AD]