panda changes calcul behavior on vista 64 ?

Scripting Issues
1

Hi,

I have a strange thing on Vista 64. When I start python and do a calculation, the result is slightly different before and after starting panda.
On a simple calcul, like this one :

a = 0.1
for i in range(10) :
    print a
    a += 0.1
import direct.directbase.DirectStart
b = 0.1
for i in range(10) : 
    print b
    b += 0.1

I have the result

Like you see, the result is slightly different.
On a simple calculation like this, it doesn’t matter. But the problem is bigger for bigger calculation like this one (it’s using Polygon library) :

from Polygon import Polygon as Pol

p1 = Pol([(468.53778076171875, 492.2611083984375), (510.03778076171875, 492.2611083984375), (510.03778076171875, 536.7611083984375), (468.53778076171875, 536.7611083984375)])
print p1.center()
import direct.directbase.DirectStart
print p1.center()

the error can’t be ignore cause the result is :

The center’s position is wrong 3 digits after the comma and with a big difference !!!

By digging a little, I found the calculation mistake occurs right after the line

        self.pipe = selection.makeDefaultPipe()

in direct.showbase.Showbase, in makeDefaultPipe on line 461.
Right before the makeDefaultPipe call, the calculation is correct, but after, the calculation is wrong.

So I’d like to know if this behavior is expected on a 64 bit system, or is it a bug ?
Cause all works really well on a 32 bits system (tested on linux, XP or Vista).

If anybody has a clue on how to solve this, I would be very grateful.

2

This is a DirectX thing. When you start a DirectX graphics context, it forces the FPU into single-precision mode. This means that all of your calculations from then on are performed in single-precision, even if they are doubles! It’s a terrible, terrible nuisance, and I haven’t found a way around it. There’s a bit that you’re supposed to be able to set to ask it not to do that. We’re setting it, and it has no effect.

So, short answer is, you have to live with single-precision, or use OpenGL instead.

David

3

Thanks for the answer.

But I’m already using Opengl. I have the line

load-display pandagl

in my config.prc.

Is there something else to add in order to disable directx ?

4

No, that should be sufficient. You can confirm that you’re running in OpenGL by checking base.win.getType(). Maybe it’s something peculiar to your particular graphics driver, then? I’ve never seen an OpenGL driver that does this FPU mangling, but it’s certainly possible.

David

5

If I check base.win.getType(), it says wglGraphicsWindow

The graphic card is a Radeon HD 4800.

6

After several tests, I finally manage to find the configuration which has this problem. It only occurs when it is :
[b] - Windows Vista 64 bits

  • ATI graphic card[/b]

I tried the latest drivers without success. :confused:

On the same computer, I replaced the ATI card with an NVIDIA card and it’s working.
I tried on another computer which has windows xp 32 bits and an ATI card and it’s working.
The only test I haven’t made is a Vista 32 bits with an ATI card.

I also tried the latest Panda version and this bug is still here.

So, do I have to hope for better ATI Driver’s or is there a tricky thing which could help to make it work ?

7

I tried with the tinydisplay option in the new panda version and the problem occurs with both configuration (ATI or nvidia) on Vista 64. Didn’t try yet on a 32 bits.

8

I’m just wondering, but I just noticed that winDetectDx.h in get_display_information (Yuck, why is there source code in the header file?) calls CreateDevice without setting that bit. But if I get this right, get_display_information is always invoked, even in OpenGL mode, am I wrong?
Could it be the problem that this forces the FPU into single-precision mode anyways (maybe a second CreateDevice call with that bit set doesn’t change it back)?
An easy way to find out would be to test running with:

request-dxdisplay-information #f
9

For 1.7.0 this fixes the problem. It now seems to work correctly with Direct X, too.

10

Egad. It sounds like this really is the source of the problem, and it has been all along.

Good find!

David

11

All right! :slight_smile: I just checked in a proper (though untested) fix, will be in 1.7.1.

12

Oh, great. Thanks a lot.