Smalltalk - Pre-rotated sprites not faster than rotating "on the fly"?

Author

Pre-rotated sprites not faster than rotating "on the fly"?

enigmainorlando@aol.com

2006-04-17, 7:05 pm

Have been developing an application which uses custom sprites to draw
animated objects on the screen. It's just basic graphics stuff.
Objects must rotate, translate, etc.

Originally, I was using the "standard" approach of rotating sprites
using a transformation matrix. To improve performance, I (just last
night) developed a "pre-rotated" sprite class, which prerotates and
stores all the shapes in a dictionary (keyed by the angle of rotation).
Much to my surprise, after profiling today, the prerotated version is
not only not faster, it is actually slightly slower.

Is anyone surprised by this? Does anyone have an explanation?

Thanks.

Ian Upright

2006-04-18, 7:07 pm

enigmainorlando@aol.com wrote:

>Have been developing an application which uses custom sprites to draw
>animated objects on the screen. It's just basic graphics stuff.
>Objects must rotate, translate, etc.
>
>Originally, I was using the "standard" approach of rotating sprites
>using a transformation matrix. To improve performance, I (just last
>night) developed a "pre-rotated" sprite class, which prerotates and
>stores all the shapes in a dictionary (keyed by the angle of rotation).
> Much to my surprise, after profiling today, the prerotated version is
>not only not faster, it is actually slightly slower.
>
>Is anyone surprised by this? Does anyone have an explanation?
>
>Thanks.

How are you storing the shapes? As a bitmap, as opposed to line drawing,
or? For starters, it could be the overhead involved in using a bitmap, if
that is what you are doing.. You certainly have not provided enough details
here to give a good explanation as to what might be going on.

Ian

---
http://www.upright.net/ian/

enigmainorlando@aol.com

2006-04-18, 7:07 pm

Ian Upright wrote:

> How are you storing the shapes? As a bitmap, as opposed to line drawing,
> or? For starters, it could be the overhead involved in using a bitmap, if
> that is what you are doing.. You certainly have not provided enough details
> here to give a good explanation as to what might be going on.

Ian, you are right in that I (purposefully) did not provide many
details. Mainly, I didn't want to glaze anyone's eyes over, and I
suppose I thought there was a chance that graphics gurus out there
might have run into this thing a thousand times before, and would be
able to provide a "most likely explanation" in a "quick and dirty"
style, i.e. "Sonny, us old-timers ran into this years ago as novices.
What is happening is...."

A while back I switched over to drawing all the sprites with Jun,
storing them as Jun2dPolygons. What I suspect is happening is this:
Even though I grab a prerotated polygon from the dictionary, I still
have to translate it using "translatedBy: aPoint." I'm suspecting
that, internally, Jun takes this and convets it into a transformation
matrix ANYWAY (what I just got away from), and then applies the
transformation to translate the polygon. If so, it means that the
prerotated polygon will not be any faster because it's undergoing a
transformation ANYWAY, so it might as well not be prerotated, as
prerotation under this scheme (if this is what is happening) would not
be buying me anything.

Anyway, I suspect that is what is going on. If anyone can confirm, let
me know. Either way, I don't know how I can solve that problem. Might
just be a bottleneck I have to live with.

Thanks.

Sponsored Links