Jump to content
  • Advertisement
Sign in to follow this  
hotpixel

when to use static?

This topic is 3501 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi guys, I'm trying to write a game engine in C++/DX and I thought it would be a good idea to define a 'RenderDevice' which contains my LPDIRECT3DDEVICE9 object so I can do a simple RenderDevice::GetDevice() anywhere in my project to grab my device. I also thought I could do RenderDevice::Init() so that only one device could ever be referenced. Now the class members need to be static, which is fine because I only want one of them but I have to redefine them as static in my static methods which doesn't seem right to me, if I don't it complains about an unlinked object:
Quote:
#ifndef _RENDERDEVICE_H #define _RENDERDEVICE_H class RenderDevice { private: static LPDIRECT3DDEVICE9 m_pd3dDevice; static HWND m_hWindow; static int m_width; static int m_height; public: static LPDIRECT3DDEVICE9 GetDevice(){return m_pd3dDevice;} static HWND GetWindow(){return m_hWindow;} static void Init(LPCWSTR name, int width, int height); static int Update(); static LRESULT CALLBACK WndProc( HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam ); }; #endif
Quote:
/*static*/ void RenderDevice::Init(LPCWSTR name, int width, int height) { ***missing code*** LPDIRECT3DDEVICE9 pd3dDevice; if( FAILED( pD3D->CreateDevice( D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, m_hWindow, D3DCREATE_HARDWARE_VERTEXPROCESSING, &d3dpp, &pd3dDevice ) ) ) HANDLE_MESSAGE(L" unable to create D3D device "); static LPDIRECT3DDEVICE9 m_pd3dDevice = pd3dDevice; ShowWindow( m_hWindow, SW_SHOWDEFAULT ); }
so you can see here that I am having to define a local d3d device so that I can pass it into the CreateDevice() method and then redefine my actual device as static and then pass my local render device back into my static render device. Does this seem right? Am I doing this right? Should I be instancing my RenderDevice? Thanks, Andy

Share this post


Link to post
Share on other sites
Advertisement
Can you think of any benefits this has over simply declaring a global RenderDevice*?

Note also that it is not an error to create multiple Direct3D devices.

Share this post


Link to post
Share on other sites
I suppose my train of thought was that I would only ever have to worry about one RenderDevice. Although multiple D3D Devices are possible I can't think of ever wanting to let anyone use more than one.

Share this post


Link to post
Share on other sites
You should initialise static variables.

eg in your cpp file place the following at the top

LPDIRECT3DDEVICE9 RenderDevice::m_pd3dDevice = NULL;

But if you are just going to arbitarily use RenderDevice::m_pd3dDevice all over the place then maybe a global *cringe* is the answer. Oh my I can't believe I said that :p

Share this post


Link to post
Share on other sites
no my m_pd3dDevice definately wants to be a private variable, and use GetDevice() to return it, I don't want people accessing it whenever they feel like it.

I want RenderDevice to handle all the DX stuff so that if I ever decide I want to port my engine onto other platforms then all I have to do is change class RenderDevice and any other WINDOWS/DX specific code

Share this post


Link to post
Share on other sites
Quote:
Original post by hotpixel
no my m_pd3dDevice definately wants to be a private variable, and use GetDevice() to return it, I don't want people accessing it whenever they feel like it.


Really? I can still access it:

class Audio
{
Audio()
{
RenderDevice::Init("=P",200,100);
}
};



Quote:

I want RenderDevice to handle all the DX stuff so that if I ever decide I want to port my engine onto other platforms then all I have to do is change class RenderDevice and any other WINDOWS/DX specific code

But your class exposes all its implementation details in a most horrific way. I would probably need to rewrite all the calling code if you stopped using DirectX and starting using some other API.

Share this post


Link to post
Share on other sites
I want my static functions to be accessed globally, then if something is breaking I can stick a breakpoints in my method and see when and why they are being accessed.

Quote:

But your class exposes all its implementation details in a most horrific way.


How so? You mean the fact that RenderDevice can always be initialised from where ever? Which was something I did think about... obviously this is just an idea that I haven't implemented yet which is why I'm asking what you think.

The idea was given to me by the guy who programmed the graphics for Viva Pinata on the PC. He splits his code into 3 main areas, game code, engine code and API specific code. None of his engine references any of the DX stuff. Everything obviously uses some sort of 'RenderDevice', everything uses vectors and matrices, uses shaders and needs to draw polygons so in theory it works.

It's where I got the idea for my RenderDevice but obviously he can't show me any of the code :(. He uses a RenderDevice class in a similar way, I'm just trying to figure it out!

Share this post


Link to post
Share on other sites
If you're going to make everything static, why use a class in the first place? That seems very unnecessary in my opinion.

Share this post


Link to post
Share on other sites
I suppose that's a valid point, why would you want to create a class you are never going to implement other than perhaps keeping it clean. ie you know you mean your RenderDevice when you want to GetDevice() and its all ecompassed in a RenderDevice file. It could get quite messy else, if there are a few things you only want to implement once.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!