d3dx9: CloneMesh test and improvements
matteo.mystral at gmail.com
Fri Aug 12 07:07:21 CDT 2011
2011/8/12 Octavian Voicu <octavian.voicu at gmail.com>:
> On Fri, Aug 12, 2011 at 12:59 PM, Michael Mc Donnell <michael at mcdonnell.dk>
>> Is it ok to use roundf and rintf? They're both C99 functions.
> As far as I know C99 is not allowed. However, you can emulate round by
> floorf(val + 0.5f)
> According to  floorf is C99 (only floor is C89), but including math.h in
> wine actually gives you msvcrt's math.h which is a bit different and doesn't
> even have round nor rint. Gdiplus uses floorf  so it should be OK.
No, we are still using "native" math library in wine dlls (actually,
linking wine dlls to msvcrt is usually frowned upon), so those floorf
calls go directly to libm. Anyway, if you look into wine msvcrt's
code, floorf doesn't do anything else than directly calling native
floorf (and without any #ifdef guard, as far as I can see), so it
wouldn't really make a difference.
That said, I don't know what is allowed and what's not. Requiring
rintf or roundf support doesn't seem really asking more than what is
needed now, but you could argue that we shouldn't use floorf in wine
BTW, as you are actually rounding to convert a float to an integer
type (as opposed to needing a rounded value still in a floating point
variable), you can also avoid using floorf() altogether. So, e.g.,
+ dst_ptr = src->x < 0.0f ? (SHORT)ceilf(src->x *
SHRT_MAX + 0.5f) :(SHORT)floorf(src->x * SHRT_MAX + 0.5f);
+ dst_ptr = src->x < 0.0f ? (SHORT)(src->x * SHRT_MAX -
0.5f) :(SHORT)(src->x * SHRT_MAX + 0.5f);
still works, since C floating point to integer conversion rules
mandate for truncation.
>  http://linux.die.net/man/3/floorf
>  http://source.winehq.org/git/wine.git/?a=search&h=HEAD&st=grep&s=floorf
More information about the wine-devel