al_get_parent_bitmap(3alleg5)

πŸ“¦
version 5.2.11.3 Β· 4 versions
, in debian trixie, ubuntu questing, ubuntu resolute, ubuntu stonking

✨ NAME ✨

al_get_parent_bitmap β€” the Allegro 5 API function that finds your bitmap's ✨actual✨ parent, no cap πŸ’–


πŸŽ€ SYNOPSIS πŸŽ€

#include <allegro5/allegro.h>

ALLEGRO_BITMAP *al_get_parent_bitmap(ALLEGRO_BITMAP *bitmap)

πŸ¦‹ DESCRIPTION πŸ¦‹

okay so bestie, listen πŸ‘‘ β€” you hand it a bitmap, and it gives you back the bitmap that this bitmap is a sub-bitmap of. That's it. That's the whole vibe.

  • If your bitmap is not a sub-bitmap? You get NULL. Simple. πŸ’…
  • This function always returns the real bitmap, and never a sub-bitmap. lowkey the most important thing here.
🚨 and this is the part that gets people: what you get back might NOT match what was passed to al_create_sub_bitmap(3alleg5). fr fr. don't assume.

Consider this code, for instance:

ALLEGRO_BITMAP* a = al_create_bitmap(512, 512);
ALLEGRO_BITMAP* b = al_create_sub_bitmap(a, 128, 128, 256, 256);
ALLEGRO_BITMAP* c = al_create_sub_bitmap(b, 64, 64, 128, 128);
ASSERT(al_get_parent_bitmap(b) == a && al_get_parent_bitmap(c) == a);

so b is a sub-bitmap of a, and c is a sub-bitmap of b… but look at that assertion πŸ‘€ it says al_get_parent_bitmap(c) == a, NOT == b. And the assertion will pass! 🌟

Why? Because only a is a real bitmap, and both b and c are its sub-bitmaps. The way the chain just collapses back to the original real one β€” it's giving generational parent energy πŸŒˆπŸ’€

So like. b's parent is a. c's parent is also a. Periodt. πŸ’–


🌸 SINCE 🌸

5.0.6, 5.1.2 β€” she's been iconic for a minute 🫢


⭐ SEE ALSO ⭐


and that's the whole page bestie!! this one's from the Allegro reference manual, covering al_get_parent_bitmap(3alleg5) πŸ’œ go forth and parent-check your bitmaps responsibly 🧚✨

πŸ“¦ where this page comes from