Alllegro 4.2.0 beta 3 has been released!

Alllegro 4.2.0 beta 3 has been released!

Evert

Member #794

November 2000

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.

CHANGES said:

==============================================================================
============ Changes from 4.2.0 beta 2 to 4.2.0 beta 3 (May 2005) ============
==============================================================================

Grzegorz Adam Hankiewicz did several documenation update.

Evert Glebbeek cleaned up some of the global namespace pollution in the
Windows port.

Chris Robinson made improvements to the Windows sound driver.

Chris Robinson made the GUI multi-selection box behave a bit nicer.

Grzegorz Adam Hankiewicz added a bunch of ASSERTs to the code to check for
out-of-range arguments.

Jakub Wasilewski fixed a bug when loading greyscale TGA images

Evert Glebbeek fixed a bug where the bottom and right line of pixels was
not updated on show_video_bitmap, as pointed out by Thomas Harte.

Evert Glebbeek documented JOY_TYPE_* defines for Windows and Linux.

Peter Wang made some cosmetic changes to some of the examples.

Dark Nation restored the ability to read old-style encrypted packfiles,
i.e. those produced before Allegro 3.9.30. This was silently removed
from 4.1.18 when custom packfile support / decoupled compression routines
were added.

Peter Wang added acomment describing the evdev mouse driver in allegro.cfg.

Evert Glebbeek made the grabber and dat utilities now use Allegro's buildin
load_font() function and made datafiles properly store truecolour fonts and
added a datedit_select() callback to datedit.

Evert Glebbeek fixed some unsafe assumptions on the size of integer datatypes.

Arthur Huillet fixed a typo in the docs.

Elias Pschernig restored Alt+key = ASCII code 0 behavior for the windows
keyboard driver

Evert Glebbeek fixed a bug that caused a crash when loading Allegro 1.x
datafiles containing 4 bit bitmaps.

Peter Wang clarified the mode select documentation and made the mode
selector clear the input variables before passing them on to the filter.

Peter Wang fixed a bug in the mode selector where disabled drivers were
still shown with empty resolution lists. Pointed out by Hrvoje Ban.

Elias Pschernig fixed Allegro's internal multithreading in Windows. This
fixes a deadlock on exit.

Robert Alfonso made the MSVC makefile call `link /lib' rather than `lib',
which doesn't work for the free toolkit.

Peter Hull fixed a problem with hardware cursors not working properly in
MacOS X.

Peter Hull added a missing enable_hardware_cursor vtable entry and added OS
native cursors for the MacOS X port.

Grzegorz Adam Hankiewicz documented online Allegro patch generator.

Evert Glebbeek renamed datafiles._tx -> datafile._tx

StApostol updated the FAQ to use rest(0) instead of the deprecated yield_timeslice().

Evert Glebbeek silenced some GCC4 warnings in MacOS X.

Peter Wang fixed warnings and errors with gcc 4.0.0 on the unix port;
reported by Milan Mimica.

Peter Wang added preprocessor symbol ALLEGRO_NO_FIX_CLASS that the user can
define to not pull in the `fix' class in C++ programs.

Peter Wang removed the exdodgy example.

Elias Pschernig fixed another X11 async reply.

Elias Pschernig made the seek in expackf test work with windows line endings.

Elias Pschernig removed some superfluous variables

Evert Glebbeek fixed a small bug that prevented the Allegro template for
Project Builder from installing correctly on MacOSX

Elias Pschernig enabled warnings about unused variables with
--enable-strictwarn in unix.

Peter Wang fixed a warning with Watcom 1.3

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.

ReyBrujo

Moderator

January 2001

Quote:

Allegro 4.2.0 beta 2 is ready and has been released.

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

--
RB
光子「あたしただ…奪う側に回ろうと思っただけよ」
Mitsuko's last words, Battle Royale

Evert

Member #794

November 2000

Quote:

Now, where I had left my touch...

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

ReyBrujo

Moderator

January 2001

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.

--
RB
光子「あたしただ…奪う側に回ろうと思っただけよ」
Mitsuko's last words, Battle Royale

Evert

Member #794

November 2000

Quote:

This wasn't fixed:

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

ReyBrujo

Moderator

January 2001

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

Watcom said:

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

--
RB
光子「あたしただ…奪う側に回ろうと思っただけよ」
Mitsuko's last words, Battle Royale

Peter Hull

Member #1,136

March 2001

What's with the Sticky L key?

Pete

Evert

Member #794

November 2000

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.

Ron Ofir

Member #2,357

May 2002

Isn't that the second time you do that?

Quote:

Evert Glebbeek fixed a bug that caused a crash when loading Allegro 1.x
datafiles containing 4 bit bitmaps.

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

Avenger

Member #4,550

April 2004

Quote:

Peter Wang removed the exdodgy example.

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

Thomas Harte

Member #33

April 2000

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

[My site] [Tetrominoes]

Edward Sheets

Member #4,734

June 2004

Quote:

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

---

Note: carving a pentagram on the top of a container of spoiled yogurt does not summon a yogurt demon. -Kikaru

Evert

Member #794

November 2000

Quote:

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

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.

Quote:

Thats all needed to get in to the credits:o.

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

Quote:

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

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.

Matthew Leverton

Supreme Loser

January 1999

Compiled fine on Mac OS X 10.4.

--
RTFM | Follow Me on Google+ | I know 10 people

Edward Sheets

Member #4,734

June 2004

Compiles here on WindowsXP without any trouble...

---

Note: carving a pentagram on the top of a container of spoiled yogurt does not summon a yogurt demon. -Kikaru

Peter Wang

Member #23

April 2000

Quote:

It's not credits, it's changes.

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

A J

Member #3,025

December 2002

edward Sheets; what compiler(s)?

___________________________
The more you talk, the more AJ is right. - ML

Hrvoje Ban

Member #4,537

April 2004

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

Evert

Member #794

November 2000

Quote:

I do think trivial changes (spelling, adding comments, etc.) don't need mentioning.

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 :-/

Thomas Harte

Member #33

April 2000

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

[My site] [Tetrominoes]

Evert

Member #794

November 2000

Quote:

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

1AL_INLINE(fixed, fixmul, (fixed x, fixed y),
2{
3   fixed sign = (x^y) & 0x80000000;
4   int mask_x = x >> 31;
5   int mask_y = y >> 31;
6   int mask_result = sign >> 31;
7   fixed result;
8 
9   x = (x^mask_x) - mask_x;
10   y = (y^mask_y) - mask_y;
11 
12   result = ((y >> 8)*(x >> 8) +
13             (((y >> 8)*(x&0xff)) >> 8) +
14             (((x >> 8)*(y&0xff)) >> 8));
15 
16   return (result^mask_result) - mask_result;
17})

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

Thomas Harte

Member #33

April 2000

Quote:

(Untested). Thomas, can you check if this does what it's actually supposed to do?

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.

Quote:

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.

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?

[My site] [Tetrominoes]

Evert

Member #794

November 2000

Thomas Harte said:

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:

Quote:

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

Robert Hightower

Member #5,830

May 2005

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

Quote:

gcc -s -o demo/demo.exe obj/djgpp/alleg/demo.o lib/djgpp/liballeg.a
lib/djgpp/liballeg.a(vbeafex.o):vbeafex.c:(.text+0x77f): undefined reference to `_int_ds'
lib/djgpp/liballeg.a(vbeafex.o):vbeafex.c:(.text+0x79c): undefined reference to `_int_ds'
lib/djgpp/liballeg.a(vbeafex.o):vbeafex.c:(.text+0x7a7): undefined reference to `_int_ds'
lib/djgpp/liballeg.a(vbeafex.o):vbeafex.c:(.text+0x7ce): undefined reference to `_int_ds'
collect2: ld returned 1 exit status
make.exe: *** [demo/demo.exe] Error 1

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.

Steve Apostol

Member #4,127

December 2003

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.