🔒 Locked

MultiAPI Renderer

Started by keatoon Sep 17, 2010 at 3:57 PM 2 replies 1.4k views

Original Post

Sep 17, 2010 at 3:57 PM

First of all, sorry for my bad english.

Today I was wondering how programmers abstract the rendering part of the game so they can use DX and GL.

I would do something like this:

- A Renderer class (base) with virtual functions like: DrawCharacter(), DrawTile(), DrawParticle(), etc;
- Derived classes like RendererGL and RendererDX wich implements those functions with respective API's functions to do what they meant to do;
- After creating the game window, I could choose the renderer like this: Renderer R = new RendererGL (or RendererDX).

is this a good way?

skwee

Sep 17, 2010 at 4:33 PM

Hey!
First of all I dont know what are your needs to make a multi-renderer. If you are making a game I would suggest you to stick to one API. You always can add the second (third or whatsoever) later on. In anyway AFAIK selecting API at run-time is worthless, most multi-render engines selects the API and compile time.

In case if you are not making a game, or insist to do multi-render API anyway, I would suggest you to check Ogre3D and see how they abstract the renderer.
Also your approach looks ok to me. The general idea is to come to some base abstract classes (for textures, materials, shaders, and etc) and then inherit the needed stuff from them (like GLTexture, DXShader and etc).

But again, unless you are familiar with all the API's you want to implement, coming to a base abstract classes will be a bit pain, and in my opinion its a waste of time.

Good Luck anyway! :)

Krohm

346

Krohm

Sep 18, 2010 at 8:13 AM

Agreed. Let's lay you choose D3D. Your chaders will be in HLSL.
Went GL? GLSL.

Want both? Uh-oh. Maybe you could go Cg, but you see, this is an external dependancy. Or maybe you want your own shading language to OMG DONT DO THAT!!!1

ArKano22

Sep 18, 2010 at 3:58 PM

Well, i don´t see anything wrong with having an abstract base renderer, then extending it. Even if you end up using HLSL or GLSL, that should not affect at all the renderer interface to the rest of the engine.

In my engine i´ve done it exactly as you describe it, keatoon. I´m using only OpenGL atm but if someday i decide to give DirectX a try, having all rendering code in one class is nice because i won´t need to hunt down gl* calls all over the entire engine. If you want to use a new API, you won´t have to change all your code as long as you can reimplement your renderer using the new API.

There might be better ways to do it, but abstracting the renderer is a clear future-proof win for me.

Topic Locked

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