Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

math operations don't work after creating the DirectX9 Device 1

Status
Not open for further replies.

CZDave

Programmer
Jan 23, 2005
4
0
0
CZ
Hi, could someone please help me with following code? I want to make a 3D simulation of solar system, therefore I need to calculate julian date from time. My function CalcJulianDate works fine until I create the Direct3DDevice9, then it returns numbers rounded to 2 or less digits. Does someone know why and how to fix it?

This is my code:



#include <windows.h>
#include <d3d9.h>
#include <stdio.h>

// declaration of my function
double CalcJulianDate( SYSTEMTIME );

int WINAPI WinMain( HINSTANCE hInst, HINSTANCE, LPSTR, int )
{
// some variables
HWND hWnd;
SYSTEMTIME st;
char Buf[255];
double JD;
IDirect3D9* pD3D;
IDirect3DDevice9* pd3dDevice;

// getting current time in UTC
GetSystemTime( &st );

// creating the window and Direct3D9
WNDCLASSEX wc = { sizeof(WNDCLASSEX), CS_CLASSDC, DefWindowProc, 0L, 0L,
hInst, NULL, NULL, NULL, NULL, "DX9", NULL };
RegisterClassEx( &wc );

hWnd = CreateWindow( "DX9", "DX9",
WS_OVERLAPPEDWINDOW, 100, 100, 300, 300, GetDesktopWindow(),
NULL, wc.hInstance, NULL );

if( NULL == ( pD3D = Direct3DCreate9( D3D_SDK_VERSION ) ) )
{
MessageBox( NULL, "Direct3DCreate9", NULL, 0 );
return E_FAIL;
}

// setting parameters for Direct3DDevice9
D3DPRESENT_PARAMETERS d3dpp;
ZeroMemory( &d3dpp, sizeof(d3dpp) );
d3dpp.Windowed = TRUE;
d3dpp.SwapEffect = D3DSWAPEFFECT_DISCARD;
d3dpp.BackBufferFormat = D3DFMT_UNKNOWN;

// calculating and displaying the julian date before creating the device
// returns what i need

JD = CalcJulianDate( st );
sprintf( Buf, "%f", JD );
MessageBox( NULL, Buf, NULL, 0 );

// creating the Direct3DDevice9
if( FAILED( pD3D->CreateDevice( D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, hWnd,
D3DCREATE_HARDWARE_VERTEXPROCESSING, &d3dpp, &pd3dDevice ) ) )
{
MessageBox( NULL, "CreateDevice", NULL, 0 );
return E_FAIL;
}

// calculating and displaying the julian date after creating the device
// now it returns rounded number, but I need full double resolution

JD = CalcJulianDate( st );
sprintf( Buf, "%f", JD );
MessageBox( NULL, Buf, NULL, 0);

// releasing DX objects
if( pd3dDevice != NULL )
pd3dDevice->Release();
if( pD3D != NULL )
pD3D->Release();

return 0;
}

// this function calculates the julian date using very simple algorithm
double CalcJulianDate( SYSTEMTIME st )
{
if( st.wMonth > 2 )
{
st.wMonth += 1;
}
else
{
st.wYear -= 1;
st.wMonth += 13;
}

double dJD;
dJD = 1720981.5 + 365.25 * st.wYear + 30.6 * st.wMonth + st.wDay +
st.wHour / 24.0 + st.wMinute / 1440.0 + st.wSecond / 86400.0;

return dJD;
}
 
This has to be one of the wierdest things I have ever seen programming. If nobody else knows what's going on, you might try using OpenGL instead and see if that works...but I still don't understand how this makes any sense at all, and DirectX obviously shouldn't be doing this. Have you looked on MSDN and seen if there is any mention of anything like this?
 
I wonder if the library is messing with the rounding control
Try seeing what is stored here before and after the call.

I agree, definitely one for the "weird" collection.

--
 
thx a lot Salem, you were right, the value of _control87 is 9001F before and A001F after, I don't know exactly what does it mean and how to use that _control87 to set it back yet, but I'm gonna find out in MSDN.. thx a lot once more :)
 
wow, it really works, I used _control87( _CW_DEFAULT, 0xfffff ) and my double values are back again :) Thx once again, Salem.
 
I would suggest you do some experiments to check whether DX9 actually depends on the changed floating point mode, or whether its just sloppy coding in DX9 which just leaves it like that.

Don't forget the dependency may be performance related, not just arithmetic. Checking things are still drawn in the same place is just as important as checking they're drawn just as quickly.

--
 
Well I need that precision only for this calculation so I could switch it everytime, but the question is if that switching wouldn't be even slower :) I'll try some variations and choose the best.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top