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
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
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
