I have been trying to pin down some memory leaks and I've hit a wall where I need to know more about what Allegro is doing/expecting because this isn't making sense to me. I believe I've narrowed the issue down to being alpha channel related.

I tested it on a small piece of bitmap initialization code here:

Globals.ui_sheet = al_load_bitmap(ui_sheet_file);
Globals.cursor_finger = al_create_sub_bitmap(Globals.ui_sheet, 0, 0, 14, 13);
Globals.cursor_arrow_up = al_create_sub_bitmap(Globals.ui_sheet, 0, 70, 11, 7);
Globals.cursor_arrow_right = al_create_sub_bitmap(Globals.ui_sheet, 0, 41, 12, 11);
/* Initialize a bunch more icons here....*/

al_convert_mask_to_alpha(Globals.cursor_finger, COLOR_TRANSPARENCY);
al_convert_mask_to_alpha(Globals.cursor_arrow_up, COLOR_TRANSPARENCY);
al_convert_mask_to_alpha(Globals.cursor_arrow_right, COLOR_TRANSPARENCY);
/* Convert alpha mask for all of them here...*/

al_destroy_bitmap(Globals.ui_sheet);

I've messed around with the timing of the alpha mask function and the delete function, and if I delete the parent bitmap before calling al_convert_mask_to_alpha, then I don't get the log messages saying "Release video texture failed. Release render target failed."

This is what the allegro.log file spits out when I'm initializing most of my bitmaps, and I'm not sure if it means I'm doing something wrong, but the presence of "Alpha doesn't match" also led me to think it's alpha channel related:

d3d      D         d3d_disp.cpp:1166 real_choose_bitmap_format        [   1.07354] Fake format
d3d      D         d3d_disp.cpp:1166 real_choose_bitmap_format        [   1.07359] Fake format
d3d      D         d3d_disp.cpp:1166 real_choose_bitmap_format        [   1.07363] Fake format
d3d      D         d3d_disp.cpp:1166 real_choose_bitmap_format        [   1.07367] Fake format
d3d      D         d3d_disp.cpp:1166 real_choose_bitmap_format        [   1.07370] Fake format
d3d      D         d3d_disp.cpp:1166 real_choose_bitmap_format        [   1.07374] Fake format
d3d      D         d3d_disp.cpp:1166 real_choose_bitmap_format        [   1.07377] Fake format
d3d      D         d3d_disp.cpp:1166 real_choose_bitmap_format        [   1.07381] Fake format
d3d      D         d3d_disp.cpp:1166 real_choose_bitmap_format        [   1.07384] Fake format
d3d      D         d3d_disp.cpp:1174 real_choose_bitmap_format        [   1.07388] Alpha doesn't match
d3d      D         d3d_disp.cpp:1181 real_choose_bitmap_format        [   1.07391] Adapter format is 23
d3d      D         d3d_disp.cpp:1184 real_choose_bitmap_format        [   1.07396] Found a format
d3d      I         d3d_disp.cpp:2283 _al_d3d_create_bitmap            [   1.07399] Chose bitmap format 9
dtor     D               dtor.c:184  _al_register_destructor          [   1.07486] added dtor for object 05AA1FE8, func 0055DC32

I have a last simple question: do I need to call al_destroy_bitmap on bitmaps created from al_create_sub_bitmap? From the documentation it sounded like no, but I just wanted to make sure.

This could be the cause of my memory leaks because I know I'm creating some sub bitmaps and not retaining pointers to them to be deleted later. I only added al_destroy_bitmap(ui_sheet) as a test there to see what the log would say to me. The documentation for al_create_sub_bitmap made it seem like Allegro would automatically handle memory management when I delete the parent bitmap.

Right, the documentation for al_create_sub_bitmap refers to the pixel data, but there's still some memory for each sub-bitmap to store things like its width and a pointer back to the parent bitmap, amongst a few other things.

Those would probably be indicative of bugs in Allegro, rather than in your code. Just t be clear, what version of it are you using?

5.0.10 is a bit old, and we have fixed a whole bunch of leaks since (not necessarily these though, I haven't checked). There's some MinGW binaries of the newest version towards the end of this thread https://www.allegro.cc/forums/thread/615781/1018005#target if you want to try them (and also MSVC libraries up top as well).