d3dx9: CloneMesh test and improvements

Matteo Bruni 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>
> wrote:
>>
>> Is it ok to use roundf and rintf? They're both C99 functions.
>
> Hello,
> As far as I know C99 is not allowed. However, you can emulate round by
> doing:
> floorf(val + 0.5f)
> According to [1] 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 [2] 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
either.

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.,
instead of
+            dst_ptr[0] = src->x < 0.0f ? (SHORT)ceilf(src->x *
SHRT_MAX + 0.5f) :(SHORT)floorf(src->x * SHRT_MAX + 0.5f);
something like
+            dst_ptr[0] = 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.

> Octavian
> [1] http://linux.die.net/man/3/floorf
> [2] http://source.winehq.org/git/wine.git/?a=search&h=HEAD&st=grep&s=floorf
>



More information about the wine-devel mailing list