Is drawing a bitmap with al_draw_rotated_bitmap() with rotation 0 as "expensive" as drawing a bitmap with al_draw_bitmap()?

Same with drawing a scaled bitmap with 1:1 scale factor, is that the same thing as drawing just the bitmap or is it more expensive since scale calculations are made?

Or short question: Could we always use al_draw_tinted_scaled_rotated_bitmap_region() or should we ONLY use that when we want to draw a tinted, scaled, rotated section of a bitmap?

I'd say the difference isn't noticeable (all those functions internally call the same function).

If you need something faster you'd use al_draw_prim and draw all your bitmaps with a single call - that can skip a few steps.

So one could use any of the draw bitmap functions to draw a not tinted, rotated scaled region bitmap? Extra calculation time is "nothing" compared with using the simpliest draw bitmap function?

A couple billionths of a second here, a few billionths of a second there, after a hundred of these it adds up to a microsecond every frame!

Ok, so there is a difference. I just thought that if we say used draw_rotated_bitmap with rotation 0 it just did a normal draw_bitmap. But then I'll keep using all the different draw bitmap function as before.

I didn't look at the source, for all I know the unrotated et. al. functions just stick in some immediate zeros. My point was that the time it takes is insignificant, being that A5 doesn't run on 4.77Mhz 8088's.

Last I heard, all of the al_draw_bitmap variants were implemented with the same underlying "do it all" function.

So you'd have a: single sprite sheet, and a whole bunch of ALLEGRO_VERTEX'es, whose u and v are based on the spritesheet? And then you call al_draw_prim with ALLEGRO_PRIM_TRIANGLE_LIST? I guess you would have two triangles per sprite to make a rectangle (and not for example a single triangle encompassing the whole sprite).
Sounds like someone should write a library/add-on for that

In my experience, there is essentially no noticeable difference in optimization with switching out to the different specific drawing functions or just going with al_draw_tinted_scaled_rotated_bitmap all the time, assuming you're using hardware acceleration. At one point I did some profiling and the results supported my hunch.

In other words, if you're making a bitmap class, just go straight to al_draw_tinted_scaled_rotated_bitmap, or al_draw_tinted_bitmap wrapped in a transform.

I think the differences are significantly smaller than that. In fact, I don't think there are any relevant differences.

I think this is true.

No noticeable difference, in fact in theory the "short-hand" should be slower
If somebody feels like rewriting the code, there is IIRC one part that is redundant in the unrotated unscaled version and could be removed to "be faster". It goes something like this:

al_identity_transform(temp);
al_rotate_transform(temp, rotation);
al_scale_transform(temp, scale);
al_compose_transform(temp, current_transformation);

But I believe SiegeLord had experimented with something similar with disappointing results (from one perspective ).

I looked into the sources, and yes, it's all done through the same function. The underlying is done with two matrix-transformed glTriangles with texture coordinates and color data in them that would form a sprite, hardware accelerated case. So my guess is that it's just for the sake of convenience. Default arguments or not, for most of the cases you will need to specify most of the arguments if you stick to one single master function. It doesn't help if you just use 0 or 1 with anything you don't currently need if there's like dozen arguments to pass, which is the case.