exsprite(3)
β¨ exsprite π
okay bestie, welcome to the Allegro manual β specifically the page for exsprite, which is a demo program in the Allegro game programming library. it's giving "datafiles access and sprite animation" and honestly? iconic. π
π¦ NAME π¦
exsprite β datafiles access and sprite animation, from the Allegro game programming library. that's it, that's the whole vibe. π
πΈ SYNOPSIS πΈ
#include <allegro.h>
Example exsprite
yes babe, that's the entire synopsis. it's an example, not a function. no arguments, no return value, just vibes and a datafile. π«Ά
β¨ DESCRIPTION β¨
so what is this example even doing? it's showing you how to use datafiles, a bunch of different sprite drawing routines, and flicker-free animation. all three. at once. main character energy fr fr. π
π why is animate() coded like that tho?
bestie, you're probably wondering why the animate() routine is written that way. and ngl, it's a whole thing. as you probably know, VIDEO RAM is much slower than "normal" RAM, so it's advisable to reduce VRAM blits to a minimum. drawing a sprite on the screen (meaning in VRAM) and then clearing a background for it is not very fast. not it. π
this example uses a different method which is much faster, but it requires a bit more memory. tradeoffs, bestie, tradeoffs.
here's the tea, step by step:
- first the buffer is cleared β and it's a normal
BITMAP, not VRAM, okay? - then the sprite is drawn on it.
- and when the drawing is finished, this buffer is copied directly to the screen.
so the end result? there's a single VRAM blit instead of blitting/clearing the background and drawing a sprite on it. so efficient. so slay. β¨ it's a good method even when you have to restore the background. and of course, it completely removes any flickering effect. periodt. π
π§ the big background situation
when one uses a big (ie. 800x600 background) and draws something on it, it's wise to use a copy of background somewhere in memory and restore background using this "virtual background". the way that works is lowkey genius. when blitting from VRAM in SVGA modes, it's probably that drawing routines have to switch banks on video card. and I think I don't have to remind you how slow is it. π switching banks? in this economy?
β οΈ okay but modern systems tho
note that on modern systems, the above isn't true anymore, and you usually get the best performance by caching all your animations in video ram and doing only VRAM->VRAM blits, so there is no more RAM->VRAM transfer at all anymore. and usually, such transfers can run in parallel on the graphics card's processor as well, costing virtually no main cpu time at all. π₯
see the exaccel example for an example of this. go look at it, bestie, it's the glow-up version. π
π SEE ALSO π
the whole friend group, in order, no one left out:
BITMAP(3)DATAFILE(3)END_OF_FUNCTION(3)END_OF_MAIN(3)LOCK_FUNCTION(3)LOCK_VARIABLE(3)SCREEN_H(3)SCREEN_W(3)allegro_error(3)allegro_init(3)allegro_message(3)blit(3)circle(3)clear_bitmap(3)clear_keybuf(3)create_bitmap(3)destroy_bitmap(3)draw_sprite(3)draw_sprite_h_flip(3)draw_sprite_v_flip(3)draw_sprite_vh_flip(3)fixed(3)font(3)hline(3)install_int_ex(3)install_keyboard(3)install_sound(3)install_timer(3)itofix(3)key(3)keypressed(3)load_datafile(3)makecol(3)palette_color(3)pivot_sprite(3)pivot_sprite_v_flip(3)play_sample(3)rectfill(3)replace_filename(3)rest(3)screen(3)set_gfx_mode(3)set_palette(3)text_height(3)textout_centre_ex(3)unload_datafile(3)vsync(3)
and that's the page, bestie!! this whole thing is from Allegro, version 4.4.3 β the exsprite(3) page, section 3 of the manual, iykyk. π¦ go forth and blit responsibly. mwah. π
π¦ where this page comes from
- fedora 43: allegro-devel 4.4.3.1-18.fc43 Β· Giftware
- fedora 43: allegro-devel 4.4.3.1-18.fc43 Β· Giftware
- fedora 44: allegro-devel 4.4.3.1-20.fc44 Β· Giftware
- fedora 44: allegro-devel 4.4.3.1-20.fc44 Β· Giftware
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms