From: mert0407 AT sable DOT ox DOT ac DOT uk (George Foot)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Allegro sprite rotation
Date: Thu, 06 Feb 1997 07:40:09 GMT
Organization: Oxford University
Lines: 56
Message-ID: <32f9797e.53712819@news.ox.ac.uk>
References: <5c6mh9$2c2k AT elmo DOT cadvision DOT com> <LukhsKANVg6yEwCT AT talula DOT demon DOT co DOT uk> <5dbb9b$m2u$1 AT troll DOT powertech DOT no>
NNTP-Posting-Host: mc31.merton.ox.ac.uk
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

On Thu, 06 Feb 1997 01:17:51 GMT, ovek AT arcticnet DOT no (Ove Kaaven)
wrote:

>Shawn Hargreaves <Shawn AT talula DOT demon DOT co DOT uk> wrote:
>
>>I've also heard mention of a rotation algorithm based on shearing the
>>image first horizontally and then vertically, which can rotate by up to
>>45 degrees (flips can then be used for the other 7 octants). I've never
>>tried implementing this: does anyone have any experience of it? Could it
>>be faster than my line-tracing method?
>
>As far as I know, this can't be done accurately by shearing only
>twice, however it is fully possible by doing it three times. I think
>I've seen rotation reduced to three "skewings" in some mathematics
>book or something.
>
>Maybe it's possible with only two shears, though, but this would most
>certainly get the scale wrong. I suppose two shears and one scaling is
>more expensive than three shears, so I don't think I would try to get
>that to work unless I would have to scale anyway.

>PS. I decided to exercise my algebra, here's my results.

Always a good idea :)

>I think we get (correct me if I'm wrong)
>
>s1 = (1-cos(v))/sin(v)
>s2 = -sin(v)
>s3 = (1-cos(v))/sin(v) = s1

I did the same thing using matrices, and got the same result (but with
opposite signs - this is due to differing shearing techniques).

Personally, though, I think Shawn's present technique would be much
faster. It is a little inefficient, though, in that it traces the
entire bounding box of the destination, rather than just the
parallelogram that the sprite maps onto. You might consider using
Bresenham's algorithm to only scan the destination area which will be
drawn to, rather than scaning its entire bounding box.

Unless, of course, you've already tried this and found it more
efficient how it is already... Anyway, I'm going to write one for
myself and see. If it's better (i.e. faster) than yours, I'll get back
to you.

>If you want to go for two skews and one scaling, I think we get:
>
>s1 = sin(v)/cos(v)
>s2 = -sin(v)*cos(v)
>scaleX = cos(v)
>scaleY = 1/cos(v)

Yes, this works, but still suffers from the same problem. I think.

George Foot