Allegro.cc - Online Community
Post Reply

Allegro.cc Forums » Allegro Development » Allegro 4 is not dead

rss feed Print
Allegro 4 is not dead
Marek Ratajczak
Member #18,974
December 2020

Dear Allegro Users,
Just short notice:
If someone needs Allegro 4 working with 64bit applications for Windows (unfortunately just for Windows at the very moment), please let me know.
The story is, I tried to migrate to Allegro 5 with my project, actually with some effort I did, but I got stuck with the lack of "infrastructure" in Allegro 5 to get what I need, especially direct drawing on the screen, XOR mode and in general - problems with primitives. I'm not creating games, I'm doing CAD, and that's the main problem. So I came back to Allegro 4, and with some changes what I needed to do, I got it working in 64bit, however just on Windows, and with (for my project most important) GDI architecture, what is mostly useful for me, and is really fast, thanks to some hardware support made by Microsoft for that.
Here is a link to the project, so if someone has some similar needs, please let me know, I will be happy to help.

alfacad.net

In the same time I'm searching for similar solution for another platform, what is Mac OSX, which seems to be much more tricky, due to changes in Apple system, especially migrating from Intel to M1. But maybe one day it will be possible, if not only me would care about such a good API as Allegro 4 really is.
I slightly modified version 4.4.3 to get it working with 64bit application.
I would be happy to share my experience.

Regards,
Marek

Edit:
Here is a link:

https://github.com/markremark1/Allegro-4.4.3.1-64bit-MSVC.git

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

Marek, that's awesome that you got Allegro to build in a 64 bit environment. It was never made compatible with 64 bit, as it was back in 32 bit days, but I'm glad you got it working.

It would be nice if you could submit a Pull Request with your changes to github.

amarillion
Member #940
January 2001
avatar

Yes, please share your changes if you can! I'm sure there are more old allegro 4 games that could benefit from this

--
Martijn van Iersel | My Blog | Sin & Cos | Food Chain Farm | Support TINS

GullRaDriel
Member #3,861
September 2003
avatar

Awesome work. It may please some users who prefer A4.
As Edgar said, PR so maybe other people are going to help / test / port.

"Code is like shit - it only smells if it is not yours"
Allegro Wiki, full of examples and articles !!

Marek Ratajczak
Member #18,974
December 2020

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

Marek, how extensive are your changes? Can you fork allegro, repeat your changes, and make a pull request on github? Your changes are based off of Allegro 4.4.3.1 git, correct? Perhaps we can just make a big diff and see if the patch works.

Marek Ratajczak
Member #18,974
December 2020

Edgar,
There are not substantial changes, just couple of files. Maybe also important part is setup of MSVC project to get it 64bit, but maybe not that hard to setup another compiler.
I'm not a hero in GitHub, so let me learn first how to do that what you request for. That's correct, it's based on 4.4.3.1 git what I downloaded not long time ago (however 32 bit version i have done with 4.4.4 but there are not really big changes). Simply, 4.4.3.1 worked better form me with MSVC. So I'm trying to use all my "talents" to fork and amend 4.4.3.1 version.
By the way, if PNG is loaded and displayed, there is also necessary to compile libpng (lpng1637) and zlib in 64 bit, loadpng I just included in source to my project and compiled all together.

Marek

William Labbett
Member #4,486
March 2004
avatar

Hi Marek,

does it compile with MingW64? Could I get it working with code::blocks?

Marek Ratajczak
Member #18,974
December 2020

William,
I didn't try with MingW64, but I believe that if it works with MSVC, it works with everything :P
Seriously, just take it and try it.
As long as we are talking about Windows GDI, and reading here: https://docs.microsoft.com/en-us/windows/win32/winprog64/interprocess-communication?redirectedfrom=MSDN this:
"64-bit versions of Windows use 32-bit handles for interoperability. When sharing a handle between 32-bit and 64-bit applications, only the lower 32 bits are significant, so it is safe to truncate the handle (when passing it from 64-bit to 32-bit) or sign-extend the handle (when passing it from 32-bit to 64-bit)...."
GDI seems to be relatively easy.
Unfortunately, I believe the migration won't be so easy on OSX, probably impossible without substantial changes. If Allegro 5 would get XOR mode, I would use it, I already migrated to Allegro 5, but I had to move back. I do not know how to do vector graphic in A5 without primitives infrastructure what I got in Allegro 4 API. I can modify GUI, to draw in memory first then swap displays (drawing directly on screen is extremely slow in DirectX), but the lack of XOR mode restrains my hands and thoughts.

William Labbett
Member #4,486
March 2004
avatar

Okay. Thanks very much for the help :)

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

Marek said:

Edgar,
There are not substantial changes, just couple of files. Maybe also important part is setup of MSVC project to get it 64bit, but maybe not that hard to setup another compiler.
I'm not a hero in GitHub, so let me learn first how to do that what you request for. That's correct, it's based on 4.4.3.1 git what I downloaded not long time ago (however 32 bit version i have done with 4.4.4 but there are not really big changes). Simply, 4.4.3.1 worked better form me with MSVC. So I'm trying to use all my "talents" to fork and amend 4.4.3.1 version.
By the way, if PNG is loaded and displayed, there is also necessary to compile libpng (lpng1637) and zlib in 64 bit, loadpng I just included in source to my project and compiled all together.

Marek

I took the liberty of forking your project and comparing it to allegro 4.4.4. I used 'git diff > patch.txt' after copying all of your changed files to the existing Allegro 444 from GIT.

I attached the patch file to this post.

If you read it, you will see that these changes can't be merged directly with 4.4.4, which is the development branch, without breaking a lot of the versioning. To contribute the changes, it would be best to 1) Fork the liballeg allegro5 master from github and do git checkout 4.4 then 2) apply your changes directly, 3) commit them, and 4) make a pull request.

1) Go to http://github.com/liballeg/allegro5 and hit the FORK button.

Clone the repository using the directions and using GIT after installing it.

git clone http://github.com/yourname/allegro5.git Allegro443
git checkout 4.4

2) Apply your changes, and whatever else you need to get it to compile in MSVC. Leave the versioning out. Also, try to make one commit for the 64 bit stuff, and one commit each for any other changes you make.

git add [file | directory]
...

3)
git commit -m "Commit message"

4) Go to your repository on github and select pull request. Make sure to compare the remote allegro 4.4 branch with your github changes branch.

Happy hunting.

amarillion
Member #940
January 2001
avatar

Ok, I made an attempt to work this patch.

Edgar, I believe you took your diff against the wrong base. Your patch file has a lot of changes like this:

-set(ALLEGRO_VERSION 4.4.4)
+set(ALLEGRO_VERSION 4.4.3)

Which makes it hard to apply cleanly. I instead took the diff between the 4.4.3.1 tag and Marek's code

diff -r -Zu allegro4.4.3.1/ allegro4-64bit-MSVC/

Which leads to a much smaller patch (attached)

 demos/shooter/demo.c                           |    2 +-
 src/file.c                                     |    4 ++--
 src/fsel.c                                     |    2 +-
 src/glyph.c                                    |    4 ++--
 src/gsprite.c                                  |    2 +-
 src/gui.c                                      |    4 ++--
 src/guiproc.c                                  |    8 ++++----
 src/unicode.c                                  |   12 ++++++------
 src/win/gdi.c                                  |    2 +-
 src/win/wddlock.c                              |    4 ++--
 src/win/wgdi.c                                 |    2 +-
 src/win/wmidi.c                                |    4 ++--
 src/win/wsndwo.c                               |    4 ++--
 41 files changed, 27 insertions(+), 27 deletions(-)

It's so small it seems like I'm missing something. Marek added a bunch of files too, but it seems to be mostly some generated documentation and build files, I didn't find any significant added files.

This new patch applies cleanly to allegro 4.4. Here are the changes on my own fork of allegro:

https://github.com/amarillion/allegro5/commit/fc8cb8e0846a397fcd1990a5aa92fa3a18e722f8

All I need now is somebody to actually test this. I'm not set up for that.

--
Martijn van Iersel | My Blog | Sin & Cos | Food Chain Farm | Support TINS

Marek Ratajczak
Member #18,974
December 2020

Amarillion,
You are right, there are not many changes, and in fact I copied whole folder so also build files were included, what probably led to big troubles to generate differences.
But those files which were amended / changed, are easy to find by date (last update), because all that work I've done around Xmas, so between 26.12.2020 and 27.12.2020. Some of those changes are marked by "//64bit ... " comment, but unfortunately I forgot to do that in each file I changed. But it is also easy to detect them by searching string "long long" which for 64 bit version replaced simply "long" because of length of addresses, however, is not necessary well done, it should be instead some "long_long" declared as long or long long depending of the desired machine, or x86 or x64. It should be actually corrected in the code.
So it's right, it's so small, but not necessary you are missing something. Actually that was a reason why I included whole folder to make it easier at least to compile with MSVC (the project is created in MSVC 2017), to get it working quickly, as a starting point for other compilers, which I didn't test.
I just can say, since I compiled that version, as an "engine" for my CAD, which is compiled in 32bit with 4.4.4 fork and 64bit with my version of 4.4.3.1, with obviously necessary changes in my code (but this time made better in my code, as long_long rather than long or long long, to use the same source for bot 32bit and 64bit), all is running well, as pure 64bit application (there are also MFC included), with fully functioning Allegro for both vector (primitives) and bitmap operations (I do not use Allegro GUI, I created my own one), however, as I underlined before, I'm using GDI driver, which is the only fast enough for direct drawing, what is necessary in my project, especially XOR mode for drawing vectors.
Regards.

Elias
Member #358
May 2000

It's so small it seems like I'm missing something.

Not so surprising - the Linux builds of Allegro 4 always supported 64 bit and the Macos port was fixed for 64-bit when the Intel macs appeared. Just DOS/Windows remained 32-bit throughout the entire lifetime of Allegro 4. But yeah, it means 64-bit Windows specific code is the only place that requires changes.

--
"Either help out or stop whining" - Evert

Marek Ratajczak
Member #18,974
December 2020

Elias,
You wrote: "and the Macos port was fixed for 64-bit when the Intel macs appeared."

Looks like I've missed something. As I know the only Mac OS graphic driver in Allegro 4 was and is QuickDraw in a Cocoa window, which was never supporting 64bit target. Was it replaced by something what supports 64bit ? I would love it, at least waiting until Allegro 5 will support XOR mode, and some other "legacy" features (like DRAW_MODE_COPY_PATTERN for example) that I can't live without.

Elias
Member #358
May 2000

Hm, I may be misremembering. I definitely used the 64-bit Linux version though. (But never used Windows or Mac myself.)

--
"Either help out or stop whining" - Evert

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

Marek Ratajczak
Member #18,974
December 2020

Edgar,
I will appreciate if you would do all necessary patches, as should be done. I made those small changes and I'm proud of it, but I cannot say I'm really familiar with GitHub requests. I'm pretty sure whole community will be more happy whe you will do that, if you are doing anyway. Many thanks.

Post Reply
Go to: