directx9 kills pythons time module?

Hi,

I’ve noticed a very weird behavior when using panda in dx9 mode.
Once I’ve started via direct start (in other words, once the graphics window is open) in dx9 mode, pythons time.time function doesn’t work anymore.
Consider the following session log:

>>> import time
>>> time.time()
1222848501.187
>>> time.time()
1222848506.0539999
>>> time.time()
1222848507.5829999
>>> time.time()
1222848508.6440001
>>> import direct.directbase.DirectStart
DirectStart: Starting the game.
Warning: DirectNotify: category 'Interval' already exists
Known pipe types:
  wdxGraphicsPipe9
(all display modules loaded.)
:util(warning): Adjusting global clock's real time by 6.67572e-006 seconds.
>>> time.time()
1222848512.0
>>> time.time()
1222848512.0
>>> time.time()
1222848512.0
>>> time.time()
1222848512.0

As you can see, time.time returns a changing (constantly growing) value. But as soon as I initialized the dx9 device, the value it returns is constant without and has no precision after the decimal point.

If I do the same in OpenGL mode, everything works fine.

I’ve reproduced this with panda 1.4.2 and 1.5.3 on both vista and xp.
I have a hunch that it has something todo with DX9 fiddling with the FPU settings without properly restoring them.
If that IS causing the problem, panda could save/restore the FPU controlword at the DX boundaries, but that’s probably a slight performance hit.

I have workarounds around this problem, but I wanted to share this with others nevertheless.

Any comments?

Cheers,

Erik

Yes, it appears that DX9 forces the FPU into single-precision mode, even if we ask it not to do this. This ruins things like time.time(), which return a number outside of single-precision range. This has always been vexing. (This is part of the reason that globalClock.getFrameTime() returns elapsed time since the application begins instead of elapsed time since 1972, since that keeps it within single-precision range. For precision timings in a Panda app, you probably want to use globalClock.getFrameTime() or globalClock.getRealTime() rather than time.time() anyway.)

That’s not a bad idea. Do you have time to investigate this possibility?

David

Hi David,

I’m sorry but I don’t really have enough time to try to save/restore the FPU word.
As you’ve pointed out, there are ways around the issue, and I’ve already worked around the problem.
Since our project is coming to an end I need to focus on more pressing issues.

But:
In the past, with other DX based engines, we always used to do this save/restore trick and it worked fine. So that might be an idea for the panda dev team to put onto the product back log.

Cheers,

Erik