Allegro.cc - Online Community

Allegro.cc Forums » Allegro Development » Feat Req: Ag 4 to Ag 5 Translation Layer

This thread is locked; no one can reply to it. rss feed Print
 1   2 
Feat Req: Ag 4 to Ag 5 Translation Layer
ZoriaRPG
Member #16,714
July 2017
avatar

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?

Eric Johnson
Member #14,841
January 2013
avatar

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.

Edgar Reynaldo
Member #8,592
May 2007
avatar

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.

SiegeLord
Member #7,827
October 2006
avatar

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.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

Polybios
Member #12,293
October 2010

It depends on your codebase. ;D
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.

ZoriaRPG
Member #16,714
July 2017
avatar

'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.

beoran
Member #12,636
March 2011

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.

bamccaig
Member #7,536
July 2006
avatar

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.

ZoriaRPG
Member #16,714
July 2017
avatar

beoran said:

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.

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.

bamccaig said:

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.

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.

Edgar Reynaldo
Member #8,592
May 2007
avatar

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.

Eric Johnson
Member #14,841
January 2013
avatar

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.

ZoriaRPG
Member #16,714
July 2017
avatar

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.

Eric Johnson
Member #14,841
January 2013
avatar

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.

Edgar Reynaldo
Member #8,592
May 2007
avatar

ZoriaRPG said:

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.

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.

bamccaig
Member #7,536
July 2006
avatar

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.

Edgar Reynaldo
Member #8,592
May 2007
avatar

DarkDragon
Member #8,337
February 2007

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! ;D!" 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."

jmasterx
Member #11,410
October 2009

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.

SiegeLord
Member #7,827
October 2006
avatar

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! ;D!" is not going to endear you to developers weighing using Allegro over alternatives.

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.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

Polybios
Member #12,293
October 2010

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.

MiquelFire
Member #3,110
January 2003
avatar

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.

---
Febreze (and other air fresheners actually) is just below perfumes/colognes, and that's just below dead skunks in terms of smells that offend my nose.
MiquelFire.red | +Me
Windows 8 is a toned, stylish, polished professional athlete. But it’s wearing clown makeup, and that creates a serious image problem. ~PCWorld Article

bamccaig
Member #7,536
July 2006
avatar

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.

ZoriaRPG
Member #16,714
July 2017
avatar

Polybios said:

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.

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 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.

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

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

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.

beoran
Member #12,636
March 2011

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.

Todd Cope
Member #998
November 2000
avatar

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.

 1   2 


Go to: