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

Todd Cope said:

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.

beoran
Member #12,636
March 2011

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

Chris Katko
Member #1,881
January 2002
avatar

Just one point of contention:

ZoriaRPG said:

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.

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.

-----sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs
"Political Correctness is fascism disguised as manners" --George Carlin

jmasterx
Member #11,410
October 2009

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.

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.

beoran
Member #12,636
March 2011

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.

Gideon Weems
Member #3,925
October 2003

jmasterx said:

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

Does this game use Allegro? /offtopic

jmasterx
Member #11,410
October 2009

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.

Gideon Weems
Member #3,925
October 2003

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

Todd Cope
Member #998
November 2000
avatar

beoran said:

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.

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.

Quote:

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.

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.

jmasterx
Member #11,410
October 2009

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.

ZoriaRPG
Member #16,714
July 2017
avatar

Beoran said:

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.

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.

bamccaig
Member #7,536
July 2006
avatar

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.

beoran
Member #12,636
March 2011

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

Elias
Member #358
May 2000

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.

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

beoran
Member #12,636
March 2011

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.

ZoriaRPG
Member #16,714
July 2017
avatar

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.

beoran
Member #12,636
March 2011

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

Elias
Member #358
May 2000

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.

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

beoran
Member #12,636
March 2011

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.

 1   2 


Go to: