0
\$\begingroup\$

I'm struggling with a problem for a while and I hope some of you can help me out. The title for this question is vague, so I will try to explain my problem as best as I can!

I'm am creating a project (in C++ using Visual studio 2012) with a DLL that has the DirectX toolkit and DXUT as references. I initialize DXUT (the device and all that kind of stuff) in the DLL and create a GameScene (GameScene is in the executable) after DXUT is initialized. The GameScene derives from its base class BaseScene (BaseScene is in the DLL project).

When I call DXUTGetD3D11Device() to get the DirectX device in the GameScene (in the executable) it is all fine, but when I call DXUTGetD3D11Device() in the BaseScene it returns null.

Note: This counts for all the DXUT functions! Note: The executable has the same references as the dll + the dll!

If you need more information to answer my question, ask me! I find it really hard to explain my problem and I will try my best to make it more clear!

Improve this question
\$\endgroup\$

1 Answer 1

Reset to default
1
\$\begingroup\$

DXUT is a static library by default, IIRC. If that's the case, when you link DXUT into both your .exe and your .dll, you actually get two separate copies of it. Any internal state will not be shared between the two, so if you initialize DXUT in one module, that device/window/etc. will not automatically be available in the other module.

You could work around this by hacking the two DXUTs to share states. Inside DXUT all the state is in the DXUTState class, and there is a global pointer g_pDXUTState that gets set up when you initialize the library. You could copy this pointer from one module to the other. However, it's possible this could cause problems because DXUT wasn't designed for this use case and it might violate some of its internal assumptions.

Another possibility is to modify DXUT into a .dll instead of a static library, which would result in just one copy of it existing in your application; but that sounds like it would probably be a lot of work.

Probably the cleanest solution is to use DXUT from only one of the modules. If you use it in the .exe, don't use it in the .dll; just pass the device pointer, window handle, etc. from the .exe to the .dll through function parameters.

Improve this answer
\$\endgroup\$
2
  • \$\begingroup\$ First I thought that this didn't explain why the GameScene could use DXUTGetD3D11Device() and the BaseScene not, but I think the reason for this is that the GameScene is created from the DLL. And the BaseScene is created from the GameScene, so in the executable and that's why it uses the DXUT from the exe. Am I Right? \$\endgroup\$
    – Yannick Lange
    Jan 10, 2014 at 23:01
  • \$\begingroup\$ @YannickLange I'm not sure, but there's an easy way to check this: go in your debugger, and while stepping through .exe code, put &g_pDXUTState in the watch window and note the address. Then step into some .dll code and see if the address changes. That will prove there are indeed two copies of DXUT in play. \$\endgroup\$
    – Nathan Reed
    Jan 10, 2014 at 23:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .