A few months ago I brought up an idea in this thread to create a drop-in replacement library for Allegro 4 that utilizes Allegro 5 for accessing the underlying system instead of having platform-specific drivers to access the hardware for each platform. Allegro Legacy does just that.

With Allegro Legacy you get a complete implementation of Allegro 4 (minus MIDI support and audio recording for now) and a few helper functions to get images onto the screen. These functions are:

ALLEGRO_BITMAP * allegro_get_a5_bitmap(BITMAP * bp);
void allegro_render_a5_bitmap(BITMAP * bp, ALLEGRO_BITMAP * a5bp);
void allegro_render_screen(void);

To get your program up and running with Allegro Legacy, you simply call allegro_render_screen() immediately after you are done drawing to screen and it will copy the contents of screen onto the Allegro 5 display it created when you called set_gfx_mode(). You can even support vanilla Allegro 4 and Allegro Legacy in the same program by utilizing #ifdef ALLEGRO_LEGACY.

Once you have your program up and running, you might want to replace that old CPU hogging timing loop with a nicer Allegro 5 timing loop. You can do this easily with Allegro Legacy since it gives you access to Allegro 4 and Allegro 5 functionality simultaneously.

This project should be considered early development. I am looking into getting MIDI support added, possibly with FluidSynth and/or PortMidi. I also should be able to get sound recording implemented easily. The allegro_render_screen() function could probably be optimized quite a bit as well.

Great, i wanted to do something similar, but I couldn't take the time to do so yet. So , I will follow your approach, since it seems to work better than my idea.

For midi support, i still think it would probably best to write an allegro5 midi add on and then wrap that for this project.

Great work!!!

Looking forward to this. For the A4 application I work on, it's possible that it can no longer render at all in the latest Mac OS X update (High Sierra). I haven't heard from any other Mac users to confirm this.

I've been considering doing this as well. I need MIDI support for one of my other projects, and I already put together a Windows MIDI driver from Allegro 4 code. If I was going to make an Allegro 5 add-on, I would probably just rip all the drivers out of Allegro 4 and use that as the basis of it. The biggest problem there would be to make an Android driver. It looks like there's a nice API available on the platform.

That was the program I used to test Allegro Legacy and get everything working, since it uses just about everything Allegro has (I had to make a couple of modifications since MIDI support isn't implemented yet). The good news is I was able to compile Allegro Legacy with the MacOS 10.12 SDK and the program ran fine. It's a bit slow, though. One of the main things I want to do is optimize the process of converting the screen bitmap to an Allegro 5 bitmap to get it onto the screen.

iirc allegro 4 has it's own midi renderer so, i think porting the allegro 4 midi code to allegro 5 is a great idea. And if the OS supports it directly, that's even better...

Thanks for this nice legacy library.

I tried to use it but failed. I want to replace allegro 4.4.2 with allegro 5.2.3 and your legacy lib.

I blit to screen with allegro 4.4.2 like this

    scare_mouse();
    acquire_screen();
    blit(ScreenBuf,screen,0,0,0,0,SCREEN_WIDTH,SCREEN_HEIGHT);
    release_screen();
    unscare_mouse();

If I use your lib and allegro5 and just add allegro_render_screen() after blit() it crashes in acquire_screen()

acquire_screen () at /usr/local/include/allegro/inline/gfx.inl:221
221 AL_LEGACY_INLINE(void, acquire_screen, (void),

If I remove acquire_screen() and release_screen() it crashes in BLIT

0x00007ffff7609f32 in blit (src=0x93d350, dest=0x0, s_x=0, s_y=0, d_x=0, d_y=0, w=800, h=600) at /home/hbs/src/Allegro-Legacy/src/blit.c:706
706 BLIT_CLIP();

Obviously I'm missing something ? At what point do I have to use

ALLEGRO_BITMAP * allegro_get_a5_bitmap(BITMAP * bp);
void allegro_render_a5_bitmap(BITMAP * bp, ALLEGRO_BITMAP * a5bp); ?

Thanks for testing!

Your program is crashing because screen == NULL. If you have called set_gfx_mode() prior to calling acquire_screen() and/or blit() and checked the return value to ensure the graphics mode has been successfully set, there is probably a bug with the creation of the screen bitmap in Allegro Legacy.

If you could post your init code here, it would be helpful in tracking down the cause of the issue.

When I replace your legacy lib it is immediatly running with allegro 4.4.2.

screen is != NULL and set_gfx_mode() returns 0.

I'm using it on a 24 bit depth linux computer.

What part of the init code are you interested ?

Is that with Allegro 4.4.2 or Allegro Legacy?

This error message shows that screen was NULL (0x0 == 0 == NULL) when it crashed on the blit() call. acquire_screen() will also crash if screen == NULL. That's why I suspect set_gfx_mode() is failing.

I would like to see your set_gfx_mode() call if you don't mind. If set_gfx_mode() is succeeding and screen == NULL, I am missing something in my Allegro 5 graphics driver code.

I fixed my logging so here is what really happens :

ret = set_gfx_mode(GFX_AUTODETECT_WINDOWED,800,600,0,0)

ret is -1 and allegro_error is "Unable to find a suitable graphics driver".

Requested depth is 24bit on a 24bit linux desktop.

Btw while the programm is properly exiting on error with allegro4, with allegro legacy there is still a thread running. Something special I have to clear on exit which is different to allegro4 behavior ?

Alright, I'll see if I can replicate the issue here and fix it. The hanging thread is also a bug.

Append: set_gfx_mode() was failing because the display driver wasn't flagged as a windowed driver. Since you are using GFX_AUTODETECT_WINDOWED, a suitable graphics driver could not be found. I have just committed a fix for this issue.

Append 2: The thread hanging issue is now also fixed.

Ok, progress was made.

Now I get a 800x600 black window and

Alright, I ran my test program using every color depth and found that for color depths > 16-bit, the image was being distorted. According to Allegro's documentation, you are supposed to be able to get the raw bitmap data by accessing the line pointers and casting to short or long for 15-, 16-, and 32-bit. This is probably wrong for 64-bit systems. By changing these to uint16_t and uint32_t I was able to fix the distortion (and prevent reading past the end of the allocated memory).

I also noticed that I had mistakenly used the 32-bit code for 24-bit bitmaps (I assumed wrongly that the data was stored the same for both formats). I added a separate implementation for working with 24-bit mode.

After all of these changes, everything seems to be working for every color depth. These changes have just been committed.

Nice work Todd, and thanks Larkin for the testing. :-)

Thanks, it is basically working now.

I noticed though that wav soundplay has a noticable (100+ msec) delay with your legacy lib.

I was using a fragment count of 4 with a sample count of 1024 in the ALLEGRO_AUDIO_STREAM that's used by the audio driver. I reduced the fragment count to 2, which might help some. This amounts to ~46ms of delay (was ~93ms with 4 fragments).

There might be extra latency due to differences in the way the Allegro 4 and Allegro 5 audio drivers work. The audio driver will certainly add some extra latency with its own buffers which it needs to ensure smooth audio playback. Maybe Allegro 5's Linux audio driver has a larger buffer that increases latency. I had this issue in the past with Linux ports of some of my games. Maybe it's still an issue.

When running my test program on Mac, there isn't really an abnormal amount of delay. I have Ubuntu 16 installed on a few computers so I'll test it there soon.

Hmmm. Some things that did work no longer do. I have no longer wav sound/music streaming, and the mouse pointer image is gone. Sound delay is still there and very obvious.

I haven't been able to reproduce any of those issues yet. I'll try on Linux soon.

How are you drawing the mouse pointer? Are you just doing show_mouse(screen);?

Yes, doing just show_mouse(screen);