Direct3D HAL vs. REF mode
I''m having a problem with D3D9 Reference mode. I get a crash after about the third frame every time I run my engine. In HAL it works fine with the exact same code. The last D3D call is Present(0, 0, 0, 0); The crash stops if I take out my code that sets the world transform. Any ideas?
Weird.
The failure of the reference rasterizer generally indicates an application bug.
Care to show some code?
Cheers,
Muhammad Haggag
The failure of the reference rasterizer generally indicates an application bug.
Care to show some code?
Cheers,
Muhammad Haggag
Since the crash is on Present() my guess was that there was a problem with my presentation parameters, here they are:
kPresentParams.BackBufferFormat = D3DFMT_UNKNOWN;
kPresentParams.BackBufferCount = 1;
kPresentParams.MultiSampleType = D3DMULTISAMPLE_NONE;
kPresentParams.MultiSampleQuality = 0;
kPresentParams.SwapEffect = D3DSWAPEFFECT_DISCARD;
kPresentParams.hDeviceWindow = hwnd;
kPresentParams.Windowed = TRUE;
kPresentParams.EnableAutoDepthStencil = TRUE;
kPresentParams.AutoDepthStencilFormat = D3DFMT_D24S8;
kPresentParams.Flags = D3DPRESENTFLAG_DISCARD_DEPTHSTENCIL;
kPresentParams.FullScreen_RefreshRateInHz = D3DPRESENT_RATE_DEFAULT;
kPresentParams.PresentationInterval = D3DPRESENT_INTERVAL_DEFAULT;
I don''t know what other code to send, if there''s a specific part of the code that will better help with a "diagnosis" I''d be glad to provide it. Thanks in advance.
kPresentParams.BackBufferFormat = D3DFMT_UNKNOWN;
kPresentParams.BackBufferCount = 1;
kPresentParams.MultiSampleType = D3DMULTISAMPLE_NONE;
kPresentParams.MultiSampleQuality = 0;
kPresentParams.SwapEffect = D3DSWAPEFFECT_DISCARD;
kPresentParams.hDeviceWindow = hwnd;
kPresentParams.Windowed = TRUE;
kPresentParams.EnableAutoDepthStencil = TRUE;
kPresentParams.AutoDepthStencilFormat = D3DFMT_D24S8;
kPresentParams.Flags = D3DPRESENTFLAG_DISCARD_DEPTHSTENCIL;
kPresentParams.FullScreen_RefreshRateInHz = D3DPRESENT_RATE_DEFAULT;
kPresentParams.PresentationInterval = D3DPRESENT_INTERVAL_DEFAULT;
I don''t know what other code to send, if there''s a specific part of the code that will better help with a "diagnosis" I''d be glad to provide it. Thanks in advance.
You do have the debug version of DirectX installed?
The reference driver is a debug only tool.
If you are running the debug build of Dx, run from the debugger, and look at the output window. Dx will send you messages there about what''s going on.
I don''t think the reference driver supports everything either - do you use any advanced features, such as a programmable vertex or pixel shaders? Check the docs on what exact the reference driver can do.
The reference driver is a debug only tool.
If you are running the debug build of Dx, run from the debugger, and look at the output window. Dx will send you messages there about what''s going on.
I don''t think the reference driver supports everything either - do you use any advanced features, such as a programmable vertex or pixel shaders? Check the docs on what exact the reference driver can do.
I always thought that the point of the reference driver was that it DID support everything, however slowly...
I didn't think you could set D3DFMT_UNKNOWN as the backbuffer. Is that legit? Try setting it to D3DFMT_X8R8G8B8 instead.
Josh
[edited by - Drilian on May 27, 2003 10:27:48 PM]
I didn't think you could set D3DFMT_UNKNOWN as the backbuffer. Is that legit? Try setting it to D3DFMT_X8R8G8B8 instead.
Josh
[edited by - Drilian on May 27, 2003 10:27:48 PM]
Yes I have the debug runtime installed. Only messages are some DLL loading messages and:
Direct3D9: (INFO) :======================= Reference SWVP device selected
Direct3D9: (INFO) :Using P3 PSGP
First-chance exception in shadows.exe (D3DREF9.DLL): 0xC0000094: Integer Divide by Zero.
The first stuff is normal, but obviously the last line is not .
Direct3D9: (INFO) :======================= Reference SWVP device selected
Direct3D9: (INFO) :Using P3 PSGP
First-chance exception in shadows.exe (D3DREF9.DLL): 0xC0000094: Integer Divide by Zero.
The first stuff is normal, but obviously the last line is not .
The crash being on Present doesn''t necessarily mean that''s where your error is.
Many drawing, matrix, state etc calls get buffered until at least the Draw*() call, and sometimes until the EndScene() or even the Present(). I suspect RefRast (don''t have the DDK installed on this machine so can''t check) buffers up lots until the last moment so the real problem could be ANYWHERE in your program.
The fact that the code works when you take out your transform code, very strongly hints at you doing something wrong in one of your matrices. Now most of the stuff that goes on in the transform pipe is multiplication and addition. So there are limited places you might encounter a divide, one in particular that is directly related to the transform is the homogeneous division by W after projection. i.e. the following happens:
1) vertices expanded to homogeneous form: xyz => xyzw, w=1
2) vertex transformed: xyzw'' = xyzw * (World*View*Projection)
3) "stuff" such as clipping and viewport adjustment
4) homogeneous divide: rhw = 1/w'' sx = x''/w'', sy = y''/w'', sz = z''/w'' (actually it just multiplies by the reciprocal, but that''s still one division)
So if one of your matrices screws up the w coordinate, you''d get a divide by 0. (e.g. element 4,4 being set to 0)
However, there is one weird thing - the division by 0 is integer rather than fp. But the refrast might be doing part of its transformation with integer maths on screen space vertices.
There are other things which happen to the matrices, and other divisions related to the matrices that may end up doing similar.
Try setting your matrix to identity and see if it crashes. The only effective way to find this is by breaking the problem down - take the matrices out of the equation.
Primitive and vertex counts passed to Draw calls might feasibly cause a divide, maybe even during correctness checking.
You say it works with the HAL, but is that using SOFTWARE or HARDWARE vertex processing? If it''s hardware then it''s not too surprising. Hardware will let you do many "wrong" things without blowing up - a T&L device has no easy way of reporting "bugs" back to the programmer short of displaying a message on the screen, so things like y=x/0 get turned into y=0 or y=x rather than crashing or returning an error. Just because it doesn''t happen in hardware doesn''t mean it isn''t wrong.
--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com
Many drawing, matrix, state etc calls get buffered until at least the Draw*() call, and sometimes until the EndScene() or even the Present(). I suspect RefRast (don''t have the DDK installed on this machine so can''t check) buffers up lots until the last moment so the real problem could be ANYWHERE in your program.
The fact that the code works when you take out your transform code, very strongly hints at you doing something wrong in one of your matrices. Now most of the stuff that goes on in the transform pipe is multiplication and addition. So there are limited places you might encounter a divide, one in particular that is directly related to the transform is the homogeneous division by W after projection. i.e. the following happens:
1) vertices expanded to homogeneous form: xyz => xyzw, w=1
2) vertex transformed: xyzw'' = xyzw * (World*View*Projection)
3) "stuff" such as clipping and viewport adjustment
4) homogeneous divide: rhw = 1/w'' sx = x''/w'', sy = y''/w'', sz = z''/w'' (actually it just multiplies by the reciprocal, but that''s still one division)
So if one of your matrices screws up the w coordinate, you''d get a divide by 0. (e.g. element 4,4 being set to 0)
However, there is one weird thing - the division by 0 is integer rather than fp. But the refrast might be doing part of its transformation with integer maths on screen space vertices.
There are other things which happen to the matrices, and other divisions related to the matrices that may end up doing similar.
Try setting your matrix to identity and see if it crashes. The only effective way to find this is by breaking the problem down - take the matrices out of the equation.
Primitive and vertex counts passed to Draw calls might feasibly cause a divide, maybe even during correctness checking.
You say it works with the HAL, but is that using SOFTWARE or HARDWARE vertex processing? If it''s hardware then it''s not too surprising. Hardware will let you do many "wrong" things without blowing up - a T&L device has no easy way of reporting "bugs" back to the programmer short of displaying a message on the screen, so things like y=x/0 get turned into y=0 or y=x rather than crashing or returning an error. Just because it doesn''t happen in hardware doesn''t mean it isn''t wrong.
--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement