acquire_bitmap(3alleg4)
β¨ acquire_bitmap β the "lock the bitmap before you draw on it" era π
okay bestie so this is a page from the Allegro manual β the Allegro game programming library β and we're talking about acquire_bitmap. it's giving low-level, it's giving "you probably don't need this", and honestly? she's a little dangerous. let's get into it π
πΈ NAME πΈ
acquire_bitmap β locks the bitmap before drawing onto it. Allegro game programming library. periodt.
π¦ SYNOPSIS π¦
#include <allegro.h>
void acquire_bitmap(BITMAP *bmp);
π DESCRIPTION π
So acquire_bitmap acquires the specified video bitmap before you draw onto it. And like β you literally never need to call this function explicitly?? it's low level, and it will only give you a speed up if you know what you are doing. Using it wrongly may cause slowdown, or even lock up your program. not cute. π
Note: you do never need to useacquire_bitmapon a memory bitmap, i.e. a normal bitmap created withcreate_bitmap. It will simply do nothing in that case. nothing. zero. nada. π
But bestie, it still can be useful, 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 this is very slow π so you will get much better performance if you acquire the screen just once at the start of your main redraw function, then call multiple drawing operations which need the bitmap locked, and only release it when done. like, one big lock, many draws, one release. main character energy only.
Multiple acquire calls may be nested, but you must make sure to 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! fr fr, do not skip this.
Note: if you are using hardware accelerated VRAM->VRAM functions, you should not callacquire_bitmap(). Such functions need an unlocked target bitmap under DirectX, so there is now just the opposite case from before β if the bitmap is already locked withacquire_bitmap, the drawing operation has to unlock it. the plot twist nobody asked for β¨
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). so the nesting counter stays unbothered, she's fine. π
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. Your best bet is to never use acquire_bitmap β chances are you are doing something in the wrong way if you think you need it. yeah. she said what she said. π
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 likeshow_mouse(orscare_mousewhich calls that) orreadkey, since it will most likely deadlock your entire program. π not the deadlock. please. do not.
π SEE ALSO π
release_bitmap(3alleg4)acquire_screen(3alleg4)release_screen(3alleg4)ex3buf(3alleg4)exaccel(3alleg4)expat(3alleg4)exquat(3alleg4)exscroll(3alleg4)exswitch(3alleg4)exupdate(3alleg4)
and that's the whole page, bestie π«Ά this was Allegro, version 4.4.3, and it's the acquire_bitmap(3alleg4) manual page β go forth, lock responsibly, and honestly? just don't use it. slay. πβ¨
π¦ where this page comes from
- debian bookworm: allegro4-doc 2:4.4.3.1-3 Β· Allegro-gift-ware
- debian trixie: allegro4-doc 2:4.4.3.1-5 Β· Allegro-gift-ware
- ubuntu jammy: allegro4-doc 2:4.4.3.1-2 Β· Allegro-gift-ware
- ubuntu noble: allegro4-doc 2:4.4.3.1-4.1build3 Β· Allegro-gift-ware
- ubuntu questing: allegro4-doc 2:4.4.3.1-6
- ubuntu resolute: allegro4-doc 2:4.4.3.1-7 Β· Allegro-gift-ware
- ubuntu stonking: allegro4-doc 2:4.4.3.1-9 Β· Allegro-gift-ware
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms