[A5] al_draw_bitmap() vs al_draw_rotated

[A5] al_draw_bitmap() vs al_draw_rotated_bitmap()

TeaRDoWN

Member #8,518

April 2007

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?

Elias

Member #358

May 2000

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.

--
"Either help out or stop whining" - Evert

TeaRDoWN

Member #8,518

April 2007

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?

Arthur Kalliokoski

Second in Command

February 2005

TeaRDoWN said:

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!

They all watch too much MSNBC... they get ideas.

TeaRDoWN

Member #8,518

April 2007

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.

Arthur Kalliokoski

Second in Command

February 2005

TeaRDoWN said:

Ok, so there is a difference.

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.

They all watch too much MSNBC... they get ideas.

Thomas Fjellstrom

Member #476

June 2000

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

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

weapon_S

Member #7,859

October 2006

Elias said:

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 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

Yes well, legibility and correct punctuation might not be "street"... but that's how I roll, motherfucker. -Edward.
Yes it sounds more authoritative to invoke some cute phrase every few sentences, but it doesn't actually make an argument any more impressive. Matthew Leverton

Mark Oates

Member #1,146

March 2001

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.

Arthur Kalliokoski said:

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!

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

Thomas Fjellstrom said:

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

I think this is true.

--
Visit CLUBCATT.com for cat shirts, cat mugs, puzzles, art and more <-- coupon code ALLEGRO4LIFE at checkout and get $3 off any order of 3 or more items!

AllegroFlare • AllegroFlare Docs • AllegroFlare GitHub

weapon_S

Member #7,859

October 2006

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 ).

Raidho36

Member #14,628

October 2012

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.

Being serious is stupid, I'm done with it.