Allegro 4.4.2 released
Peter Wang

The anticipation has been intense.

http://sourceforge.net/projects/alleg/files/allegro/4.4.2/

Quote:

==================================================================
============ Changes from 4.4.1.1 to 4.4.2 (May 2011) ============
==================================================================

Make rest(0) call select() with non-zero timeout on Unix. The old
implementation was no longer enough to make input responsive on X11,
on programs which try to draw as fast as possible. (Peter Wang)

Fix module loading on Unix (Bernhard Rosenkraenzer).

Made memory bitmaps returned by create_system_bitmap not marked as system
bitmaps (Edgar Reynaldo).

Add detection of Windows 7 (Andrei Ellman).

Fail instead of crashing if gfx_directx_make_bitmap_from_surface() fails
(Andrei Ellman).

Fix crash in GDI driver if setting a second mode fails, after having
successfully set a mode previously (Andrei Ellman).

Add missing frameworks required for static linking on OS X (Peter Johansson).

Fixed a problem with keyboard focus being lost on OS X when switching from
windowed mode to fullscreen mode (Peter Johansson).

alsa_rawmidi_init could return success on failure (Nicolas Kaiser).

Updated PSP port from diedel. "The graphics, system, digi, keyboard, mouse,
joystick and timer drivers are implemented and are fully functional. It
supports 8, 15, 16 and 32 bpp color depths and a max. resolution of 480x272
pixels."

Eliminated the need for old DirectX headers for the Windows port
(David Capello).

Fix problems in Windows when you use Alt-Tab. Sometimes the Alt modifier is
kept pressed when you focus the Allegro window. (David Capello)

Make the submenu appear to the right of its parent menu if it does not fit
in the screen (Paul Suntsov).

Made timers on Unix cope with system time being set backwards
(Hardi Stengelin).

Fix various compilation and build problems (scottmc, Cristian Morales Vega,
Tony Ylisirniö, Edgar Reynaldo).

Added WANT_OSS, WANT_ALSA, WANT_JACK, WANT_SGIAUDIO options
(Samuli Suominen).

Also pass -pg when building shared library in PROFILE mode.

Let demos find readme.txt and source files correctly even if running from a
build directory (Peter Wang).

Neil Walker

Well done all involved.

But you're flogging a dead horse. Allegro 5 is the future. Let's hope it doesn't take as long to drop A4 as it did to get rid of DOS from Allegro (I remember those heated debates on why DOS is important....)

Trent Gamblin

There was a decision to remove DOS? My understanding was that it would remain as long as someone maintained it.

Neil Walker

That attitude will never win you a Nobel.

Todd Cope

But you're flogging a dead horse.

I disagree. I have many old projects that I will never have time to port to A5. This update is much appreciated. I think everyone is already recommending A5 to new Allegro users.

Arthur Kalliokoski

{"name":"dead+horse.gif","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/8\/08fc75d40a970fe434b2f8283160ddd1.gif","w":300,"h":232,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/8\/08fc75d40a970fe434b2f8283160ddd1"}dead+horse.gif

Thomas Fjellstrom

Looks a little like something out of Monty Python's Flying Circus. If so, I approve.

That said, I don't think continuing to support A4 is like beating a dead horse. This release is part of the original plan, to do occasional bug fix releases. People have submitted bugs, and bug fixes, why shouldn't we include them in a release at some point? Clearly it means people are still using it, and want to keep using it for some projects. Dropping A4 on its ass with no support what so ever would be incredibly short-sighted, and a good way to get people to just stop using any version of Allegro.

AMCerasoli

I got to be honest with you guys... This is the unique library/software/PC-version/Car-Model/etc..etc..

That has a version 5 and still doing things for 4... I don't get it!!!. What it's happening I mean everything goes, 1, 2, 3, 4... etc.. or 0.1, 0.2, 0.4... It's like there is some kind of ramification, something like a 4 Dimension in the world of Allegro.

Why it jumps from 4.4.2 to 5.0.0? where are 4.6.0 and 4.8.0? I know that I asked this before and I think it made sense that time... But know I'm confused again... :-X

PS: Imagine a new Service Pack for Windows 95.

Thomas Fjellstrom

Why it jumps from 4.4.2 to 5.0.0?

Version 5 is completely separate from anything that came before. Allegro 4 will continue to receive bug fixes till we all get bored of it. While Allegro 5 is where all the new fancyness is added.

MS is still releasing occasional patches for XP afaik. And they have Vista, Windows 7 out, and Windows 8 on the way. It's not much different from that.

The linux kernel community is currently supporting like 10 different stable and longterm releases of the linux kernel. Just because you release a new version, doesn't mean you stop supporting the old one right away.

kenmasters1976

I am glad to see a new Allegro 4.4 release. Downloading.

Evert

There was a decision to remove DOS? My understanding was that it would remain as long as someone maintained it.

Yup.

Trent Gamblin

Which, time permitting, I plan to do. Starting with getting the thing fully running including the addons if possible (AllegroGL may be difficult).

AMCerasoli

So actually there is a jump?

What would happen if for example I say: Allegro 4 it's better let's still making new patches and adding new stuffs... You know imagine that suddenly Edgar it's multiplied by 100 so there are 100 guys doing new patches and adding new stuff to allergo 4 and from 4.4.2 start growing 4.4.2, 4.4.4, 4.4.6 ... 4.6, 4.8, 5... then there would be two version of allegro with the same number version?

I didn't know that Allegro 4 had PSP port.

MS is still releasing occasional patches for XP afaik.

How can we diferenciate when it's a patch or a new version?

I mean, when you say a new SP for windows XP I know that it's a pack to resolve old problems of Windows XP, I won't see in a Service Pack for XP the new DirectX 11... or support for Multiple touch screens, right?

I don't know is very weird, it's like you're mixing the name with the version... For example should be: Allegro 4 v4.4.2, then would be more understandable... I think that was my problem.

Now we have Allegro 5, and doesn't should be Allegro 5 v0.0.1... Ohhh I think now I get it, you're mixing the name with the version in some kind of abbreviation, like Windows 95.0.4 where 95 is the name and 0.4 is the version... Right?

Matthew Leverton

4.10.0 comes after 4.8.0.

Thomas Fjellstrom

The intention is for Allegro 4 to eventually go away. Most pf the changes in the new A4 release we're contributed by users. The current dev team is not that interesed in workin with the old codebase any longer, at least not more than is absolutely necessary.

im sure others are welcome to pick up Allegro 4 development if they wish, but i find that unlikely to happen. It just doesnt support many things people want, and would be hard to add to the code without making a serious mess.

kenmasters1976

I agree that Allegro 4 should be deprecated in favor of Allegro 5 but if someone is willing to do some maintainance for people still using it, I say that's fine.

AllegroGL may be difficult

I got AllegroGL working on Allegro 4.2 for DOS a while back. I'm guessing Allegro 4.4 and Allegro 4.2 share a lot in common so it shouldn't be difficult given that you have the Mesa lib installed (an old, no longer maintained DOS version), which is the hard part.
Anyway, I don't think anyone will complain if AllegroGL is disabled on DOS.

Trent Gamblin

I heard something about a linux framebuffer driver that does opengl or something like that, directfb maybe? And mesa supports it on Matrox cards... well I have a Matrox card so I might be able to get that working too. All of this will be a side project though, stuff to do when I'm burnt out from my other work.

Edgar Reynaldo

Is Michael Cichon around anywhere? I'd love it if you would make a build script for making Allegro 4 binaries to put on the Allegro.cc files page. ;D I wouldn't personally use them, but it would make it much easier for all the newbies.

Yodhe23

Well done everyone, nice job.

Michał Cichoń
Edgar Reynaldo

Awesome! Many thanks Michal! ;)

Michał Cichoń

I just got first successful build of A4 with addons:

allegro-4.4.2-monolith-mt-debug.dll
allegro-4.4.2-mt-debug.dll
allegrogl-0.4.4-mt.dll
allegrogl-0.4.4-mt-debug.dll
jpgalleg-2.6-mt-debug.dll
loadpng-1.5-mt-debug.dll
logg-1.0-mt-debug.dll

More, A4 can be build as monolith, with all addons integrated. Wish me luck!

Edgar Reynaldo

Michal, one question - will the A4 binaries have different names than the ones built from source with cmake? Should the output from cmake be adjusted to match your naming convention?

Michał Cichoń

Well, this issue hasn't been discussed yet. I alone cannot make such decision.

Current naming scheme is a consequence of using my build scripts, where I have to differentiate between binaries.

Binary name is fully descriptive to help to identify very specific version. Not once I did hit the problem when an executable required alleg42.dll, then I found one on the HDD and application didn't work, because versions were binary incompatible. So, it is better at least for me to know explicitly what binary is required to run my application.

Do you think people will accept mine naming scheme?

A side note about origins of current name of Allegro binary: alleg42.dll. I used Allegro in 199x where DOS was in store and file named allegro-4.2.dll wasn't possible, because names were limited to 8 characters and extension to 3 characters.
I'm not convenient about that, but it looks like A4.4 does not support DOS any more. Well not directly, sources are still there but CMake does not handle them.

GullRaDriel

Awesome, thanks to all the contributors !!

Michał Cichoń

OK. Complete Allegro 4.4 build. You will find links at the end of this post. They are very same like in the post above, archive files were updated.

What changed:
- main library is compiled in the A5 fashion
- jpgalleg, loadpng, logg were updated and build as DLL's
- monolith build was introduced, which mean all addons are integrated with main library

allegro-4.4.2-mingw-3.4.5.7z
allegro-4.4.2-mingw-4.2.1-sjlj.7z
allegro-4.4.2-mingw-4.4.0.7z
allegro-4.4.2-mingw-4.5.0.7z
allegro-4.4.2-mingw-4.5.2.7z
allegro-4.4.2-msvc-10.0.7z
allegro-4.4.2-msvc-8.0.7z
allegro-4.4.2-msvc-9.0.7z

Evert

Should the output from cmake be adjusted to match your naming convention?

The other way around, I would say...

Edgar Reynaldo

That would be fine too. The output from cmake is a little inconsistent currently though, as the release static version is named liballeg.a but the debug and profile static versions both have a -static suffix.

@Michal
I can't seem to get a test program to build when linking to the liballegro-4.4.2-monolith-mt.a library. It keeps giving me undefined references to allegro functions. It works fine when I use liballegro-4.4.2-mt.a though.

Something odd - liballegro-4.4.2-monolith-mt.a is 1160KB and is smaller than liballegro-4.4.2-mt.a, which is 1334KB. That doesn't seem right?

Is the liballegro-4.4.2-monolith-mt.a library a static library?

Matthew Leverton
Evert said:

The other way around, I would say...

Allegro's naming convention is not verbose enough for distributing multiple binary versions (different Allegro versions, different compilers, monolithic builds, etc) of the libraries.

I don't see any problem with the two not being the same. If a person is unable to follow a tutorial because the file names aren't exactly the same, then he just needs to get a bit smarter.

Evert

I don't see any problem with the two not being the same. If a person is unable to follow a tutorial because the file names aren't exactly the same, then he just needs to get a bit smarter.

True.
I was mostly thinking of DLLs, but then, back when I used Windows, it was still common practice to keep all DLLs in one place. I think that's changed now, and you're supposed to keep them with the executable?
For static libraries, it really doesn't matter either way...

Arthur Kalliokoski
Evert said:

it was still common practice to keep all DLLs in one place. I think that's changed now, and you're supposed to keep them with the executable?

I think it was to prevent crackers from installing their DLL's into system folders, so you need to keep your DLL in your own directory where you have write access. Of course crackers can still do that too...

Edgar Reynaldo

Don't you guys think it is a little unconventional to have cmake produce libraries named differently than the pre built binaries? Otherwise in the docs and tutorials you have to have two different sections to cover linking both ways. No reason to add more confusion to the mix.

Michał Cichoń

I can't seem to get a test program to build when linking to the liballegro-4.4.2-monolith-mt.a library. It keeps giving me undefined references to allegro functions. It works fine when I use liballegro-4.4.2-mt.a though.

Something odd - liballegro-4.4.2-monolith-mt.a is 1160KB and is smaller than liballegro-4.4.2-mt.a, which is 1334KB.

That doesn't seem right? Is the liballegro-4.4.2-monolith-mt.a library a static library?

You're correct, monolith builds does not have symbols properly exported. I will look at the issue. Sorry, that is entirely my fault.

Peter Wang

I'm not so much worried about tutorials as breaking makefiles.

Edgar Reynaldo

@Michal
What is your method to name the libraries - ie... are you passing the names as Cmake parameters?

Michał Cichoń

I'm not using CMake. I have a script which generate Code::Blocks projects. That's where my binaries comes from.

Edgar Reynaldo

Okay then, that's fine. Well, I guess we can make tutorials that cover linking to the binaries produced by Cmake as well as the binaries produced by your projects.

Any chance of making a static monolith library for Allegro 4.4? That would be really nice.

Michał Cichoń

Yes, there will be static monolith library of A4.4. Right now I'm fighting with GCC 3.4.5 misfeature. When I solve that, I will produce new packages.

Edgar Reynaldo

Sounds good. Thanks for working on this.

Andrei Ellman

Personally, I'll be using Allegro 4.x for a while. This is because the project I'm working on relies a lot on paletted modes and MIDI which are not supported by A5, so I'm glad 4.x is still being maintained. But I will of course consider 5.x for future projects.

Last I heard, 4.4.x does not work on DOS but 4.2.x does. IIRC this involved an issue with draw_sprite_ex() which could not be resolved using just C code alone, and none of the devs were willing to delve into the world of machine-code haxx0ring. Back in 1997 when I was working on AllegroPak, I hacked my own machine-code versions of the various sprite-drawing functions (so I could add Z-buffering functionality), so I have some experience with the DOS machine-code. But alas, it's unlikely I'll have any time in the near future to look into this. Also, I seem to remember that someone was having an issue getting LOGG to work with DOS, but I recently managed to compile and run the LOGG test-programs in DOS so I couldn't find any issues with LOGG on DOS. Were there any other issues with DOS support on 4.4.x?

AE.

PS. Does anyone think we should rename the Allegro 4.x branch to "Allegro Classic"?

Matthew Leverton

Does anyone think we should rename the Allegro 4.x branch to "Allegro Classic"?

Only if we name series 5 "Allegro Pro."

Thomas Fjellstrom

Last I heard, 4.4.x does not work on DOS but 4.2.x does. IIRC this involved an issue with draw_sprite_ex() which could not be resolved using just C code alone, and none of the devs were willing to delve into the world of machine-code haxx0ring.

I think the issue is that no-one wants to touch the old crusty ASM anymore. And the DOS port is filled with it. Even its own calling convention.

Michał Cichoń

Edgar, try it now. This build should work.

Again, archives were replaced with new ones. This time symbols were exported with explicitly generated definition file. So all should be there.

allegro-4.4.2-mingw-3.4.5.7z
allegro-4.4.2-mingw-4.2.1-sjlj.7z
allegro-4.4.2-mingw-4.4.0.7z
allegro-4.4.2-mingw-4.5.0.7z
allegro-4.4.2-mingw-4.5.2.7z
allegro-4.4.2-msvc-10.0.7z
allegro-4.4.2-msvc-8.0.7z
allegro-4.4.2-msvc-9.0.7z

Edgar Reynaldo

Linking a simple test program with liballegro-4.4.2-monolith-mt.a works correctly now. I'll see about testing some more tomorrow.

Thanks Michal!

Larkin

Appreciate your efforts to improve allegro4. I will use it for a while with my old projects.

Edgar Reynaldo

Hey Mr. Leverton, do you think the binaries are ready to be put up on the files page?

Larkin
Quote:

Eliminated the need for old DirectX headers for the Windows port

How was this achieved ? No more need to deploy dx70_min.zip ?

Thread #607371. Printed from Allegro.cc