Allegro 4.2.0 beta 3 is ready and has been released. This is a beta release for Allegro 4.2.0 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).
Get it from the download page on sourceforge.

This release fixes problems in the previous beta, which was announced in this thread. Please download and test the new release, especially if you had problems with that last beta, and let us know if there are problems. Do not hesitate to report problems even if they have been reported before! Please provide an example programme that demonstrates the problem and if possible help to locate and fix the problem. You can report bugs on the forums, but it would be preferable if you post the problem on the mailing list or the tracker.

Old news

make: *** Warning: File `obj/mingw32/alleg/makefile.dep' has modification time i
n the future (2005-05-14 20:00:34 > 2005-05-14 16:08:46)

Ah, great, now I will have to wait 4 hours!

Now, where I had left my touch...

Yeah, I'll wait about 24 hours when 4.2 stable comes out before I announce it.

This wasn't fixed:

gcc -DALLEGRO_LIB_BUILD -Wall -Wno-unused -mcpu=i586 -O2 -funroll-loops -ffast-m
ath  -fomit-frame-pointer -I. -I./include -o obj/mingw32/alleg/grabber.o -c tool
s/grabber.c
tools/grabber.c: In function `datedit_ask':
tools/grabber.c:3501: warning: implicit declaration of function `vsnprintf'
obj/mingw32/runner.exe gcc -s  -Wl,--subsystem,windows -o tools/grabber.exe obj/
mingw32/alleg/grabber.o lib/mingw32/libaldat.a lib/mingw32/liballeg.a -lkernel32
 -luser32 -lgdi32 -lcomdlg32 -lole32 -ldinput -lddraw -ldxguid -lwinmm -ldsound
obj/mingw32/alleg/grabber.o(.text+0x731e):grabber.c: undefined reference to `vsn
printf'
obj/mingw32/alleg/grabber.o(.text+0x7667):grabber.c: undefined reference to `vsn
printf'
make[1]: *** [tools/grabber.exe] Error 1
make[1]: Leaving directory `D:/Compiler/Source/C/allegro-4.2.0b3'
make: *** [all] Error 2

My ancient MinGW GCC 2.95.3-6.

Aaaaaaaaaaaaaaaaaaaargh!
Actually, I did take some time to fix those. It would seem that I missed a few though. sigh Fixed in CVS...

The released version worked fine with 3.2.3. Now got this problem again in Open Watcom 1.3:

wcl386 -w1 -zq -fr=nul -bt=dos4g -5s -s -I. -I.\\include -fo=obj\\watcom\\asmdef
.obj -fe=obj\\watcom\\asmdef.exe src\\i386\\asmdef.c
Stub exec failed:
D:\Compiler\Watcom\binw\dos4gw.exe
Arg list too big
Error: Compiler returned a bad status compiling 'src\i386\ASMDEF.C'make[1]: ***
[obj/watcom/asmdef.exe] Error 1
make[1]: Leaving directory `D:/Compiler/Source/C/allegro-4.2.0b3'
make: *** [all] Error 2

(Edited: After compiling the file by hand, it continued up to:

obj/watcom/runner.exe wcc386 \\ tools/grabber.c @ -w1 -bt=dos4g -5s -ox -zq -fr=
nul -I. -I./include -fo=obj/watcom/alleg/grabber.obj
DOS/4GW Protected Mode Run-time  Version 1.97
Copyright (c) Rational Systems, Inc. 1990-1994
tools\grabber.c(3529): Error! E1054: Expression must be constant
make[1]: *** [obj/watcom/alleg/grabber.obj] Error 1
make[1]: Leaving directory `D:/Compiler/Source/C/ALLEGR~1.0B3'
make: *** [all] Error 2

int datedit_select(AL_CONST char *(*list_getter)(int index, int *list_size), AL_CONST char *fmt, ...)
{
   DIALOG datedit_select_dlg[] = {
      /* (dialog proc)     (x)   (y)   (w)   (h)   (fg)  (bg)  (key)    (flags)     (d1)           (d2)     (dp)                 (dp2) (dp3) */
      { d_shadow_box_proc, 0,    0,    224,  113,  0,    0,    0,       0,          0,             0,       NULL,                NULL, NULL  },
      { d_ctext_proc,      0,    2,    220,  15,   0,    0,    0,       0,          0,             0,       NULL,                NULL, NULL  },

      /*  the error is in this line, it does not like to initialize the  */
      /*  dialog with an argument of the function  */
      { d_list_proc,       28,   24,   161,  50,   0,    0,    0,       0,          0,             0,       list_getter,         NULL, NULL  },
      { d_button_proc,     16,   80,   81,   17,   0,    0,    13,      D_EXIT,     0,             0,       "OK",                NULL, NULL  }, 
      { d_button_proc,     127,  80,   81,   17,   0,    0,    27,      D_EXIT,     0,             0,       "Cancel",            NULL, NULL  }, 
      { NULL,              0,    0,    0,    0,    0,    0,    0,       0,          0,             0,       NULL,                NULL, NULL  }
   };

(Edited 2: The Windows version compiled fine).

What's with the Sticky L key?

Pete

PH: I typed All and then picked the announcement headline from the list of earlier-typed options as a base. I'll try to remember paying closer attention next time.

Isn't that the second time you do that?

Wow! What took you so long? Anyway, it's nice to see that we are keeping backwards compatability.

Thats all needed to get in to the credits:o. I think I'll just randomly delete a file and post an update;D

If you could make it one of the GUI or FLI related source files then I'd cheer for you!

Actually, I think it was recently introduced. It's a pretty pointless fix, since no one is going to run into it (unless they want to play the Allegro 1.0 demo game I posted a week or so ago), but since the loading code is there anyway, we might as well make sure it actually works.

It's not credits, it's changes. As for exdodgy... you really don't want to know what it tried to show you to do (it probably doesn't even work properly on non-DOS systems).

Both go to the 4.2 compatibility layer in 4.3.
Although as I've said before, I actually use both of them. Well, don't actually use the FLI player much, but I do use the GUI for displaying menus and such. I could write code to do it myself, but as Allegro already has it (and it works fine), it saves me time.

Compiled fine on Mac OS X 10.4.

Compiles here on WindowsXP without any trouble...

I do think trivial changes (spelling, adding comments, etc.) don't need mentioning. The full CVS log is just too detailed; I used to prune it also when making releases. Removing exdodgy was important enough to mention, though you didn't really need to credit me for that :-)

edward Sheets; what compiler(s)?

Compiles all versions without problems - MinGW/MSYS with GCC 3.4.2

I agree. I actually did prune a few attributions and meant to combine several others in something like `minor tweaks and updates to code and examples by such and so' and combine the two GCC4 fixes into one. I must have walked away from my computer after converting the raw changelog and simply zipped up the release when I came back.
I'm growing old

Still no change to the way pure-C fixed point is handled?

Sorry... I'd forgotten all about that patch!
Peter's patch actually looks fine to me, although I'd like to get rid of the conditionals for the signs of the two integers (I think Bob had a trck for that on his page-of-tricks).

EDIT: found it. That would produce

(Untested). Thomas, can you check if this does what it's actually supposed to do? It depends on fixed being a 32 bit integer internally, which may not be very nice, although it's probably safe if a C99 compiler is in use.

A quick test, replacing all the fmuls in my own code with that version works fine. I use fmul quite a lot for graphics calculation (the program is my fledgling entry for the Ray Casting Competition I'm organising) so this gives me a lot of confidence.

EDIT: rebuild (of beta 2 because I'm a bit behind - will update to beta 3 and retry but have some work to do first) seems to work fine. I have no idea which are the best tests to determine this sort of thing but everything I've tried looks okay, including exsprite and ex3d.

Actually, there appears to be a slight mouse cursor bug in that when the mouse cursor is 'changed' (e.g. in exmouse when it says "press a key to change cursor" and the user then pressed a key) it remains exactly as it was until the user moves the mouse. It strikes me this is unlikely to be fixmul related and if I find the same behaviour in beta 3 then I'll properly report it as a bug.

Spot statistic: my heavily fixed point program, compiled against the altered Allegro, is about 5-10% faster with this change.

Is it not also dependant on signed shifts? Anyway, if a 48 or above bit integer is in use internally then the even better solution of

(x*y) >> 16

is available. Perhaps it is desirable that Allegro starts checking for integer size before library building? Or is there already a #define for that sort of thing?

Well, Allegro uses C99 integer types provided by the system if they're available, or it defines them itself (using an `educated guess' where an int is 32 bit) if they're not. This will generate a compile-time warning that Allegro is guessing for integer size. include/allegro/platform/alosxcfg.h defines HAVE_INTTYPES_H, which means that the platform defines C99 types (see include/allegro/platform/astdint.h for the fall-back solution). The fixed datatype is a typedef for int32_t, so assuming it's 32 bit should be safe.

As for checking integer sizes at compile-time, sure but the way I'd do it is with a configure script, which the MacOS X port doesn't use... shrugs I think C99 integer types should be enough saveguard. I wouldn't be opposed to having allegro_init() check if the sizes are actually what Allegro suspects. That will make the library fail on platforms where it guesses wrongly, which is probably better than crashing (however, I suspect not many people check the return value of allegro_init(), so their programmes would still crash).

EDIT:

Yes, that's a bug. It should be fixed in beta 3 though.

Using the latest cvs, the djgpp version is still having problems.

This happens only in the optimized version, not the debug version. On line 684 or so of vbeafex.c, int_ds is declared as a global static int. Changing it to a non-static global seems to correct the problems above, and the optimized version builds without issue.

WinXP, Mingw 3.4.2 both debug and release compile fine. MSVC2003 cannot build the grabber, however, due to the references to vsnprintf. I know this has been fixed in CVS, but I thought I'd comment on it anyway.

gcc 3.4.2 (mingw-special)

Nice job, devs. Your work is appreciated

Now something is amiss with the two last betas. Since the beta1 I've seen a ~100 fps reduction in a program of mine (with beta3 it is ~5-10fps slower than with beta2). What's more, since beta2 both debug and release versions operate at the same speed (whereas with beta1 the release was about 80fps faster). Results show up with both msvc2003 and mingw3.4.2 on WinXP SP2. What

The scene I'm using consists of a clear bitmap, two 'textprintf_ex's, a rotated, masked blit and key input. Is there something that's changed that could account for this slowdown? I'll make a simple demo and try to trace the slowdown, but it would help if possible causes for this where given first.

Nothing obvious comes to mind. There were a few changes to the keyboard driver, some bugfixes to the mouse driver and some threading issues solved.

Running the code through a profiler may shed some light.

Here are a few details about compiling Allegro with the latest djgpp (with GCC 4.0) under Windows 2000 (yes, I know, don't use Windows 2000 with djgpp, but I cannot test it under plain DOS right now):

1. When compiled with WARNMODE=1, I get this warning (does not stop the processing, though):

gcc -fno-exceptions -DALLEGRO_LIB_BUILD -Wall -W -Wstrict-prototypes -Wno-unused
 -Werror -mtune=i586 -O2 -funroll-loops -ffast-math -fomit-frame-pointer -I. -I.
/include -o obj/djgpp/alleg/cpptest.o -c tests/cpptest.cpp
cc1plus.exe: warning: command line option "-Wstrict-prototypes" is valid for Ada
/C/ObjC but not for C++

2. When the directory is already created, mdhelper.bat throws this error under Windows 2000 (does not stop the building): Extended Error 183

3. Under Windows 2000, at least, the info is not installed:

copy docs\info\allegro.info d:\compiler\djgpp\info
File not found - DOCS\INFO\ALLEGRO.INFO
        0 file(s) copied

4. Attached the five patchs I got to get djgpp working correctly (except the -Wstrict-prototypes warning). I am not happy with the vbeafex.c patch (it is already reported in a previous post, replacing static int int_ds with int int_ds. I tried to make it local variable, but there are not a single free register to store it with "r".

The patches should work correctly in previous DJGPP versions, since they are casts. My 2.95.3 copy is broken (asks for txi, I use make all and it compiles one file and stops again. I can continue using make all to compile the next file, but it is just too stupid to continue).

RB: I've slightly modified three out of five of your patches. Revised version attached. Can you check if these still work properly and do what they're supposed to do?

Couldn't yet test your patch, will do later when I arrive home. At work, as promised, worked on the MinGW patch. Attached it is. The most interesting patch is:

Index: src/win/wgdi.c
===================================================================
RCS file: /cvsroot/alleg/allegro/src/win/wgdi.c,v
retrieving revision 1.35
diff -u -r1.35 wgdi.c
--- src/win/wgdi.c	14 May 2005 15:54:52 -0000	1.35
+++ src/win/wgdi.c	16 May 2005 20:00:37 -0000
@@ -114,7 +114,6 @@
 /* hardware mouse cursor emulation */
 static int mouse_on = FALSE;
 static int mouse_was_on = FALSE;
-static BITMAP *mouse_sprite = NULL;
 static BITMAP *mouse_frontbuffer = NULL;
 static BITMAP *mouse_backbuffer = NULL;
 static int mouse_xfocus, mouse_yfocus;

I am not sure if this was made on purpose, but this local variable was shadowing the global one defined in mouse.c. I removed this copy, and it worked fine. Maybe someone should compile with -Wshadow and check everything again?

Also, I casted the parameters to DWORD or BYTE if they were used in Win32 API functions. If you want, you can change them to unsigned long and unsigned char.

Note that this is a unofficial version of GCC 4.0 for MinGW, but I am confident solving these warnings will prepare Allegro to work flawlessly with the official branch.

(Edited on 2005-05-17: I tested your patch. Moving the static variable inside the function doesn't work, the compiler cannot find it. By the way, I cannot setup sound with DJGPP (no hardware detected). I hope someone can test this on a real W9x system. I will see if I can install Windows 95 on Qemu).