search

NewCreature / Allegro-Legacy

Make Your Allegro 4 Programs Run On Modern Systems Using Allegro 5
19 stars 3 forks source link

Can't see anything rendered to screen without adding extra code. #13

Closed NewCreature closed 3 years ago

NewCreature commented 3 years ago

I think it might be possibly to make Allegro Legacy truly Allegro 4 compatible by emulating a display in a separate thread. screen can just be a memory bitmap and the contents can be copied to a display bitmap at regular intervals.

The display thread would run a timer that simulates the refresh rate and would copy the current contents of screen to the display's texture. It would work just like a real old-school display adapter in that the screen might not be done rendering when the pixels are copied. To remedy the tearing issue, the user would call vsync() before rendering to screen. They are probably already doing this anyway in their Allegro 4 projects.

If we can get this working, Allegro Legacy can be a true drop-in replacement for Allegro 4. I would still want to allow some of the nice added features to be available. Maybe we can add a flag that disables this emulated display if we want to go what we currently do. If the display is running in a separate thread, we won't be able to render textures from our own thread onto the display.

NewCreature commented 3 years ago

I tested this idea and it does indeed work. I think I'll pursue enabling the emulated display by default. This will allow Allegro 4 programs to work without modification. I still want to enable users to add improvements using Allegro 5, so having an option to disable this emulated display would be desired. We have to disable the emulated display if we want to user our own ALLEGRO_BITMAPs with the display since they must be created in the same thread as the display.

One thing I need to figure out is how to handle vsync. Ideally, when the user calls vsync() the graphics rendering will sync up with the emulated display and render a pristine image with no tearing. We should probably create a custom event queue and fire an event immediately after al_flip_display() so the users rendering code has time to complete it's rendering before the next al_flip_display() call. It should work even if the graphics driver doesn't wait for vsync to happen since the display thread will be updating at the user's specified refresh rate (or 60hz by default).

NewCreature commented 3 years ago

This has been implemented, but needs further testing. We no longer use special code in the GUI routines to force graphics onto the display. We instead rely on the emulated display being updated whenever the GUI draws to screen. It should work, but it hasn't been tested.

NewCreature commented 3 years ago

Seems to be working, closing.