"breaking up" of rotated/scaled OBJs is not due to fixed point rounding
error, it's due to the unpredictability of the pixels that get lit in the
hardware operations related to rasterization.

predicting rotscal OBJ placement is non-trivial. because OBJs can only be
positioned on full pixel boundaries (unlike rotscal BG layers), but the
result of a pixel stride scale may result in a "partial" pixel coming out of
the hardware (which will not get lit), an adjoining OBJ may be drawn with a
1-pixel gap relative to the other. the problem is exacerbated when sprites
are rotated. i learned this the hard way in thps2, when i tried to make the
main menu wheel out of 4 rotscal 64x64 OBJ. i never could get it to
perfectly line up without gaps. of course then i stopped being stupid and
changed to using a BG layer. ;)

the best solution we have come up with takes advantage of the following
property of rotscal OBJ: because of the rasterization process the OBJ
hardware uses for scaling (successive addition), there can only ever be a
maximum of 1 pixel gap between OBJ. so in our sprite tool, we simply
overlap OBJ boxes by 1 pixel. this obviously increases the amount of memory
required to store the pixel data, but realistically this isn't a very large
percentage. and we're using the image best compression available: 4-bit
sprite data. :-D

regards,
matthew.

----- Original Message -----
From: "alex mole" <nal@...>
To: <gbadev@yahoogroups.com>
Sent: Saturday, November 08, 2003 10:32 AM
Subject: Re: [gbadev] Digest Number 1241


> i would normally just use the following to round while shifting down
>
> c = (c + (1<<7)) >> 8;
>
> mathematically, this is like 'floor(x + 0.5)', which rounds x to the
> nearest integer
>
> and it saves one whole AND operation and a temporary register! ;)
> ok, so it's pretty minimal, but like Dan said, sometimes you gotta be
> frugal ;)
>
> i think it also makes it better for Arm code optimisation as [IIRC] you
> can do the above in one instruction [though it's been a while so you
> might need to correct me on that].
>
>
> alex:)
>
>
>
> Dan Posluns wrote:
> > On Saturday, November 8, 2003, at 04:57 AM, gbadev@yahoogroups.com
> > wrote:
> >
> >
> >>BTW, do to weird round off, when we rotate/scale a multi-part sprite
> >>around, the sprite tends to break up a little. Have you guys
> >>figured out the trick to fixing this?
> >
> >
> > If it is, in fact, round-off that is causing your error, you can make
> > sure that your fixed-point calculations are rounded to the nearest
> > value instead of truncated when you shift off any of the fractional
> > portion.
> >
> > For example, say I multiply two 24.8 numbers:
> >
> > c = a * b; // c is now 16.16
> >
> > In order to reduce it back to 24.8, I would normally do the following:
> >
> > c >>= 8;
> >
> > To make sure the number is rounded instead of just truncated, I can
> > mask out everything except the 7th bit of the number, and then add it
> > to the original number before shifting:
> >
> > c += (c & (1 << 7)); // (1 << 7) is (0000 0000 0000 0000 0000 0000 1000
> > 0000)b
> > c >>= 8;
> >
> > If you round off your calculations as you go instead of just
> > truncating, I find it tends to significantly reduce those minor screen
> > errors. Now the only trick is figuring out which calculations can
> > benefit from the rounding process and which calculations it is wasted
> > cycles for. (This shouldn't have to be a consideration if you are only
> > doing it once per frame, but if like me you are doing these
> > calculations in a tight inner loop you need to be much more frugal with
> > your cycles.)
> >
> > Dan.
> >
> > --
> > Dan Posluns, B. Eng. & Scty. (Software Engineering and Society)
> > dan@... - ICQ: 35758902
> > http://www.danposluns.com
> >
> > "Only when the last tree has been cut down, only when the last river
> > has been poisoned, only when the last fish has been caught - only then
> > will you realize that money cannot be eaten."
> > - Cree prophecy
> >
>
>
>
> ________________________________________________________________________
> This email has been scanned for all viruses by the MessageLabs Email
> Security System. For more information on a proactive email security
> service working around the clock, around the globe, visit
> http://www.messagelabs.com
> ________________________________________________________________________
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>