acquire_bitmap(3)

💖 acquire_bitmap(3) — the Allegro manual, but make it slay ✨

okay bestie, gather round, we're talking about acquire_bitmap from the Allegro game programming library 🎀 this one is lowkey a menace and highkey only for the brave, so listen up 💅

---

✨ NAME ✨

acquire_bitmap — locks the bitmap before drawing onto it. Allegro game programming library. that's the whole vibe 🫶

---

🌸 SYNOPSIS 🌸

#include <allegro.h>

void acquire_bitmap(BITMAP *bmp);

---

💜 DESCRIPTION 💜

So acquire_bitmap acquires the video bitmap you pass in, before you draw onto it. and like… you literally never need to call it yourself, because it's a low-level function and the only thing it gives you is a speed boost — and only if you actually know what you're doing. use it wrong and you get a slowdown, or your program just fully locks up 💀 not cute.

Note: you never ever need to use acquire_bitmap on a memory bitmap, i.e. a normal bitmap you made with create_bitmap. in that case it just… does nothing. iconic behavior honestly, zero notes 🌈

It still can be useful though, because — for example — under the current DirectDraw driver of Allegro, most drawing functions need to lock a video bitmap before drawing to it. but doing that is very slow, so you get much better performance if you acquire the screen just once at the start of your main redraw function, then call multiple drawing operations that need the bitmap locked, and only release it when you're done. one lock, many draws, big brain energy 🧠✨

Multiple acquire calls may be nested, but you have to make sure you match up the acquire_bitmap and release_bitmap calls. ⚠️ and be warned: DirectX and X11 programs activate a mutex lock whenever a surface is locked, which prevents them from getting any input messages — so you must be sure to release all your bitmaps before using any timer, keyboard, or other non-graphics routines! like, fr fr, do not skip that part 🙈

Note: if you're using hardware accelerated VRAM->VRAM functions, you should not call acquire_bitmap(). those functions need an unlocked target bitmap under DirectX, so now it's just the opposite case from before — if the bitmap is already locked with acquire_bitmap, the drawing operation has to unlock it. messy, I know 😭

Note: for backwards compatibility, the unlocking behavior of such functions is permanent. that is, if you call acquire_bitmap first, then call e.g. an accelerated blit, the DirectX bitmap will be unlocked internally (it won't affect the nesting counter of acquire/release calls). the way that it just… stays unlocked? yeah. that's the deal 💅

There is no clear cross-platform way in this Allegro version to know which drawing operations need a locked/unlocked state. for example a normal rectfill most probably is accelerated under DirectX, and therefore needs the screen unlocked — but an XOR rectfill, or one with blending activated, most probably is not, and therefore locks the screen. and while the DirectX driver will do automatic unlocking, there is no such thing under X11, where the function is used to synchronize X11 calls from different threads. so your best bet is to never use acquire_bitmap — chances are you're doing something in the wrong way if you think you need it 👑 (and that's on periodt.)

Warning: this function can be very dangerous to use, since the whole program may get locked while the bitmap is locked. so the lock should only be held for a short time, and you should not call anything but drawing operations onto the locked video bitmap while a lock is in place. especially don't call things like show_mouse (or scare_mouse, which calls that) or readkey, since it will most likely deadlock your entire program 😭💀 like bestie I am BEGGING you

---

🦋 SEE ALSO 🦋

• release_bitmap(3)
• acquire_screen(3)
• release_screen(3)
• ex3buf(3)
• exaccel(3)
• expat(3)
• exquat(3)
• exscroll(3)
• exswitch(3)
• exupdate(3)

---

and that's the whole page, bestie!! this was Allegro, version 4.4.3, and acquire_bitmap(3) — now go release your bitmaps before you touch a timer, I'm serious 💖✨🎀 mwah 🫶