Sign in to follow this  
Fire Lancer

Multiple graphics backends

Recommended Posts

I want to build my game with the potential to change the underlay graphics API, without rewritting game code. Im currently doing this by proving additonal layers between my game code and the graphics API (currently only d3d9) eg
class IGraphics;
class ISprite;

class IGraphics
	unsigned backCol;

	void SetBackgroundColour(unsigned col){backCol = col;}
	virtual void Render(boost::function<void(IGraphics*)>)=0;

	virtual ISprite *CreateSprite(const std::wstring &File)=0;

class D3D9 : public IGraphics
	bool lost;
	Window *window;
	IDirect3D9             *d3d;
	IDirect3DDevice9       *device;
	IDirect3DVertexBuffer9 *quadVB;
	void GetParams(D3DPRESENT_PARAMETERS *out);
	void D3D9::SetRenderStates();
	D3D9(Window *window);
	virtual ~D3D9();
	IDirect3DDevice9 *GetDevice();
	virtual void Render(boost::function<void(IGraphics*)>);
	virtual ISprite *CreateSprite(const std::wstring &File);

	boost::function<void(IGraphics*)> OnDeviceLost;
	boost::function<void(IGraphics*)> OnDeviceReset;

The game then only handles classes such as IGraphics and ISprite within its code for the most part (eg stuff like lost/reset device is a d3d thing I need to handle, but opengl doesnt have anything like that, however for the most part it will be handled within the other classes once im done). The problem thats occured to me however, is that even if I never call any function from a given API, it loads the API's dlls straight off, meaning it will only work for people who support all the backends I used... Is there someway to make it only load/lookfor/need the dlls when I actauly create a D3D9 IGraphics instance and same for openGL and D3D10? So it will work for poeple that dont have D3D10 for example, as long as they chose D3D9/OpenGL in the options?

Share this post

Link to post
Share on other sites
Yep, that's the standard approach.

Another option would be to mark the depending DLLs as delay-loaded, but that's probably a bit more flakey than just having separate DLLs.

Share this post

Link to post
Share on other sites
I would also suggest that if you care at all about the quality of this implementation, you immediately halt forward progress and go fix that "current only D3D9" bug. Runtime-swappable rendering subsystems are thorny, and of highly questionable utility and practicality beyond educational experience... if you build one by providing a vague abstraction based only on a single concrete API (e.g., "only D3D9") you'll probably find yourself with heaps of refactoring to do later, once the abstraction is large and unweildy, and you only just are starting to try and build the OpenGL implementation underneath.

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this