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 h
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 time.tim
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
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
> # myExtensionModule.CreateDirec
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 single
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
> 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-neare
> 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
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, ma
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()
10 matches
Mail list logo
