On 05/02/2012 04:57 AM, Pekka Paalanen wrote:
On Tue, 1 May 2012 20:30:15 +0100
Daniel Stone<[email protected]> wrote:
+ u = trunc(d);
+ *p = u<< 8;
+ *p |= (uint32_t) (trunc((fabs(d - u)) * (1<< 8)))&
0xff;
Hmm, any reason for not doing this instead?
*p = (int32_t)trunc(d * 256.0)
The sample code certainly looks wrong, especially if d is negative.
It is also much faster to just calculate the integer in floating point
and then do the conversion to int. On most processors this will also
translate out-of-range to max/min int.
Also, any rationale in choosing trunc() instead of round() or
ceil/floor?
I would use floor() for all graphics. Otherwise you get weird behavior
when the locations of things goes negative, because they will often
shift by 1 pixel over. Another way to look at it is that if you drew 50%
on the pixel identified by f/2 for all integers, you expect every pixel
to be drawn twice. This will happen if the pixel is floor(f/2). But if
trunc(f/2) is done pixel '0' is drawn 3 times.
The main reason you will often see shift in graphics code is because of
the desire for floor(). "i>>1" will divide by 2 but turns -3 into -2.
Of course it is an unfortunate historical accident that floating point
was designed to compile 1950's Fortran where modulus arithmetic was not
used. Otherwise I'm sure rounding would be done by floor and a%b would
have the sign of b, not a.
PS: there are also well-known tricks for converting from float->24.8
that avoid the slow fpu converter. This involves multiplying a double by
a large enough constant that all values in range have the same exponent
and the lower 32 bits are equal to the desired integer. You can check
the upper 32 bits to see if they are the correct value to detect
out-of-range. I'm not sure if these are faster on modern processors
however, and it is difficult to control the rounding.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
