The ddraw tests don't compile with Visual C++ 2005.

[Francois Gouget]

Visual C++ 2005 does not like the way we compute the infinity and NaN 
values. I've tried replacing the current divisions by zero with 
arithmetic on FLT_MAX (at least for the infinity calculations), but it 
did not like that either.

Does anyone know how to make these calculations portable?
How does one get at these values on Windows?


diff --git a/dlls/ddraw/tests/d3d.c b/dlls/ddraw/tests/d3d.c
[...]
     light.dvAttenuation0 = -1.0 / 0.0; /* -INFINITY */
[...]
     light.dvAttenuation0 = 1.0 / 0.0; /* +INFINITY */
[...]
     light.dvAttenuation0 = 0.0 / 0.0; /* NaN */



-- 
Francois Gouget <fgouget(a)free.fr>              http://fgouget.free.fr/
                            1 + e ^ ( i * pi ) = 0

[Stefan Dösinger]

Am Sonntag 27 Mai 2007 13:17 schrieb Francois Gouget:
> Visual C++ 2005 does not like the way we compute the infinity and NaN
> values. I've tried replacing the current divisions by zero with
> arithmetic on FLT_MAX (at least for the infinity calculations), but it
> did not like that either.
>
> Does anyone know how to make these calculations portable?
> How does one get at these values on Windows?
> Does it like less obvious calculations, like
> float one = 1.0;
> float zero = 0.0;
> float infinity = one / zero;
> float nan = zero / zero;

I couldn't find any usable way of getting a NaN and INF, only the test for it 
via isNaNf. The same problem will occur in d3d8 and d3d9 I think.

[Marcus Meissner]

On Sun, May 27, 2007 at 01:17:23PM +0200, Francois Gouget wrote:
> Visual C++ 2005 does not like the way we compute the infinity and NaN 
> values. I've tried replacing the current divisions by zero with 
> arithmetic on FLT_MAX (at least for the infinity calculations), but it 
> did not like that either.
>
> Does anyone know how to make these calculations portable?
> How does one get at these values on Windows?
>
> diff --git a/dlls/ddraw/tests/d3d.c b/dlls/ddraw/tests/d3d.c
> [...]
>      light.dvAttenuation0 = -1.0 / 0.0; /* -INFINITY */
> [...]
>      light.dvAttenuation0 = 1.0 / 0.0; /* +INFINITY */
> [...]
>      light.dvAttenuation0 = 0.0 / 0.0; /* NaN */

Why doesn't the code try using the INFINITY and NAN #defines?
Would this help with Visual C++?

Ciao, Marcus

[Francois Gouget]

On Sun, 27 May 2007, Marcus Meissner wrote:
[...]
> Why doesn't the code try using the INFINITY and NAN #defines?
> Would this help with Visual C++?

Do you mean the INFINITY macro defined in /usr/include/bits/inf.h? 
(which one gets through math.h)

I have not found any macro called INFINITY in the PSDK or the 
Visual C++ headers. So this would not work.

Visual C++'s math.h header has a _HUGE and a HUGE symbol that look like 
they could be +INFINITY but this would not work in Wine (Winelib apps 
cannot import exported variables).

-- 
Francois Gouget <fgouget(a)free.fr>              http://fgouget.free.fr/
                              145 = 1! + 4! + 5!

[Kuba Ober]

On Sunday 27 May 2007, Francois Gouget wrote:
> On Sun, 27 May 2007, Marcus Meissner wrote:
> [...]
> > Why doesn't the code try using the INFINITY and NAN #defines?
> > Would this help with Visual C++?
>
> Do you mean the INFINITY macro defined in /usr/include/bits/inf.h?
> (which one gets through math.h)
>
> I have not found any macro called INFINITY in the PSDK or the
> Visual C++ headers. So this would not work.
>
> Visual C++'s math.h header has a _HUGE and a HUGE symbol that look like
> they could be +INFINITY but this would not work in Wine (Winelib apps
> cannot import exported variables).

Isn't it possible to have some wine-local constants for them?

Such as:

const union {
        unsigned int i;
        float f;
}
        WINE__INF32 =  { 0x7F800000 },
        WINE__NINF32 = { 0xFF800000 },
        WINE__NAN32 =  { 0x7F800001 };

const union {
        unsigned long long int i;
        double d;
}
        WINE__INF64 =  { 0x7FF0000000000000LL },
        WINE__NINF64 = { 0xFFF0000000000000LL },
        WINE__NAN64 =  { 0x7FF0000000000001LL };

#define WINE_F_INF  (WINE__INF32.f)
#define WINE_F_NINF (WINE__NINF32.f)
#define WINE_F_NAN  (WINE__NAN32.f)
#define WINE_INF    (WINE__INF64.d)
#define WINE_NINF   (WINE__NINF64.d)
#define WINE_NAN    (WINE__NAN64.d)

I don't know how that plays with endianness, but that's for someone else to 
figure out :) Where no LL suffix (or no long long) is supported, we can have 
a struct of two ints instead of a long long int member.

Cheers, Kuba