freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Devel] Error in new FT_SqrtFixed?


From: David Turner
Subject: Re: [Devel] Error in new FT_SqrtFixed?
Date: Fri, 27 Apr 2001 11:40:59 +0200

> 
> OK, I did some more investigative footwork.
> 
> I used David's supplied test_bbox.c file, but I made a change.  He was used
> the following:
> 
> #define  XSCALE    1000
> #define  XX(x)     ( (FT_Pos)( x * XSCALE ) )
> #define  XVEC(x,y) { XX(x), XX(y) }
> #define  XVAL(x)   ( ( x ) / ( 1.0 * XSCALE ) )
> 
>   static FT_Vector  dummy_vec_1[4] =
>   {
>     XVEC( 408.9111, 535.3164 ),
>     XVEC( 455.8887, 634.396  ),
>     XVEC( -37.8765, 786.2207 ),
>     XVEC( 164.6074, 535.3164 )
>   };
> 
> I used:
> 
> #define  XVAL(x)   ( (x) / 65536.0 )
> 
>   static FT_Vector  dummy_vec_1[4] =
>   {
>     { (FT_Int32)0x0198E93DL , (FT_Int32)0x021750FFL },  /* 408.9111, 535.3164 
> */
>     { (FT_Int32)0x01C7E312L , (FT_Int32)0x027A6560L },  /* 455.8887, 634.3960 
> */
>     { (FT_Int32)0xFFDA1F9EL , (FT_Int32)0x0312387FL },  /* -37.8765, 786.2207 
> */
>     { (FT_Int32)0x00A49B7EL , (FT_Int32)0x021750FFL }   /* 164.6074, 535.3164 
> */
>   };
>

Well, you could have obtained the same result by simply changing

  #define  XSCALE  1000
to
  #define  XSCALE 65536

:-)
 
> As you can see, I used a full 16.16 representation.  That is where the problem
> lie.  If I changed the code back to what David originally supplied, I got the
> correct results.
> 
> If I use my changes, the bounding box for that curve is way off.
> 
> The problem is in the new bbox calculation code.  I made a change so that each
> of a, b, and c are shifted right by 8 bits.  I then got the correct results.
>

I've just commited the fix. Actually, there were two really silly
bugs in the coefficient normalisation code:

  - first of all, the code didn't normalize to 8.16 numbers, but to
    9.16, which could have caused overflows for very large input
    polynoms..

  - second, when shifting to the right, the value of "shift" was
    negative and applied to "a", "b", "c" as in "a >>= shift".
    later resulting in invalid values for the zeroes..

The new code seems to handle well your 16.16 examples now..

- David



reply via email to

[Prev in Thread] Current Thread [Next in Thread]