[A5] Loading Bitmaps while al_hold_bitmap_drawing() is Engaged
Kris Asick

Very simple question: Can you load bitmaps into video memory while al_hold_bitmap_drawing() is engaged, or is this a very bad idea?

If this isn't possible, I can work around it thanks to al_is_bitmap_drawing_held(), but it would still be nice to know ahead of time. I'm the midst of coding an automatic texture handling system for my game and it just occurred to me that deferred drawing may be going on when texture load requests automatically happen.

Todd Cope

I don't see how it could cause a problem, as no rendering occurs until you call al_hold_bitmap_drawing(false). Deferred rendering just builds up a list of vertices and dumps them to the screen when you make that call or attempt to draw something that uses a different texture.

Kris Asick

Well, I'm going by this little snippet from the A5 manual: "While deferred bitmap drawing is enabled, the only functions that can be used are the bitmap drawing functions and font drawing functions."



I think that Todd is right from guesswork and logic, but your complain is founded.

Reading from the documentation, it seems implied tha not only blender and render state can't be changed but also loading bitmaps.


I'd follow the recommendation in the manual. In principle we could audit the other functions and see if they continue to work while bitmap drawing is deferred, but until that's done, I'd make no guarantees. In particular, nothing stops the bitmap loaders from using drawing functions as part of loading (e.g. al_put_pixel).

Kris Asick

*nods* Given the fact that loading only has to happen once per main texture file unless it's unloaded again at some point, I think erring on the side of caution would be the better approach. Disabling and re-enabling deferred drawing automatically is simple enough and I don't think the average person is going to notice or care if their framerate drops for a fraction of a second when they're first starting up the gameplay. ;)

I'm designing my texture handling system so that I can manually buffer in textures ahead of time if necessary, but for the most part, it will wait until a particular sub-texture is accessed, at which point it loads in the main texture file and parses it into its individual sub-textures. Unloading has to be done manually though, but the system is smart enough not to accidentally load anything twice, or attempt to unload anything which is already unloaded.

I'm building all kinds of generic foundation code right now so that any time I go to make a game in the future I won't have to re-write all this stuff again and again! 8-)


I agree, not knowing precisely if there would be any effect...errig on the cautious side is okay.

I actually didn't think that loading functions could access drawing functions.

Side question: is it (at least in theory) possible to register a custom bitmap loader that takes care of drawing hold status?

Thread #614717. Printed from Allegro.cc