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).

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!!!

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.

Indeed. Thanks for spotting that.

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).

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.

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.

Its not just you wait for 4.3.* muahaha. 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.

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:

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.

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

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.

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]