Allegro.cc - Online Community

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

This thread is locked; no one can reply to it. rss feed Print
 1   2 
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

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.

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.

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

killocan
Member #1,556
October 2001
avatar

First of all, Marek Ratajczak, what an awesome move!!!! Congratulations on that!!! I have a project that uses all4 that is on hold(deadish) for quiet a while now, but would be good to compile it on 64, just because hehehe. Since my day to day work is not related to programming I can't say I will to it stat, but I'm definitely trying your(and other fellows that are merging it) solution anytime soon!!! Once again, congrats on the job!

Peter Hull
Member #1,136
March 2001

I had a quick check yesterday evening; the code as it is won't compile on Linux now, due to ULONG_PTR. There are also some line-ending problems (stray ^M). I hope to have some time over the weekend to go over it more thoroughly. I believe we can and should use the stdint types, they are actually the ones used in the header files.

[edit] I did look and started trying to fix all the warnings but with MSVC set to /W3, as it is in our CMake script, there's a huge number of them. Most of them are of dubious value. So I think I'll back-track and just make sure it'll compile on Windows (MSVC) and Linux, assuming MinGW will also be OK. That's only a couple of changes to Marek's PR.

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

Peter Hull
Member #1,136
March 2001

Despite appearances to the contrary I'm not dead, either.
But I am just struggling with building using MSVC; it's not able to link in the allegrogl part. Also the built-in CMake support in Visual Studio seems a bit flaky and gives inconsistent errors which don't appear in the 'standalone' cmake.

If anyone knows about this, please chip in!
Pete

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

Glad you're still with us Peter. ;) :)

Is there a repo you're working with? Let me clone it and see what I can do about the CMake stuff. Which version of VS are you using?

Have you made all the changes necessary to use the stdint.h header's standard types?

Peter Hull
Member #1,136
March 2001

I've fixed the cmake problem, plus all cases where the casts seemed unsound (i.e. casting a pointer to a long) and then a few bits and bats.
The branch is here:
https://github.com/pedro-w/allegro5/tree/64-bit-allegro4-ph
I will need to rebase to sort out the commits as they're all mixed up at the moment.

 1   2 


Go to: