Jump to content

  • Log In with Google      Sign In   
  • Create Account


~0ul

Member Since 18 Jul 2009
Offline Last Active Private

Posts I've Made

In Topic: Compile Shaders/Load Extensions without setting up a window

17 September 2013 - 01:23 AM

Yeah, it makes sense to have a wglContext, I just don't see why it requires a window to be setup and was hoping there was a way to create a gl context without creating a window. Just like you can create a d3d11 device without creating a window and compile all your shaders using d3dcompile.

 

If I must create a dummy window, is it safe to delete the hWnd etc after getting the addresses for the extensions ? I know the context must stay alive but I'd like to clean up all the other window stuff if possible.


In Topic: D3D9 CreateDevice crash with D3DCREATE_HARDWARE_VERTEXPROCESSING

15 July 2013 - 03:55 PM

actually its probably not a callback blowing the stack as I would see it in the callstack, still could be a stomp though.


In Topic: D3D9 CreateDevice crash with D3DCREATE_HARDWARE_VERTEXPROCESSING

13 July 2013 - 01:25 PM

Thanks for the reply mhagain. I did take a quick look and the code around the device creation looked ok, but I'll check again ( I also tried increasing the thread stack just as a test but I still got the crash, so I was thinking something might just be blowing the stack somewhere (infinite recursion, or huge allocation on the stack) ). Yeah, I'm assuming the fault is in our code and not in the drivers. I got the sample app to work correctly, however I haven't tried spawning a thread from a native dll called from managed code and creating a device from there yet.

 

I was curious if the CreateDevice function might have some callbacks into user code ? If so, what would these callbacks be. for eg: the d3dxeffect system has user callbacks which get called from inside the d3d dll's. Maybe create device is calling such a callback which is causing the stack overflow. If so what kind of usage would trigger a callback from inside CreateDevice ? I can't step into this function so I'm not sure how to find out.


In Topic: D3D9 CreateDevice crash with D3DCREATE_HARDWARE_VERTEXPROCESSING

12 July 2013 - 11:42 PM

Yeah, that's what I'm assuming. Software VP would mean vertex shader emulated on the CPU whereas mixed picks hardware if it can otherwise fall backs to software ?

 

Maybe that's why it fixed my crash, by delaying some initialization to happen sometime later which causes the crash to not happen.


In Topic: D3D9 CreateDevice crash with D3DCREATE_HARDWARE_VERTEXPROCESSING

12 July 2013 - 11:53 AM

Thanks for the suggestion. Yup, just tried it:

D3DCAPS9 Caps;
sys->GetDeviceCaps(D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, &Caps);
if( Caps.DevCaps & D3DDEVCAPS_HWTRANSFORMANDLIGHT )
     return true
return false;

returns true.

 

What is D3DCREATE_HARDWARE_VERTEXPROCESSING anyway ? Does this mean the entire geometry stage (vertex fetch, vertex shader etc) runs in software or just the old fixed function stages ? I can even get it to work with D3DCREATE_MIXED_VERTEXPROCESSING which makes the CPU run a lot faster so I'm assuming its doing all the heavy lifting on the gpu. I just don't know why its crashing with D3DCREATE_HARDWARE_VERTEXPROCESSING. 


PARTNERS