|
This thread is locked; no one can reply to it. |
1
2
|
Feat Req: Ag 4 to Ag 5 Translation Layer |
ZoriaRPG
Member #16,714
July 2017
|
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
|
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
Major Reynaldo
May 2007
|
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. My Website! | EAGLE GUI Library Demos | My Deviant Art Gallery | Spiraloid Preview | A4 FontMaker | Skyline! (Missile Defense) Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide |
SiegeLord
Member #7,827
October 2006
|
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 |
Polybios
Member #12,293
October 2010
|
It depends on your codebase. |
ZoriaRPG
Member #16,714
July 2017
|
'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. |
bamccaig
Member #7,536
July 2006
|
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. -- acc.js | al4anim - Allegro 4 Animation library | Allegro 5 VS/NuGet Guide | Allegro.cc Mockup | Allegro.cc <code> Tag | Allegro 4 Timer Example (w/ Semaphores) | Allegro 5 "Winpkg" (MSVC readme) | Bambot | Blog | C++ STL Container Flowchart | Castopulence Software | Check Return Values | Derail? | Is This A Discussion? Flow Chart | Filesystem Hierarchy Standard | Clean Code Talks - Global State and Singletons | How To Use Header Files | GNU/Linux (Debian, Fedora, Gentoo) | rot (rot13, rot47, rotN) | Streaming |
ZoriaRPG
Member #16,714
July 2017
|
beoran said:
The fundamental problem seems to be that your current code is not well factored out. 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
Major Reynaldo
May 2007
|
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. My Website! | EAGLE GUI Library Demos | My Deviant Art Gallery | Spiraloid Preview | A4 FontMaker | Skyline! (Missile Defense) Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide |
Eric Johnson
Member #14,841
January 2013
|
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
|
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
|
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
Major Reynaldo
May 2007
|
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. My Website! | EAGLE GUI Library Demos | My Deviant Art Gallery | Spiraloid Preview | A4 FontMaker | Skyline! (Missile Defense) Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide |
bamccaig
Member #7,536
July 2006
|
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. -- acc.js | al4anim - Allegro 4 Animation library | Allegro 5 VS/NuGet Guide | Allegro.cc Mockup | Allegro.cc <code> Tag | Allegro 4 Timer Example (w/ Semaphores) | Allegro 5 "Winpkg" (MSVC readme) | Bambot | Blog | C++ STL Container Flowchart | Castopulence Software | Check Return Values | Derail? | Is This A Discussion? Flow Chart | Filesystem Hierarchy Standard | Clean Code Talks - Global State and Singletons | How To Use Header Files | GNU/Linux (Debian, Fedora, Gentoo) | rot (rot13, rot47, rotN) | Streaming |
Edgar Reynaldo
Major Reynaldo
May 2007
|
Distinction noted. It's more like a zlib or MIT license really. My Website! | EAGLE GUI Library Demos | My Deviant Art Gallery | Spiraloid Preview | A4 FontMaker | Skyline! (Missile Defense) Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide |
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! !" 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. Agui GUI API -> https://github.com/jmasterx/Agui |
SiegeLord
Member #7,827
October 2006
|
DarkDragon said: 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. 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 |
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). |
MiquelFire
Member #3,110
January 2003
|
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. --- |
bamccaig
Member #7,536
July 2006
|
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. -- acc.js | al4anim - Allegro 4 Animation library | Allegro 5 VS/NuGet Guide | Allegro.cc Mockup | Allegro.cc <code> Tag | Allegro 4 Timer Example (w/ Semaphores) | Allegro 5 "Winpkg" (MSVC readme) | Bambot | Blog | C++ STL Container Flowchart | Castopulence Software | Check Return Values | Derail? | Is This A Discussion? Flow Chart | Filesystem Hierarchy Standard | Clean Code Talks - Global State and Singletons | How To Use Header Files | GNU/Linux (Debian, Fedora, Gentoo) | rot (rot13, rot47, rotN) | Streaming |
ZoriaRPG
Member #16,714
July 2017
|
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). 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. MiquelFire said: 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? Edgar Reynaldo said: 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
|
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
|