Skip to main content
GameDev.net gamedev.net
🔒 Locked

Rendering Framework Design

Started by WalterTamboer Jul 4, 2007 at 4:58 PM 1 replies 1.9k views
Original Post
WalterTamboer
WalterTamboer
Hey everybody, I'm creating a tiny framework that will support rendering for OpenGL as well as for Direct3D9. Now I've created a GraphicsDevice class, an OpenGLGraphicsDevice (which is derived from GraphicsDevice) and a Direct3D9GraphicsDevice class (which also is derived from GraphicsDevice). This isn't really hard to accomplish but I want to make use of swap chains in Direct3D. This is because I need to render to multiple windows. In OpenGL this can be done by using multiple rendering contexts. Now I've come up with some example code that does the job (it does have some memory leaks though). This is the concept:
while (Rendering)
{
	Device->Bind(FirstHandle);
	Device->Clear();
	Device->BeginScene();
	...
	Device->EndScene();
	Device->Present();
	
	Device->Bind(SecondHandle);
	Device->Clear();
	Device->BeginScene();
	...
	Device->EndScene();
	Device->Present();
}




The bind function will loop through a std::map and check if the handle already exists. If not, it will be registered and a swap chain will be created. In the OpenGL version, a new rendering context will be created and registered. Full sourcecode can be found here: http://waltertamboer.nl/Test.zip My question is; Are there people that have created such a framework before or are willing to take a look at my code to give me some tips to improve it. Or maybe anyone knows a better way to do this? [Edited by - WalterTamboer on July 5, 2007 1:50:31 AM]
Shannon Barber
Shannon Barber
Study the design of existing engines that handle both DX & OGL first (e.g. OGRE, any others?)

You cannot create OGL rendering context's on-the-fly/per-frame, it's extremely slow.
The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara
dmatter
dmatter
If that solution works for you then thats fine, although I dont think its a clean enough separation between the renderer and operating system/window creation code, and in my oppinion such a separation should exist.

I wrote about something related last year in another thread that could be useful to you.

To re-iterate it

You abstract the graphics code into a renderer class

You abstract the code that creates windows into some form of a window class (or have an operating-system-platform class - that'll work too).

At this point you can create windows and you have code that can perform graphics. In order to get the graphics actually onto a window you need some glue-code to bind them together.
DirectX is a Windows-only API and this glue functionality is actually built-in (its swap-chains and some init functions too), but OpenGL is a multi-platform API and doesnt support the concept of a window (not every platform has windows so basing a flexible rendering framework around windows is a non-portable idea) so for OGL this glue functionality lives in the windows API called 'wiggle functions' (theyre functions prefixed with wgl_).
This glue-code is the platforms responsibility not the graphics API's responsibility so it ought to be built into your window class youve previosuly built. One way to do this is to have different types of window classes e.g. OGLWindow and D3DWindow that derive from a RenderTarget class and that interacts with your window-creation code.

So now:
All gfx API stuff is kept in the renderer and has no idea that windows exist at all, for it knows it could be rendering to a texture but all it really knows is that its rendering to a RenderTarget,
all OS & window stuff is kept in a Window or OSPlatform class,
and all the glue-code is kept in OGLWindow and D3DWindow.

I think this is a good way to support multiple windows and keep the underlying APIs cleanly abstracted.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.