My DirectX class design problems
Author
Hello,
I've got engine.h and engine.cpp. The code for these I got from some tutorial or something, don't remember where exactly. Anyways, they setup Directx for me. However, I've run into a problem. They declare the Direct3D and the Device interfaces in the .cpp file. No big deal, I've been running everything up until this point just fine.
So, I want to add some text to my game. I have a CBoard class that basically runs the game. I go use D3DXCreateFont and ut oh, I can't see my d3dDevice pointer. Where do you typically declare the interfaces? And more importantly, how do you get those pointers into other classes?
Do you simply pass the pointers into the constructors of any and all classes you write that may need them?
Help please!!
Hi..
first,your ought to read more about OOP design ..
take this desing approach as a starting step
in your engine.cpp/.h , make a class that handles the device for initing, releasing and rendering operations , then make a member function that returns a pointer to your device like IDirect3DDevice8 * GetDevice()
{
return m_mydeviceptr;
// where mydeviceptr declated as a member variable with
//this definition IDirect3DDevice8 * m_mydeviceptr = NULL;
}
So if you want to render a text and the rendering function needs a pointer to the device , all you have to do is passing the pointer to the function ( GetDevice ) .. e.g
RenderText(IDirect3DDevice8 pointer .... )
{
pointer=GetDevice();
pointer-> // access the device's functions
}
first,your ought to read more about OOP design ..
take this desing approach as a starting step
in your engine.cpp/.h , make a class that handles the device for initing, releasing and rendering operations , then make a member function that returns a pointer to your device like IDirect3DDevice8 * GetDevice()
{
return m_mydeviceptr;
// where mydeviceptr declated as a member variable with
//this definition IDirect3DDevice8 * m_mydeviceptr = NULL;
}
So if you want to render a text and the rendering function needs a pointer to the device , all you have to do is passing the pointer to the function ( GetDevice ) .. e.g
RenderText(IDirect3DDevice8 pointer .... )
{
pointer=GetDevice();
pointer-> // access the device's functions
}
There are many ways of doing this. As AhmedSaleh pointed out, you could pass the pointer or reference of your CEngine into a funtion within your CBoard class, you could always make CBoard a friend class within CEngine or...even derive CEngine from CBoard. Personally I'd go with the first option.
public CBoard : public CEngine
{
///
protected:
IDirect3DDevice8* m_pD3DDevice;
};
public CEngine
{
friend class CBoard;
////
protected:
IDirect3DDevice8* m_pD3DDevice;
};
public CEngine
{
public:
IDirect3DDevice* GetD3DDevice() { return m_pD3DDevice; }
////
protected:
IDirect3DDevice8* m_pD3DDevice;
};
CBoard::Yourfunction(CEngine& engine)
{
IDrect3DDevice8* pDevice = engine.GetDevice();
}
My main class which sets up d3d is a singleton class, which means there is only ever one instance of it.
Just my 2 cents worth.
Regards,
Steve
public CBoard : public CEngine
{
///
protected:
IDirect3DDevice8* m_pD3DDevice;
};
public CEngine
{
friend class CBoard;
////
protected:
IDirect3DDevice8* m_pD3DDevice;
};
public CEngine
{
public:
IDirect3DDevice* GetD3DDevice() { return m_pD3DDevice; }
////
protected:
IDirect3DDevice8* m_pD3DDevice;
};
CBoard::Yourfunction(CEngine& engine)
{
IDrect3DDevice8* pDevice = engine.GetDevice();
}
My main class which sets up d3d is a singleton class, which means there is only ever one instance of it.
Just my 2 cents worth.
Regards,
Steve
I am successfully using that "pass engine by parameter" method in my engine. I tried several approaches during the last few years and that is the one I finally felt like sticking to...
As far as OOP goes - once you start with it - stick to it. Don't start weakening your classes by defining things public that shouldn't be. Occasionly this can cause some headaches but it's definitely worth the effort - not sticking to it will get you in a really ugly dependency-hell...
Cheers,
Alex
As far as OOP goes - once you start with it - stick to it. Don't start weakening your classes by defining things public that shouldn't be. Occasionly this can cause some headaches but it's definitely worth the effort - not sticking to it will get you in a really ugly dependency-hell...
Cheers,
Alex
Its probably not the most OOP way of doing things, but instead of worrying about passing pointers and getting pointers to your DirectX interfaces, you could just make them global variables in one .cpp file, and then use the keyword "extern" to let your program know that the global exists in another file, and that is the one you want to be using. The way I program, I have about 50 externed variables in this game I'm working on. If you don't know about 'extern', I think you've kinda got to learn more C/C++ before making even a very simple game.
What i did was to write a base class that contained all the global pointers i needed. The things i put in it were the LPDIRECT3DDEVICE9. HINSTANCE, HRESULT and HWND. SO that by default each class has this handle/variable. Then i wrote a function that in this base class that excepts 4 parameters and sets the for locals providing the paramater is not NULL.
This works a beaut.
You can find my engine source code at the site in my sig.
This works a beaut.
You can find my engine source code at the site in my sig.
A common system if these things will only be one instance at a time you can do...
//in h
class stuff
{
static otherclass* m_pOtherClass;
};
//in Cpp
static otherclass* stuff::m_pOtherClass = NULL;
I believe it is that way in the C++, it really is just doing the right syntax, since the class won't directly create a
static value you have to in a cpp file.
The above example is sometimes good for putting a value inside a class that all class instance will be tied together through it. You use it like normal, but that var will be the same mem in each class instance.
another way
//h
class Stuff
{
public:
//shit in class
int x;
};
Stuff &GET_STUFF();
//cpp
Stuff &GET_STUFF()
{
static Stuff staticOut;
return staticOut;
};
That is an easy way to always get a class if you plan on only using one instance of that class. Which is common for a rendering device.
use it like...
GET_STUFF().x = 10;
With C++ it is knowing your tools and using them right.
If you just want a pointer you can also do about anything you want and set it any way. You could even put it as public and get it that way. Or make a macro for each class to return a pointer.
//assumes x is already a pointer
#define GET_P(x,y, z) z* ##y() { return x; };
works this way
class Stuff
{
private:
int *wha;
public:
GET_P(wha, GetWha, int)
};
Stuff tempStuff;
int *ahh = tempStuff.GetWha();
All about knowing your tools... Also intellisense somtimes misses macro's, stupid intellisense piece of crap.
//in h
class stuff
{
static otherclass* m_pOtherClass;
};
//in Cpp
static otherclass* stuff::m_pOtherClass = NULL;
I believe it is that way in the C++, it really is just doing the right syntax, since the class won't directly create a
static value you have to in a cpp file.
The above example is sometimes good for putting a value inside a class that all class instance will be tied together through it. You use it like normal, but that var will be the same mem in each class instance.
another way
//h
class Stuff
{
public:
//shit in class
int x;
};
Stuff &GET_STUFF();
//cpp
Stuff &GET_STUFF()
{
static Stuff staticOut;
return staticOut;
};
That is an easy way to always get a class if you plan on only using one instance of that class. Which is common for a rendering device.
use it like...
GET_STUFF().x = 10;
With C++ it is knowing your tools and using them right.
If you just want a pointer you can also do about anything you want and set it any way. You could even put it as public and get it that way. Or make a macro for each class to return a pointer.
//assumes x is already a pointer
#define GET_P(x,y, z) z* ##y() { return x; };
works this way
class Stuff
{
private:
int *wha;
public:
GET_P(wha, GetWha, int)
};
Stuff tempStuff;
int *ahh = tempStuff.GetWha();
All about knowing your tools... Also intellisense somtimes misses macro's, stupid intellisense piece of crap.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
