I'm certain that this topic has arisen in the past, but it would truly be nice if there was a / legacy layer / for Allegro 5, so that those of us with massive codebases built on ag4 could use the latest library without needing to rewrite 250k+ lines of stuff to adapt.

How impractical is this, these days; to provide some kind of translation later with ag 5.x for 4.x codebases to use?

I think it would be incredibly impractical. How would you expect something like this to even work? I think it would take more time to write a compatibility layer than it would for you to simply rewrite your existing code using Allegro 5.

There are guides for porting from A4 to A5, and Evert Gleebek wrote some sort of conversion tool that is pretty old by now.

The main thing to remember is A4 was memory bitmaps, software drawing, cpu bound, and polling based. The main thing to remember in A5 is video bitmaps, hwaccel, gpu bound, event based. Those are the main things that need to be changed.

Rewriting a polling system to use events can be a bit of a pain, but the effort is well worth it - no more missed input, no more 100% cpu.

And regarding conversion tools - A4 doesn't map 1 to 1 with A5 in the function or structure department, so a perfect tool would be pretty complicated.

There's https://github.com/kazzmir/allegro4-to-5 and also the speed demo inside A5's source has a very loose adapter in the a4_aux.h.

It depends on your codebase.
When you have event-polling and accessing key[...] from pretty much everywhere, you're probably going to have a hard time. Providing a compatibility layer for memory bitmaps shouldn't be too difficult; it could even be slower than A4 though.

'When you have event-polling and accessing key[...] from pretty much everywhere, you're probably going to have a hard time.'

Well, we certainly have plenty of that. There is good reason that any migration for us would require a major rewrite under the present system.

I suppose the main issue, is that ag5 was not written with backward-compatibility in mind, and stuff like this would need to be added to a support/legacy layer, for it to be viable.

At present the options to migrate are limited. It cannot be done a bit at a time, but rather, it requires pretty much writing the engine from scratch, then figuring out how to make it backward compatible with our old versions. Backward compatibility with all prior releases of ZC is our highest priority.

The fundamental problem seems to be that your current code is not well factored out.
I think a possible approach would be to first refactor your project so all calls to A4 are cleanly wrapped by some middle-level wrapper functions. This is the most work, but it is valuable in itself since it will clean up the code of the project and make it significantly easier to update your code later. Then, replace A4 with A5 in those wrapper functions functions. At this stage, the upgrade will actually be not so much work at all.

Is there a reason you need to upgrade at this time? It may be worth a grain of wisdom: if it ain't broke, don't fix it. Is it feasible to write a compatibility addon that registers all events and tracks the state of everything in an A4 API? I don't know. I don't imagine anybody is going to go that trouble unless they themselves need it. Perhaps this is a project for the OP to attempt.

We're well-aware of this, and we are slowly working towards a goal of processing all of these events through back-ends, but it is a very time-consuming process. Sure, it would be lovely if we had a huge staff to just jump in and refactor everything, but we have four people working on it in their spare time, as a hobby; so, it takes time.

I concur that it should have been done years ago.

The reason is that on Windows, ag4 programmes have numerous graphical issues that are nearly impossible to resolve. We have fixed some of the most fundamental with care, but there are others that simply cannot be addressed; and in the future, as more and more legacy elements are stripped from the OS, it becomes increasingly impossible to maintain support.

On the Linux front, there are also a variety of sound issues that we have encountered, and I am not qualified to deduce the cause thereof.

The most critical question is: Should the burden of making the newer version of allegro backward-compatible be placed on the user?

I think that this is somewhat short-sighted. If ag5 was developed with backporting in mind from the onset--this was dropped early on--then we would not be discussing it now; but it certainly makes sense to have this as a capability.

Otherwise, you are just saying, make a wrapper for everything, at which point the user may as well use a newer model, or just use OpenGL. Allegro's popularity clings to legacy applications that use it. Now that those applications are breaking on modern operating systems, it is worth considering fixing the root of the issue, rather than saying that every single application needs to be refactored.

Ultimately, the problem is with companies like Microsoft, who drop support for drawing modes, or other core UI components, and expect everyone to upgrade. When you have a userbase that is updating to the shyte that is Win 10, and your software breaks because MS kill compatibility layers, you can't just jump on a rewrite and expect everything to go smoothly.

This is precisely what has happened on Win 8+, and TBH, what happened with Allegro 4.9. Perhaps it would be better to work on polishing 4.4x and just continue using it, but that is also a short-term solution .

Please understand that I don't expect a back-porting layer to be added to ag5. It should have been there from the onset, but it would be damned nice to have at this point, especially if you want to convince users to update to the newer lib without needing to fully re-write first.

This kind of thing allows the programmer to slowly adapt and merge a codebase to new ag5 stuff, without breaking the whole ball of wax and taking two to three years to do the conversion with zero updates, or releases in the interim. It is worth considering, as a future goal, at the least, IMO.

Allegro 4 was an evolutionary dead end. Sometimes you have to turn around and start over on a fresh path.

Simply put, there was no clean way to do what needed to be done for Allegro 5 without getting rid of the old system first.

I'm sure people are happy to apply patches, but I doubt anyone wants to actively work on maintaining Allegro 4 anymore. I love it, and I don't want to touch that mess either.

Allegro 5 is fundamentally different compared to Allegro 4. Aside from sharing the same name, it's essentially a whole new library. I think backwards compatibility with 4 is unrealistic and kind of silly.

If there's anything I've learned from programming and technology as a whole it's this: never get attached to something, because it's here today but it'll be gone tomorrow. You have to constantly stay up to date or you risk getting left behind.

I highly recommend biting the bullet and just rewriting your code using Allegro 5. You'll have to do it eventually--with a compatibility layer or not--so you might as well start sooner than later.

As I said, there is already some groundwork towards this goal, but it is incremental, and there have been discussions along the line of:

When we have a backend done, and we are free of the ag4 dependency, what library do we want to use?

Allegro 5 is one of four possible choices that we have discussed. A major concern though, is that ag5 is now years old, and we have no idea how long it will remain supported, given what happened to ag4.

Nothing lasts forever, but I think it's a safe bet to assume that Allegro 5 will be around for a long while. The only reason (or one of the biggest reasons, I suppose) why Allegro 4 and 5 are totally different is like Edgar said: "Allegro 4 was an evolutionary dead end"; the API had to be totally different moving forward to reflect the changes in hardware and technology as well as to overcome the limitations of Allegro 4. So, unless another major API change is hidden beyond the horizon (which I don't think there is), Allegro 5 is here to stay, and you shouldn't have to worry about its longevity or it falling out of support.

Allegro 5 is stable, and still under development. You can do all kinds of things with A5 you could never do with A4, like use shaders and upload vertex data.

I suggest you take another look at Eagle. It can teach you a lot about compatibility with A4. All the abstraction is already done for you. If you wanted to write a short driver for A4 for Eagle, all the work would be done for you, and you could use Eagle as your abstraction layer. It is event based and has an Allegro 5 backend up and running. As soon as I get multiple windows working properly together I may make some binaries for people to try.

Specifically, look at the way I provide A4 style input from an event system :

https://github.com/EdgarReynaldo/EagleGUI/blob/master/src/InputHandler.cpp#L618-L866

Using something like that could accelerate your efforts to abstract your backend away. License for my code is freeware - just keep the copyright notices intact or mention me or something.

Nitpick: "freeware" typically implies gratis to run proprietary software. Copying, redistributing, and modifying are typically not allowed, and typically source code is not available. You'd be better off describing your licensing as free software or open source software. The best option is just to pick a tried and tested open source license that you like. Many of them require copyright notices to remain intact (e.g., BSD), but you could customize a simple license to your liking if that's too restrictive.

Distinction noted. It's more like a zlib or MIT license really.

I don't want to wade too deeply into this discussion, as from what I can tell Allegro 5 is a far more robust and maintainable library than Allegro 4 and a compatibility layer indeed does not sound practical. But this point jumped out at me:

[quote]If there's anything I've learned from programming and technology as a whole it's this: never get attached to something, because it's here today but it'll be gone tomorrow. You have to constantly stay up to date or you risk getting left behind.[/quote]

This seems like a very odd stance for a library provider to be taking. Stability and backwards-compatibility are huge selling points for developers. "We might totally change the API to make you rewrite 1,000,000 lines of your own code at any time! !" is not going to endear you to developers weighing using Allegro over alternatives.

Again, not trying to start a flame war--but did want to register my reaction as a developer of one of your biggest "customers."

Something that has not really been stated though, is, at the hardware level, things are fundamentally different in A4 than A5.

Software rendering like A4 gives you really fast direct access to pixels, and you do things in software you would just not do in hardware.

In hardware accelerated graphics, we get pixel access through shaders. Direct pixel access on a video bitmap is too slow. And if you are not interested in using hardware acceleration, then I do not really see the point in switching to A5.

But Switching to an event driven hardware accelerated API requires fundamental changes in how you render things and do things. It's not just about wrapping the calls.

That can probably be done, but it would incur such a performance hit to be backward compatible that you might as well stick to A4.

A4 => A5 was not just this fun refactoring of function names and categories, it's a fundamental change in how you do your rendering, key binding, sound mixing, input handling, to use modern techniques of game development.

It's not just something that can have bindings or macros and you get a 1 to 1 performance mapping.

I think backwards compatibility is an incredibly important feature, but Allegro 4 kind of designed itself into a corner. Perhaps it could have been redesigned in a more minimal way, but that discussion is a decade too late at this point. Allegro 5, for what it is worth, has a pretty long history of backwards compatibility.

A project that appears to have similar problems is Adventure Game Studio (AGS) which has quite a large community (and several indie games have been sold based on it).
Dating back to 1999, AGS uses Allegro4 at its heart, but they seem to have hacked it to be able to run on Android, iPhone, and macOS.
Apparently, they keep doing all the drawing on A4 memory bitmaps and then copy the resulting backbuffer to OpenGL or whatever. I don't know much about this, only been curious after I bought a game and saw an A4 DLL coming with it, so I don't know how they handle input.

I remember there being an OpenGL Plugin for Allegro 4, AGL I think it was referred as. There's a chance that using AllegroGL might have allowed AGS to keep its support even though it's using A4.

Wasn't Allegro 4.4 supposed to be hardware accelerated too? And what exactly is breaking with Allegro 4.x in Windows 10? Rather than developing a compatibility layer I think it's probably a better goal to try to keep Allegro 4.x working with the latest OSes. Maybe that won't be the A5 team doing it, but the beauty of open source software is that anybody interested can do the work of maintaining patches to keep it functioning properly. Report the issues and maybe the fixes will come.

That's interesting. I'll need to see if they are open source, and what modifications they have made to Allegro 4 in the process. If they have produced a library that is ag4 compliant, that is actually an improvement, it may be worth researching it.

I think that AGL is part of the 4.4.x series. Is that right?

It is rather critical, from our stance, that all licences are explicit. If you want a ZLIB-style license, you may as well use the ZLIB license. If you want GPL, use that. If you want something custom, you should write it, but at this point, that seems extraneous.

The main issue, is clarification, particularly when your library is being supplied with other packages that use ZLIB, GLP, whatever. Any 'murky' license is an automatic 'no' in the open-source world, as it can come back and bite you in the arse in time to come.

First of all, I fully appreciate that refactoring a legacy project is a lot of work.

Seeing that there are several A4 projects that are "stuck", I do wonder if maybe A5 should be given some non core additional features to ease the transitions, such as palettes, packfiles, support for MIDI files, etc...

That would already go quite some way towards helping projects transition from A4.

I think instead of trying to make a compatibility layer, it would be better to have an Allegro 4 add-on for Allegro 5 that keeps Allegro 4's internal operations as-is but has helper functions to convert BITMAPs to ALLEGRO_BITMAPs so we can put the final buffer onto the screen. The system drivers would just use Allegro 5 to get at the hardware instead of having drivers for each OS. Spawn a thread to listen for keyboard events and fill the key[] array, another for mouse, etc. Your Allegro 4 code would compile without changing anything.

Allegro 4 is great at what it does (easy API, fast memory bitmap manipulation, etc.). Instead of trying to map Allegro 4 functionality onto Allegro 5, let Allegro 4 do what it does best and have some helpers to convert A4 data types to A5 to help transition projects. Also, if your project is better suited to memory bitmaps you could use the add-on in new projects.

I, too, have a huge project that uses A4 that I've been reluctant to start porting to A5 due to the size of the task. After a lot of thought, what I really want to move to Allegro 5 for is modern system compatibility. I don't want the hardware acceleration, alpha blending, etc. I just want my program to run on modern systems. With my proposed add-on, I could compile my Allegro 4 project and get it up and running in no time. Then, if I wanted to change the main loop to use Allegro 5 events to minimize CPU usage, I could do that as well.

I agree with this, and it would be superb. I do not know if it is practical, but for our scope of use, shaders would rarely see the light of day; pun intended.

Our engine is an 8-bit thing that needs the palette structure of allegro 4, which is one of the reasons that there was never an urgency to convert. Much of what we do depends on memory bitmaps, and such. A rewrite to use OGL and similar would turn what runs at a decent speed, into something that bugs down all but the latest hardware; which is the objection that I raised to us using OpenGL not too long ago.

Being able to merge the libraries somehow would open up new corridors of capability, but that would be a massive undertaking, and you blokes are just as understaffed as we are.

Todd Cope, so what you propose is to use both a4 and a5 into the same program as is, but then make a thin bridge library or a5 plugin that does as you described
That would probably be less work, yes, but I don't know if it is even possible
Hmm, something worth trying at least...

Just one point of contention:

That really makes no sense. Worst case, a memory bitmap in A5/OGL cannot be slower than a memory bitmap in A4. It's still a memory bitmap. And palettes can be simulated with insane speeds using shaders. The palette itself can simply be a texture. Tons of people have written color-cycling palette shaders, a simple google shows:

https://gamedevelopment.tutsplus.com/tutorials/how-to-use-a-shader-to-dynamically-swap-a-sprites-colors--cms-25129

https://gamedev.stackexchange.com/questions/43294/creating-a-retro-style-palette-swapping-effect-in-opengl

And that requires zero writes to bitmaps. (Zero locking. Zero syncing. Zero slowdown) The shader builds the correct palette entry at draw time using all those cores that are just sitting there bored on people's machines.

The ONLY drawback is, your program will require a card with an OpenGL version that has modern pipelines.... which is like OpenGL 2 (and some support before that through extensions.). Which, IIRC, is an nVidia GeForce 6100 or later. It came out in 2005 so... 12 years ago and predates... Windows Vista.

Yes,however, A4 uses software rendering, which makes blitting memory bitmaps quite fast. Compared to A5 that if used in HW accelerated mode with memory bitmaps will be insanely slow.

Using A5 in software mode is well below A4 performance.

Direct pixel access, without shaders, will still be pretty slow if you want to use HW acceleration.

It would affect games like https://en.wikipedia.org/wiki/Pocket_Tanks that probably use direct pixel access.

A game like that could easily be altered to take advantage of hardware acceleration, but maybe not out of the box port.

Still an A4 compatibility addon would be great. Perhaps the A4 software renderer could be ported to get the same performance at least in software mode.

OK, here goes. I make a proof of concept based on Todd Cope's idea. You link both a4 and a5 into your program. You use a4a5's transition functions, mapped through macros to a4. You use a5 explicitly to set up your game and the display, but the rest of your program can keep on using the a4 API mapped through a4a5. This will allow gradual transition.

https://gitlab.com/beoran/a4a5

Currently I have only keyboard support, and I only compiled and tested it on Linux, but I think now it's probably not that much work to get something usable. In stead of looking at each other to see who will move first, let's work on this together. So some on over to gitlab and I will add you guys to the project, maybe even make a group for this?

Meanwhile some A5 addons such as palette support, midi support (through fluidsynth?), packfiles, an A4-style gui lib on A5 would be useful to further ease the transition.

Does this game use Allegro? /offtopic

I'm pretty sure it does.
The windows version links against ddraw (direct draw) so that already gives me an indication. But I remember reading somewhere a while back that it did. One of the friends of the developer used to hang around a.cc and made Neon Wars, but that was made with OpenGL.

Grepping binaries from the APK didn't turn up any Allegro-specific strings. A (now defunct?) vector/primitive drawing suite called Fog is mentioned in readme.txt, however, so perhaps it is safe to say Allegro is not used (at least in the Android version).

a4a5 is not exactly what I had in mind, but it seems like it could work. My plan was to clone the A4 repo and make a new set of drivers that just map hardware access to Allegro 5. Then change the name of the library to Allegacy or something like that.

Aren't you already using Allegro 4 for these things if you use a4a5 (other than MIDI)? With my plan, PACKFILEs would use ALLEGRO_FILE functions underneath instead of stdio. Sound functions would use A4 code, but the final output would route through Allegro 5's audio add-on. MIDI support could be added through a portable MIDI library (if there is one), or a MIDI add-on could be created for A5.

Not sure we have the same goals in mind. My goal is not necessarily to transition away from A4 gradually for projects that rely on it, but rather just get them to run on modern systems while leaving the door open to utilize some modern features where you want to. The main feature I want to be able to use from A5 is the event system for minimizing CPU usage.

I did not think the android port would use Allegro.
I'm not even sure the PC versions do. The game was originally released in I think 2001, and I think the first versions did use it, but eventually, to make it work on android and such they probably switched to something else that I cannot seem to find.

Oh my, that sounds like progress that I never expected.

What is obvious, that would be needed, for our stuff, are palettes, colour conversion, ag4 drawing primitives, packfiles, and memory bitmaps.

I would be willing to work on testing this stuff, and possibly on the project itself, given appropriate time; but I have zero rep here, so I have no idea if you would want me involved at present.

Typically open source works like this: talk = useless, action = welcome aboard. It's pretty rare for people that do useful work to get turned away. If you're willing to try and contribute what you can I'm sure you're welcome. Just don't expect the job to get handed to you done by somebody else. It might, if you inspire them enough, but their fuel will likely drain quickly, whereas you have a need for a solution that most others don't have. You should be the one driving change. You can do anything you put your mind to.

@toddcope

Actually I do have the same goals in mind, but I see it more like a 3 step approach:

1. First make a4a4 a "bridge" library. You use all three a4, a5 and a4a5. a4a5 takes care of mapping a4 onto a5 in a minimal way, but doesn't provide packfiles, etc yet, those stay in A4. Just the bare minimum. Like this, A4 games can be ported with not too much effort to run on new hardware. Likewise, A4a5 can emain thin and we can have something usable sooner than if we try to put the whole of A4 API on top of A5.

2. We move all missing A5 functionality from A4 to A4A5 by copying over what we can from A4. This should result in not needing A4 anymore. This is what you were suggesting. At this stage a4a5 == allegro legacy. This is a middle long term effort.

3. We implement all missing A4 functionality as plugins for A5. A4A5 just becomes a thin layer over A5. This is a long term effort, lots of work, but makes further
upgrading to A5 easier.

@ZoriaRPG: Good to hear you are interested, but you should be willing to take an active role in this idea. Scratch your own itch, and all that.

@bamcaig

I agree. Todd Cope and ZoriaRPG have almost the same goals here, and what I'm suggesting is a quicker path towards those goals. But I only gave the kick off, it's up to the A4 users to keep playing the ball. I'll be willing to assist too, but I need all the help I can get to keep this going.

I completely agree with Todd Cope's approach. In allegro4-to-5 we started with the idea that we do not need 100% compatibility - and without going into all the details that eventually got us stuck because for each problem we now could just say "update the user's A4 code".

Starting from a copy of the A4 base and simply replacing all the platform drivers (DOS, Windows, Linux...) with a single A5 driver should achieve that. And it would involve zero copy&pasting and just some simple implementations (instead of updating key[] from a DOS hardware interrupt update it from an A5 event thread).

Two issues I can see is synchronizing the screen BITMAP asynchronously, and palettes.

For the screen BITMAP I think a lot of A4 code actually uses "double buffering" or "page flipping" which should make it easy to have it work, i.e. call al_flip_display from show_video_page or when a bitmap of the same size is blit() to screen. In other cases (probably have to auto-detect that somehow) something slightly more hackish might be needed to call al_flip_display often enough.

For palettes, I would go the ex_palette A5 example way and use a shader. Note how none of the A5 graphics functions at all are used otherwise. A4 can draw 100% of the graphics, the only thing the new driver has to do is display the one A4 screen BITMAP on Allegro's display from time to time.

Well, if you don't like the idea of of a thin bridge approach, then https://github.com/kazzmir/allegro4-to-5 which SiegeLord linked is actually close to what Elias and ToddCope are suggesting.

I just read the code of that project a bit and there already seem to be quite a few things in working order. Although it does use an underlying ALLEGRO_BITMAP for BITMAP, ALLEGRO_FONT for FONT, etc, starting with that project could also allow us to save time. Personally I am most interested in providing a way for A4 projects to transition gradually to A5, but I don't care too much how this goal is achieved. So, I thin we could start with allegro4-to-5 as a basis.

I'm clearly more interested in beoran's approach here. It seems like a clean, simple, and effective way to provide a compatibility layer, that doesn't drop support for legacy calls, and allows using ag5 stuff with ag4 stuff, side-by-side.

As I said, I might be up for doing some work on it. This all depends both on my available time, general state of wellness, and comprehension of the subject matter. I'll take a look at it at some point soon, and see what happens.

@ZoriaRPG Well, if you like the thin bridge idea, I think I could allocate some time to it. Especially seeing that your project is an important A4 project that I would like to see upgrade gradually to A5. That's my fundamental idea behind a4a5, to allow gradual transition to A5 for existing A4 projects.

allegro4to5 is the thin-bridge approach. You could probably reuse some of it. It just will never be able to run 100% of existing a4 code (without modifying that code) - which would be the goal of the a4-driver idea.

I don't want to get lost in semantics, but I would call allegro4to5 more of a "thin wrapper".

No matter the approach, you will have to link in A5 to run A4 code on top of it. So you might as well make use of A5 for its functionality. And A4 is unsupported now, so it would be best if A4 projects could upgrade to A5. But the gap is too wide to do this transition without help. That is what I want to do with a4a5. Provide a helper library that will smooth the transition. You gradually start using A5 code while keeping using A4 for features A5 misses.

Yes, you will have to change your code somewhat to use a4a5.
For instance, I envisage that with a4a5, you set the screen mode with A5, but still draw to an A4 bitmap and then blit/flip that to the A5 screen with an a4a5 function. But that is the way to go. Rather than wrap A5 in an A4 jacket and use that indefinitely, with a4a5 I want to enable people to truly upgrade to A5 at their own pace.