IDirect3DDevice9* pd3dDevice = DXUTGetGlobalDialogResourceManager()->GetD3DDevice();
// Set up a state block here and restore it when finished drawing all the controls
DXUTGetGlobalDialogResourceManager()->m_pStateBlock->Capture();
Using DX Gui outside of there framework.
Author
Hey,
I'm trying to figure out how to use the DX Gui outside of their custom framework. I spent a lot of time converting all my code over to unicode(yuck) and I copied all there files into my folder. And now I'm stuck trying to get the CDXUTDialog initialized properly.
1) I created an instance of the CDXUTDialog variable.
2) I called m_dxHud.AddButton( /*IDC_TOGGLEFULLSCREEN*/0, L"Toggle full screen", 35, 40, 125, 22 );
3) I call m_dxHud.OnRender( );
*BOOM* it crashes in CDXUTDialog::OnRender( );
- It seems that pd3dDevice == 0.
- This makes sense because I never called there DXUTInit, DXUTCreateWindow, or DXUTCreateDevice function calls because I have my own rendering system set up.
So my question is, if I'm not using there framework can I integrate in the DXGUI? And If I can how do I properly initialize their stuff?
- Thank you,
Dave Neubelt
Author
Quote:DirectX SDK
This sample demonstrates how an application that uses the Direct3D sample framework can take advantage of the framework's user interface support. The sample framework supports the following control types:
So does this mean I can't use the gui?
No. It means that the sample demonstrates how to use the UI features with the framework. It does not illustrate how to use this feature in general (e.g. without the framework).
It seems to me as if they implemented this whole UI stuff within the sample framework. So you have to incorporate that part into your own rendering system if you want to use it. It is not part of D3D or D3DX.
No, of course you can use the GUI system outside of their framework.
But i's NASTY to convert all the Unicrud crap out of there. Then you have to make sure you're loading up the default ID3DXSprite and ID3DXFont interfaces that the GUI system uses, along with the bitmap that the GUI system is using from the "media" folder in the SDK..
Yes...I WAS trying to break it out there myself to try and backport the GUI system to DX8.1, but I gave up.
I was also trying to figure out how to use the text input dll that they load up...
But i's NASTY to convert all the Unicrud crap out of there. Then you have to make sure you're loading up the default ID3DXSprite and ID3DXFont interfaces that the GUI system uses, along with the bitmap that the GUI system is using from the "media" folder in the SDK..
Yes...I WAS trying to break it out there myself to try and backport the GUI system to DX8.1, but I gave up.
I was also trying to figure out how to use the text input dll that they load up...
Author
Quote:Original post by darookie
No. It means that the sample demonstrates how to use the UI features with the framework. It does not illustrate how to use this feature in general (e.g. without the framework).
I don't know, it seems that all the code in the GUI is making use of the framework's classes. So I'm going to have to go through all there code and try to figure out how to make it work. It's going to take a major re-write.
Maybe I'm goign about it the wrong way, are there a few create functions I need to call that I pass in IDirect3DDevice9* and the ID3DXFont*
Quote:Original post by wazoo69
But i's NASTY to convert all the Unicrud crap out of there.
UNICODE is a very useful feature. It's not like all people on earth speak English or something... And the code difference is just ridiculously small. I don't see why this is any major drawback.
You'd probably spend just as much time creating your own GUI engine. And then you would know it inside out and backwards :)
Myself, I'm trying to pick apart the SkinnedMesh sample, and its about 40 pages of code :(
Myself, I'm trying to pick apart the SkinnedMesh sample, and its about 40 pages of code :(
Truth,
I just mean that when I plug the framework into my existing engine, I now have to convert quite a bit of objects over to work with UNICODE properly..
Plus I now have to add a "L" in front of all my strings..
Yes I'm in a bitchy mood today. :)
I just mean that when I plug the framework into my existing engine, I now have to convert quite a bit of objects over to work with UNICODE properly..
Plus I now have to add a "L" in front of all my strings..
Yes I'm in a bitchy mood today. :)
Quote:Original post by darookieQuote:Original post by wazoo69
But i's NASTY to convert all the Unicrud crap out of there.
UNICODE is a very useful feature. It's not like all people on earth speak English or something... And the code difference is just ridiculously small. I don't see why this is any major drawback.
Someone else already said it, but it'd probably be easier for you to just write your own than trying to convert it. If you write your own, you could use the framework GUI as an example on how to do it, and follow that.
As for UNICODE, there's nothing wrong with it people and it's here to stay so you better get used to it.
As for UNICODE, there's nothing wrong with it people and it's here to stay so you better get used to it.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
