What is the proper procedure for restoring bitmaps on Android?

What is the proper procedure for restoring bitmaps on Android?

Max Savenkov

Member #4,613

May 2004

Android is driving me crazy. First, blend modes didn't work and I had to write a shader to subtract two textures, and now bitmaps are getting corrupted after I suspend and resume my game.

So, what's happening:

When I resume my game after going to background (via pressing Home button), I get not one, but two ALLEGRO_EVENT_DISPLAY_RESUME_DRAWING events.

If I recreate all bitmaps on both of them, all bitmaps with NO_PRESERVE_TEXTURE get corrupted very badly. For example, when I later draw a one-pixel line on such bitmap, it gets displayed as a wide band.

If I only react to the first event, everything gets corrupted (as it should be, probably)

If I only react to the second event (beyond calling al_acknowledge_drawing_resume), the picture is more correct, but there are still some problems with alpha channel.

Here's the code I use:

#SelectExpand
  1// Game.cpp, main loop:
  2
  3case DisplayEvent::DISPLAY_RESUME_DRAWING:
  al_acknowledge_drawing_resume( al_get_current_display() );
  render.SetGlobalScaling( SCALING_KEEP_ASPECT, SCREEN_W, SCREEN_H );
  GetBitmapManager().ReloadAllResources();
  m_forcedPause = false;
  break;
  9
 10// Bitmap manager, a simplified code for ReloadAllResources():
 11void BitmapManager::ReloadAllResources()
 12{
  const int oldFlags = al_get_new_bitmap_flags();
  
  for ( ResVector::iterator iter = m_resources.begin();
      iter != m_resources.end();
      ++iter )
  {
       ALLEGRO_BITMAP *pOld = ((AllegroImage5*)iter->m_res)->GetBitmap();
       ALLEGRO_BTIMAP *pNew = 0;
       int newFlags = al_get_bitmap_flags( pOld );
       al_set_new_bitmap_flags( newFlags );
       if ( IsResourceFromFile( iter ) )
           pNew = al_load_bitmap( iter->filename.c_str() );
       else if ( !(newFlags & ALLEGRO_NO_PRESERVE_TEXTURE )) 
           pNew = al_clone_bitmap( pOld );
       else
       {
           const int w = al_get_bitmap_width( pOld );
           const int h = al_get_bitmap_height( pOld );
           pNew = al_create_bitmap( w, h );
       }
 33
       al_destroy_bitmap( pOld );
       delete iter->m_res;
       iter->m_res = new AllegroImage5( pNew );
  }
 38
  al_set_new_bitmap_flags( oldFlags );
 40}

So, what am I doing wrong? I've tried everything I could think of already.

bamccaig

Member #7,536

July 2006

I'm not really overly familiar with Allegro 5, let alone the Android port, but what stands out to me are oldFlags and newFlags. You extract the flags from the original bitmap, but you don't seem to apply them to the new bitmap. And the al_set_new_bitmap_flags doesn't appear to do anything since you just reassign the exact same flags that were already set. It's difficult to know though what Allegro does in the background with all this global state... I would have expected you to use al_set_new_bitmap_flags to temporary change the flags before creating the new bitmap and then restore the original setting at the end...

--
I mean the best with what I say. It doesn't always sound that way.

Max Savenkov

Member #4,613

May 2004

Ah, sorry, I forgot to copy that line Amended.

Edgar Reynaldo

Major Reynaldo

May 2007

Do you ever clear the new bitmaps? You create new bitmaps in the case of un-preserved textures and bitmaps not reloaded from a file. If you aren't drawing over the whole bitmaps then you could have uninitialized memory in them.

That's all I can really see as you re-load bitmaps that were from files and you clone bitmaps that don't have the NO_PRESERVE_TEXTURE flag set.

Are all your resources in m_resources bitmaps? Ie, are they all AllegroImage5 objects?

Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide
King Piccolo will make it so Then I could just flip it with some sweet, sweet matrix math. In either case, I’ll ride this wagon until the wheels fall off. Thanks to those that keep it running

Max Savenkov

Member #4,613

May 2004

Yes, they are all stored in m_resources. I do not clear NO_PRESERVE_TEXTURE bitmaps, as they are usually drawn over completely on the next frame. It's still would be more proper to clear them, of course, than to rely on that, so I'll do that.

What bothers me more, is those ALLEGRO_EVENT_DISPLAY_RESUME_DRAWING events... Why am I getting two of them, and why recreating bitmaps twice screws things up royally (compared to a common screw up that happens if I only recreated them once, during handling of the second event)? I can't find any relevant references to surfaceChanged being called twice in Google...

EDIT: I've done some digging, and it seems that I found the reason for some of my troubles. Based on attached log, I deduced the following sequence of events:

1) The game is paused, halt_drawing is acknowledged, the game goes to background
2) The game is resumed, a new Surface is created in response to onCreate, nativeOnCreate is called, resume_drawing event is posted to queue.
3) My code begins to react to resume_drawing event by re-creating bitmaps
4) SUDDENLY! In the middle of it all, a second onCreate is called in another thread! The current Surface is destroyed - but my code is in the middle of recreation of bitmaps, and has no notion that something has gone wrong. After this part, all bitmaps I try to re-create are corrupted, because they have no Surface to be created against.
5) The second resume_drawing event reaches my code. I begin to recreate bitmaps once again, but most of their data is already corrupted (?).

This explains why things looks the best when I only react to the second resume_drawing event. I couldn't discern why onCreate is called twice, but there are mentions of such behaviour here and there. It seems like it's normal behaviour on Android sometimes. So the question is, how to make Allegro handle it correctly? The main problem I see is that Surface is destroyed when my own code is in the middle of work with bitmaps. Is there any way to postpone destruction of the old Surface? I don't quite see what to do here...