{"name":"611898","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/b\/b\/bb5e43b061b96236cd5a2dd22beab35c.png","w":532,"h":696,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/b\/b\/bb5e43b061b96236cd5a2dd22beab35c"}

Hard to believe this, but Allegro 4 is getting a new release! This is mostly bugfixes accumulated over the past 8(!) years. You can download it from GitHub downloads.

Changes from 4.4.3 to 4.4.3.1 (March 2019)

• Fix a regression with the dat tool not working with plugins (SiegeLord).

Changes from 4.4.2 to 4.4.3 (February 2019)

• Allow building the dependencies as shared libraries. (Michał Cichoń, Edgar Reynaldo)

• Fix typo preventing get_executable_name from using System V procfs correctly. (Peter Wang)

• Relicense loadpng under ZLib license.

• Fix spelling of endianness in textconv (Andreas Rönnquist).

• Fix format string warnings (Andreas Rönnquist).

• Add Linux console tslib mouse "touch screen" driver. (Tobi Vollebregt)

• Don't define a duplicate DLLMain. (SiegeLord)

• Fix Allegro crashes/compilation under 64 bit Windows. (Sven Eden, David Capello)

• Fix possible random crashes on Windows restoring DirectDraw surfaces. (David Capello)

• Make internal function get_value in jpgalleg static. (Trent Gamblin)

• Implemented load_midi_pf, play_fli_pf, open_fli_pf. (Ivan Mogilko)

• Make use of <stdint.h> in MSVS 2010 and higher. (Ivan Mogilko)

• Fixes several issues related to fullscreen mode in Windows. (Etienne Vouga)

• Windows: fixed TAB key getting stuck in key buffer when held before ALT. (Ivan Mogilko)

• Fix building with Mesa 18.2.5 and later. (Andreas Rönnquist)

• Remove f* variants of fixed math functions. (Andreas Rönnquist)

• Fix complilation of datedit. (rofl0r)

• Modernize and fix release zipup script. (rofl0r)

SHA256 SUMS:

67981ff3e1dcc785c3cde93e07200f319ff85ab47c33752c03dcbd4b7e818022  allegro-4.4.3.7z
1e096e435e49e2dfd924d9c54ed7325caa1b06cecd28c3307146dd0de3d0bcb4  allegro-4.4.3.tar.gz
2740f951dfc6a7d2ca8fdec808042c899d742e1a04d5571abe60ea5debc1797f  allegro-4.4.3.zip
3b471b2db278c5c0e84b6f285c4280d937c5eb762559c368a10529affc4eff57  allegro-4.4.3.1.7z
ec19dbc9a021244582b4819b3583ee594b50141f9fcf6944a4ed8069cbf8d4d4  allegro-4.4.3.1.tar.gz
8d1e716a9b6f74fa44b801fb84a63432f74ea9178c219584c3d10793a9fb4520  allegro-4.4.3.1.zip

I had to check to make sure it wasn't April 1st...

also, great picture

Any chance we can get a C++ Allegro 4 with OpenGL and Kinect support???

@Seige Lord

I'll push our fix for the keyboard input race condition, if you'll accept it into the build. It corrects an issue on Windows where input becomes frozen based on allegro games being left runing for an extensive time.

The patch is here, if you want to review it:
https://github.com/ArmageddonGames/allegro5

Branch: 4.4-ZCFixes

Did anyone look at OSX 64b compilation, and is Linux 64b safe now, too?

It would also be nice to see precompiled libs for each platform made available with the release. A set of precompiled bins would always be helpful, at least for gccon OSX and Linux.

Windows, you'd need MinGW and MSVC bins.

We have someone (in theory) going through ag4.4 on OSX and fixing its deps. Quicktime.library is deprecated, and IDK what's happened with Quartz over the last few years.

Perhaps in a year or so, we can get some momentum on Allegro Legacy and turn it into 4.5. (IDR if you used that version designation before shifting the primary digit to 5.xx.)

Very good. I put in a pull request.

Looks like we need to rebuild for MSVC in order for our static lib to be current with your latest fixes.

I'm unsure about this commit, though, as I recall this having been fixed in the past:

We have not encountered this since shifting to 4.4.2. Good to know that there was another fix, though. Perhaps the KB mutex also solved it. IDK.

Did someone test it in DOS?

Yeah, I think we can finally wave goodbye to 32bit. I thought about messing around with my next project and making it 100% 64bit, never done that before.

I was going to build this for DOS, just for shits and giggles, but I realized this version uses CMAKE instead of the trusty old fix.bat files.

And I am not THAT interested in messing around with DOS!

Than I honestly don't see any reason to even bother with it. DOS nostalgia is on the rise lately, check out the MS-DOS Gaming page (https://www.facebook.com/groups/2209352733/) on Facebook sometime! There's a surge in people buying old hardware to build DOS machines again. The cost of older hardware is going up in fact because of this.

As much as DOS has been long gone, I still see Allegro 4 as part of that era and seeing as how an update to it like this is rare and not expected at all, I don't see why support should have been dropped when we have Allegro 5 for newer things.

I do have 4.2 around here somewhere. Thinking about messing around with it and DOSBOX for kicks. Heck, there are people making money selling new games made for old platforms like the C64 and DOS, if you follow The 8-bit Guy on Youtube, he is. It's quite interesting.

I've released 4.4.3.1, which fixes the dat tool which was broken by the 4.4.3 release.

Does it work on Windows 10?

I will deadass consider moving back to 4 just to simplify my life.

I honestly don't understand how this is still a thing. I mean, there's some boilerplate that is silly in retrospect but it's fairly small!

Like manually having to attach timers to a queue instead of having a starter queue and attach them to it by default (who would ever use the timer addon but NOT timers?), having to init all kinds of addons (who uses allegro 5 but DOESN'T use the primitive library? If I needed that savings I'd just rip out the code myself.) (But SDL is full of that crap too, which I bring up because it's a very popular alternative and nobody complains enough to not use SDL.) Allegro 5's API suffers from over-generalization instead of "optimize for the most common case." But it's FAR FROM TERRIBLE.

Either way, once you either write an Allegro 5 program out 10 times, or make a starter template with the code, you remember the boilerplate gotchas and coding is not bad at all. I just fork a previous project of mine, grab the setup bits, and move on. The only annoying thing is that I have to provide a font instead of using the default "FONT" but I started just giving it a path to a Linux system font (instead of packaging it myself) and I'm fine now.

The act of actually making the games is far harder than anything Allegro related. Make an OpenGL / GLEW application (read an old NeHe tutorial!) and you will recoil in horror at the complexity of just getting a triangle on the screen with all the windows messaging, device context, graphics context, opengl context (all separate!) boilerplate crap.

http://nehe.gamedev.net/tutorial/creating_an_opengl_window_(win32)/13001/ <--This isn't even a triangle yet, it's JUST the window! The triangle comes in the next tutorial in the series! And, NeHe tutorials are horribly outdated and the proper way of vertex buffers, display lists, and such are even more complex.

Most of what you see there is standard boilerplate Windows code you will see for ANY windows app. That's not OpenGL for the most part and you don't have to memorize most of it. I done this myself, with Windows, you can pretty much copy and paste most of that code for just about every project you make. Heck, make a function, throw most of that code into it with a couple parameters for changing minor things and you can reuse it in every project you make pretty much.

While NeHe is outdated, I didn't see the old way as complex at all. I learned OpenGL and done my own 3D program with it using straight Windows code + OpenGL, with display lists which I found really fast, at least for the time.

Here's some simple code I used to create a display list using the older immediate mode:

GLuint listSkybox = glGenLists(1);
glNewList(listSkybox, GL_COMPILE);

// insert code to draw skybox here

glEndList();

That's it!

After this, you simply call glCallList(listSkybox); to draw the skybox whenever you wish to draw that object. I don't know how you see that as complex. If you find that complex, stick to 2D as shaders will really confuse you. And don't even think of looking at Vulcan which forces you to do EVERYTHING which is insane (powerful, but... it makes that Windows code you hated look like a walk in the park in comparison).

I may try doing things with just straight Windows code + OpenGL again, only this time with modern opengl shaders.

Agreed, GREAT site for learning modern opengl properly. It's where I learned to make this (video of some code I learned from that site and have added to since)...

I think the main problem is that many libraries we use do all this for us so we become accustomed to not having to do much, which can be really misleading. There's a lot that is important in the Windows code that needs to be done. Much of it allows you to adjust absolutely everything. Most of the time we don't need to, but it is important and your opinion of it probably underscores the problems with libraries simplifying things so much without understanding what is going on under the hood.

This is why I programmed some stuff where I vowed not to use any libraries, just Windows code + opengl and I was able to do it all and gained a good understanding of how Windows works.

The windows boilerplate is pretty simple honestly. You can create functions which you will never have to touch again. In fact, NEHE created a header which has some functions for setting up all the Windows stuff, you just include it and then call his functions and you never have to look at that Windows code again.

It reminds me a little of OpenGL shaders which has a lot of boilerplate code which you can reuse once you coded it once. All you need to do is program your code to load and compile your shaders then shove them into reusable function and you never have to program that code again. I think some libraries have functions to load and compile shaders for you.

Speaking of modern opengl shaders, I found a great siggraph video explaining how to do them for the beginner, it's a really good talk, going to watch it a couple times I think.