Ok, my final solution is to add the D3DCREATE_FPU_PRESERVE flag. It didn't
harm performance in a noticeable way at all. I was under the impression
SSE would be affected by this, too. Additionally I was under the
impression that float precision would suffice for time.time(). Obviously I
was
Nitro schreef:
Ok, my final solution is to add the D3DCREATE_FPU_PRESERVE flag. It didn't
harm performance in a noticeable way at all. I was under the impression
SSE would be affected by this, too. Additionally I was under the
impression that float precision would suffice for
Nitro [EMAIL PROTECTED] wrote:
They should really make the fpu preserve flag the default. It just causes
very sneaky bugs.
They did in Direct3D 10, which doesn't change the flags. It's too late
to change the behaviour Direct3D 9 which was created a time where changing
FPU precision could have
Hello,
today I encountered a very odd situation. I am on Windows Vista and using
Python 2.5.2. Here's a code snippet to illustrate my problem:
# uncomment the next line to trigger the problem
# myExtensionModule.CreateDirect3D9Device()
import time
for i in range(0,100):
print time.time()
Nitro [EMAIL PROTECTED] writes:
With the line commented time.time() returns a changing value which is
what I expect. However, when I uncomment it and create a Direct3D9
Device [1][2] it keeps printing the very same number over and over!
The granularity of time.time can be quite large, maybe
The granularity of time.time can be quite large, maybe as much
as 1 second in some systems. Also, if the user can set the time,
the output might not be monotone. They might set the clock backwards
if it has drifted ahead, or something like that. Better to use an
explicit counter if you
Nevertheless time.time() shouldn't fail here unless DirectX is really
badly tinkering with my system.
I can tell you more now. If I pass D3DCREATE_FPU_PRESERVE while creating
the DirectX device the bug does not appear. This flag means Direct3D
defaults to single-precision round-to-nearest
Nitro [EMAIL PROTECTED] wrote:
I can tell you more now. If I pass D3DCREATE_FPU_PRESERVE while creating
the DirectX device the bug does not appear. This flag means Direct3D
defaults to single-precision round-to-nearest (see [1]) mode.
Unfortunately it is not an option to pass this flag, I
Nitro schreef:
Nevertheless time.time() shouldn't fail here unless DirectX is really
badly tinkering with my system.
I can tell you more now. If I pass D3DCREATE_FPU_PRESERVE while creating
the DirectX device the bug does not appear. This flag means Direct3D
defaults to
En Tue, 26 Feb 2008 17:37:22 -0200, Nitro [EMAIL PROTECTED] escribió:
today I encountered a very odd situation. I am on Windows Vista and using
Python 2.5.2. Here's a code snippet to illustrate my problem:
# uncomment the next line to trigger the problem
#
10 matches
Mail list logo
