Allegro 4.2.0 RC2 has been released. SourceForge has the source packages, and binaries are available here.
If you build from source, please take note of two things
A last minute change to hline and vline created a lot of warning messages when compiling under MSVC. Just ignore those. It's already been taken care of.
If you use the .zip distribution for building under Linux, be sure to specify the new switch to enable dos to unix new line conversion. The old --quick parameter is now the default behavior.
The files:
Pre-built Packages
[/list]
Changes from 4.2.0 RC1 to 4.2.0 RC2 (August 2005)
Grady Martin made the grabber consider deleting object properties as a change to the datafile.
Milan Mimica fixed numerous bugs in extract_font_range().
Peter Hull moved the 'magic chdir' in the MacOS X port to earlier in the startup process, so that the config file will be looked for in the resource directory if is present.
Chris Robinson made create_bitmap(0,0) not return a bitmap that would later crash destroy_bitmap(). Zero-sized bitmaps are still not allowed so the assertions for debug mode have not changed.
Elias Pschernig patched the Windows keyboard driver to get key_shifts working again with KB_SHIFT_FLAG, KB_CTRL_FLAG, KB_ALT_FLAG on Win98.
Peter Wang changed hline and vline into aliases for internal symbols to avoid a conflict with the curses API. This change should be transparent for users.
Matthew Leverton and Michal Molhanec updated the build system for MSVC 8.
Grzegorz Adam Hankiewicz prevented make_relative_filename() from crashing with malformed parameters.
Hrvoje Ban made ASSERT() actually abort in Windows.
Chris Robinson made GUI menus work with gui_screen.
Evert Glebbeek fixed reading of 32 bit Windows .bmp files, which was not supported. These files seem to be not very standard though, so it's unclear if it will always do the right thing. Alpha channels also seem not to be standard in 32 bit BMP files, so it's possible they're not read in correctly.
Peter Wang and Peter Hull updated the ABI compatibility document. This documents our policy for the 4.2.x series.
Extensive documentation updates from Grzegorz Adam Hankiewicz and minor updates due to Michael Faerber, Robert Ohannessian and Milan Mimica.
Changes from 4.2.0 beta 4 to 4.2.0 RC1 (August 2005)
Peter Hull fixed the MacOS X port to avoid an issue with the dead bootstrap context and cleaned up the dock notification. This means command line apps (with SYSTEM_NONE) run without the dock being notified.
Peter Wang Added a COLORCONV_KEEP_ALPHA flag, as suggested by Gideon Weems.
Peter Wang fixed issues with OSS in OpenBSD and made the configure script print a warning if Allegro is compiled without X11 support.
Peter Hull set the compatibility version to 4.2.0 for MacOS X and added a MacOS X help file.
Peter Wang made the Mode-X and VBE/AF drivers fail if Allegro is compiled as a C-only library in Linux and made the Unix port install liballeg*.so and the alleg-*.so modules with the execute permission enabled.
Grady Martin standardised some of the grabber dialog boxes and added a `move' command to the grabber.
Evert Glebbeek fixed a bug when loading some old datafiles containing monochrome fonts.
Evert Glebbeek fixed a bug that prevented system cursors from working correctly in Windows.
Olivier Blin fixed compilation problems for the ModeX driver with newer binutils.
Shawn Walker fixed a bug in get_executable_name under some UNIX systems.
Shawn Walker worked around a problem with some versions of GNU AS and fixed some errors in the configure script when not using GCC.
Elias Pschernig made create_sample not unnecessarily clear the sample to 0.
Bobby Ferris fixed the makedoc SciTE API output.
Elias Pschernig fixed a too strict assert that prevented set_volume from working in debug mode.
Paavo Ahola helped fix a problem with BCC and the C implementations of fixmul.
Elias Pschernig fixed a cosmetic bug where the listbox was drawing a too big selection rectangle, reported by dthompson.
Documentation and example updates by Grzegorz Adam Hankiewicz, Peter Wang, Elias Pschernig Michal Molhanec and Evert Glebbeek.
Many thanks to all who contributed to this! 
Finally a new release!
But there will probably be at least a 4.2.0 RC3, because the new demo game isn't integrated in this release.
There was an RC1? 
Anyway, does anyone have a direct link to the source distribution? Sourceforge's main page seems to be down.
I think Beta 4 was RC1. In the Dev-C++ updater, it called Allegro "Allegro 4.2.0 RC1".
I think Beta 4 was RC1.
It wasn't. But one wonders why you would release a release candidate without telling anyone... (since the whole point of release candidates is testing)
downloading & testing (and YES, windows BMP file system is PAIN IN THE DONKEY !)
Compiled and tested it (MinGW, XP) now. The joystick bug is still there. Also, it seems that the button names are in the wrong order (this was the case the last time as well, alth I just didn't think about it then) - though this might conceivably be a driver issue.
(and YES, windows BMP file system is PAIN IN THE DONKEY !)
BMP is a file system now?
I didn't think BMPs could have alpha channels. That's PNG's job.
The RC1 was released internally in the AD mailing list after the beta4. This is the first public release candidate.
Compiled and tested with MSVC7.1 and Mingw (gcc 3.4.4 candidate) under WinXP. Mostly seems OK.
NOTE: I tried changing the parameters for the warn mode in MSVC7.1 (from -W3 -WX to -W4 -Wp64, enabling 64bit portability warnings). The results were, well, enlightening. Almost every file has at least one function the does assignment from a 64bit pointer to a 32bit integer (or worse 16bit). Most of these are inside macros, and so impossible to debug properly.
The most annoying ones (and possibly harmless) are in the draw.inl file. For example:
include\allegro\inline\draw.inl(535) : warning C4312: 'type cast' : conversion from 'unsigned int' to 'unsigned int *' of greater size
AL_INLINE(int, _getpixel32, (BITMAP *bmp, int x, int y),
{
uintptr_t addr;
int c;
bmp_select(bmp);
addr = bmp_read_line(bmp, y);
c = bmp_read32(addr+x*sizeof(int32_t));
bmp_unwrite_line(bmp);
return c;
}) // This is line 535. I think the problematic line is the assignment to c
There are 8 such warnings in draw.inl that will always appear when compiling an app with -Wp64, as allegro.h includes draw.inl. How to combat them? Just detect msvc and supress the warning in this file? That's what I do, but it seems like a hack.
=========================================================================
EDIT: In case anyone is interested I redirected the output of the WARNMODE=1 build for MSVC7.1, using the updated parameters, to the attached file. Most warnings come from the draw.inl file, but most others may be cause real problems. Take a look to see what I am talking about.
=========================================================================
The reason RC1 was not publicly announced was... we were too busy with SpeedHack.
We'll have to look into the 64-bit portability warnings.
Ahem... Anyone knows how to post news in the Gamedev site? I think this release should be announced. The more users that update to this, the easier it will be to find bugs before the final 4.2.0
The beta1 release was also announced, and it seems that many upgraded to it (or tried allegro out for the first time).
Ok, so I'm not the only one who missed RC1.
There's an "Add a News Item" button on the right, where the news section begins.
Oh! I had adblocked gifs for speed reasons, so it wouldn't display... 
I tested the source package and it seemed to work fine under Gentoo.
Gnolam :
BMP is a file system now?
No, but RC2 didn't give me a good english 
i was thinking of 'file format' ;-p
dthompson:
I didn't think BMPs could have alpha channels. That's PNG's job.
32 bit is always faiked. 32 bit is 24 color bits + 8 alpha bits.
So a 32 bit bitmap will have an alpha channel, as all 32bit picture format.
I think the bug they talk is more that some soft aren't filling the alpha channel, or fill it in some strange ways.
I didn't think BMPs could have alpha channels. That's PNG's job.
They have alpha support for years. I know that I implemented alpha support in a (java) bmp reading lib I coded about 4 years ago - and 4 computer years are like 40 human years ...
It wasn't. But one wonders why you would release a release candidate without telling anyone...
Just for the record: people on the mailing list, on IRC, and here were told, but it didn't make it on SF because people were either away on vacation or busy with SpeedHack.
Downloaded it and recompiled Rocket Duel, which seems to be working just as well after the upgrade from 4.0. 
A big thanks to those with the skill and motivation to work on things like Allegro! Without people like you, people like me probably wouldn't be making games.
It seems the guys at Gamedev do not like the news . If anyone cares, do try to make a post about the Allegro release.
It's on the front page...
Almost every file has at least one function the does assignment from a 64bit pointer to a 32bit integer (or worse 16bit).
Not really. Allegro uses C99 typedefs (eg. uintptr_t; an unsigned integer capable of holding a pointer value) where available for this. On systems that don't have the typedefs, Allegro has to assume a 32-bit target. Since Microsoft doesn't want to follow the C99 standard, it's their own fault for not supplying comparible typedefs.
What do the references to uintptr_t here mean?
Interesting. I don't believe Allegro uses them in MSVC. Figures that they couldn't use stdint.h like the standard says. Someone should update Allegro's VC headers for them before 4.2. What VC version are they in?
MSVC 6
MSVC 7 (.NET)
MSVC 7.1 (.NET 2003)
MSVC 8 (.NET 2005)
Only the intptr types? 
Can't make anything easy, can they..
All of the <u>int*_t types are automatically defined (except for 64 bit). No include file, from my experience. From a project that uses all the integer typedefs, here's some code:
//typedef __int8 int8_t; //typedef unsigned __int8 uint8_t; //typedef __int16 int16_t; //typedef unsigned __int16 uint16_t; //typedef __int32 int32_t; //typedef unsigned __int32 uint32_t; typedef __int64 int64_t; typedef unsigned __int64 uint64_t;
That is, I used to have all of them defined, but I commented them out when I last used this code. Perhaps because I got a newer version fo the compiler. You'll have to do more research.
Just a quick remark on the missing public RC1. I uploaded the files the evening before going on vacation but didn't announce the release because we wanted to have binary releases too. A few bugs showed up, and since these were fixed or had patches waiting by the time I got back, I didn't see much point in bringing out RC1 with known problems.
In the mean time, I'm having fun at a workshop in Chicago. Thanks to Matthew ands Peter for taking care of this baby!
For the first time, we also have a Mac OSX binary installer. This will install
The Allegro library in normal, debug, profile and normal-static link versions
The grabber, dat and fixbundle tools
The help in Apple help-book format
If you are able, please try it out as I would welcome feedback.
OSX Installer (2.4MB)
Pete
Suggestion: for the msvc binaries at any rate, could someone include the .pdb symbol files with the binaries? That would be hugely helpful...
I assume alld42.pdb is the only one needed?
actually, it would be nice to have both. Last night, I was hitting a crash while using the release lib... just makes it easier to pull up source when a problem occurs.
(BTW, the problem was nothing to do with Allegro, just a linking conflict between one component using debug vs another using release)
I tried out the 4.2.0 rc2 yesterday, on win32/msvc. Mainly hoping for a "working" mouse speed setting. (Some guy was able to emulate my game on linux properly except for a super sensitive mouse behaviour). Am I right when concluding it has not been fixed? The mouse sensivity remained the same.
void set_mouse_speed(int xspeed, int yspeed);
Sets the mouse speed. Larger values of xspeed and yspeed represent slower mouse movement: the default for both is 2.
The game compiled and played fine mostly. Some Dialog drawing routines seemed a little messed up. I did not manage to fix these issues yesterday. But that could be caused by the tweaked dialog routines inside my game's libraries.
For now I just retained my 4.0.3 installation.
This is probably a stupid question, but how do you avoid these errors when including <allegro.h> in a cpp file?
C:\app\vs\VC98\INCLUDE\allegro/inline/draw.inl(67) : error C2562: 'vline' : 'void' function returning a value
C:\app\vs\VC98\INCLUDE\allegro/inline/draw.inl(67) : see declaration of 'vline'
Thanks,
Steve
Ok, it was stupid. I guess this is the solution:
#define ALLEGRO_NO_VHLINE_ALIAS
#include <allegro.h>
Those have already been fixed in CVS.
So... Now I can just use a package with MSVC 6.0 and it should work ?
man this is great..
I could use a decent IDE and debugger(MSVC) or I could use allegro and DEV-C++
so nog I can use Allegro AND MSVC .. great 
Just to let you down:
It is possible that MSVC support will be dropped in the next major release (4.3.0)
Vote against, if anyone asks you.
MSVC support won't be droppped, although version 6 won't work if C99 is used.
You can either upgrade your command line tools (for free) and use them with the MSVC 6 IDE or download the (currently) free VC++ Express version, which contains a fully optimizing compiler.
It is possible that MSVC support will be dropped in the next major release (4.3.0)
No way. I'd personally love to drop active support for compilers that don't support C99 (and that includes all versions of MSVC), but dropping support for MSVC is just out of the question.
It's not that I like microsoft so much .. It's I like having a debugger
just try debugging in Dev-C++
by the way .. MSVC moans about this
| 1 | bool Comp(const TSprite *v1, const TSprite *v2); |
| 2 | |
| 3 | |
| 4 | void TEngine::draw() |
| 5 | { |
| 6 | draw_stars(); |
| 7 | |
| 8 | zero_sound=false; |
| 9 | items.sort(Comp); |
| 10 | list<TSprite *>::iterator p=items.begin(); |
| 11 | while (p!=items.end()) |
| 12 | { |
| 13 | TSprite*hulp=*p; |
| 14 | hulp->draw(x,y,vscr); |
| 15 | p++; |
| 16 | } |
| 17 | |
| 18 | } |
| 19 | |
| 20 | bool Comp(const TSprite *v1, const TSprite *v2) |
| 21 | { |
| 22 | return (v1->z < v2->z); |
| 23 | } |
it's my Z_sort code in Dev-C++ it worked fine
Evert: I can't say I understand you. You'd like to drop it, but it wont happen? Or is the active crucial here?
There are things which would make maintanance easier, so we would like to do them. But we can't. MSVC support is one of them It definitely never was planned to drop support for MSVC > 6. MSVC-6 (as well as gcc 2.95) probably won't be able to compile future Allegro code, as well as any other sane open source project's code I believe. 4.2.0 should support both though.
No way. I'd personally love to drop active support for compilers that don't support C99 (and that includes all versions of MSVC), but dropping support for MSVC is just out of the question.
Evert: I can't say I understand you. You'd like to drop it, but it wont happen? Or is the active crucial here?
Milan: the problem is that, whether we like it or not, MSVC is basically the industry standard development tool for anything windows related. Dumping MSVC support would be, basically, committing library suicide. So, we'll have to be very careful if we ever do decided to dump support for MSVC. Frankly, I don't think we are ready to dump it quite yet. (4.3? We will see...)
I can't say I understand you. You'd like to drop it, but it wont happen? Or is the active crucial here?
I'd like to drop active support, which means not doing anything in particular to make sure it compiles with MSVC. Not doing that means that it will probably get broken, but not nescessarily. Sticking to a well-defined standard should make the code work on all compilers that support that standard, but in practice it doesn't always work that way.
So while I'd personally like to say `here's our code, try if it works in MSVC, if it doesn't, tough', that won't happen.
It's not a matter of dumping support for MSVC, but MSVC dumping support for C. At the rate MSVC is deprecating standard C features, it won't be too surprising to see it drop C completely.
While some parts of C99 are nice, I don't think it's worth it to switch to it yet. What is gained is trivial to losing a large audience. I believe a language switch to C99 would have to be an Allegro 5 thing. Because by that time Microsoft probably will only be in the C# business anyway.
What is gained is trivial to losing a large audience.
Yes, I agree.
Crap. I use MSVC 6. 
:strokes it:
Thanks guys!!
It's not a matter of dumping support for MSVC, but MSVC dumping support for C. At the rate MSVC is deprecating standard C features, it won't be too surprising to see it drop C completely.
While some parts of C99 are nice, I don't think it's worth it to switch to it yet. What is gained is trivial to losing a large audience. I believe a language switch to C99 would have to be an Allegro 5 thing. Because by that time Microsoft probably will only be in the C# business anyway.
hum by that time someone should make a opensource IDE for GCC/MingW with an integrated debugger and code completion..
hum by that time someone should make a opensource IDE for GCC/MingW with an integrated debugger and code completion..
MinGW Developer Studio, not perfect but nice. I tried it maybe a year ago. The debugger is very much like the one in Visual Studio and the source editor uses Scintilla.
Hello,
I lately downloaded the new Allegro release and while installing I came across the build instructions Setting up Dev-C++ to build Allegro.
There is to read:
Get the DirectX SDK: go to Tools\Check for Updates/Packages... and install the DirectX package. Close Dev-C++.
First, there is no such file for download in the packages
[EDIT]
There are some licensing issues about distributing DX through DevPacks.(DEV-C++ forums)
[edited]
and second would it be helpful if there is the indication
Get the minimal DirectX 7 SDK for MinGW (dx70_mgw.zip). You download it from 'http://alleg.sourceforge.net/wip.html'.
like it was in the 4.0.3. build instruction.
Its mentioned in the previous chapter Setting up MinGW to build Allegro but who reads the whole sheet?
I didnt, but remembered the 4.0.3 installation. But, if someone is new and works read word for word and do exact what is written there perhaps will be despair.???
And a small matter concerning the manual. There is under Palette routines the paragraph where its explained that Allegro accept the spelling pallete. But that isnt true anymore!;)
Finally I wish to thank all participants of the Allegro-Project for this great work!:D
K.-W. Haase
hum you don't neet all that..
go here : http://devpaks.org/
and save yourself a LOT of trouble