quote:Original post by FreJa
Ok... for example: in most of the games you have the possibility to choose in which API to run... and my question is: how do they handle this change?

Wrong: in MOST of the games you can''t choose in which API to run.
Counterstrike, errrr, Half-Life isn''t "most" games. Most games are Direct3D, except the Quake-engine derived ones. Please don''t respond with thousands of exceptions, you know you''re wrong.

IMHO supporting both APIs is a completely unnecessary waste of time. Both Geforces and Radeons have excellent OpenGL drivers, so if you want portability to those 0.6% of gamers who run Linux and never ever pay for anything, go ahead and use OpenGL. Other cards are unlikely to be capable of running a game anyway.

Good software design never came back to bite anyone on the ass. The majority of engines on the market can support more than one graphical API if they so choose. Some ship with one because it was too difficult to maintain both drivers at the same time and meet their release date, and others don''t ship with them because one is buggy and the other is not. But I''d venture to say all but the lowest of the low hacked togeather games are the ones that were designed so that the API can not be removed or replaced with out having a major engine overhaul.

Abstracting the API''s like suggested in the above replies is "good design". Abstracting d3d or openGL code into a rendering class will pay for itself in the long term even if you don''t implement both at once. For example lets say your using direct3d, and a new version''s released with some changes to one function that you''ve called over 1000 times in your application. If you "hack" it all togeather with out an API abstraction layer your going to be hand editing 1000 lines of code and hoping it works. With an API abstraction layer you make a change in one or two functions and most likely don''t have to touch any other part of the code. Not only that but it also saves you from having your code completely dependant on a single API in case changes ever happen, or extensions are ever added.


Most of the posters who have replied to this with negative comments are obviously inexperianced or just plain stubborn.

As for Abstracting the interfaces:

class Renderer{  virtual Init() =0;  virtual Draw() = 0;};class DXRenderer: public Renderer;{  Init() { d3dInit(); }  Draw() { d3dDraw(); }};class OGLRenderer( public Renderer:{  Init() { oglInit(); }  Draw() { oglDraw(); }};

That''s how it''s done. Note that the virtual functions in the renderer class have =0 after them. This means that they are pure virtual, and for an Abstract Base Class this is the way it should be.

From there you''d do

Renderer* renderer = new OGLRenderer;renderer->Init();renderer->Draw();delete renderer;

quote:Original post by Anonymous Poster
Good software design never came back to bite anyone on the ass. The majority of engines on the market can support more than one graphical API if they so choose.

...

Abstracting the API''s like suggested in the above replies is "good design". Abstracting d3d or openGL code into a rendering class will pay for itself in the long term even if you don''t implement both at once.

Commerical game engines must support multiple APIs of course. But a hobby game engine? Life is too short...

quote:
Commerical game engines must support multiple APIs of course. But a hobby game engine? Life is too short...

The reality of the situation is that it takes very little time to abstract the code into a rendering class as shown above. All the virtual functions in your base class are pure virtual so none need to be implemented in the base class at all! The only ones that need to be implemented are the functions in the derrived d3d or opengl rendering classes. And quite frankly you''d be doing that anyway if you were to write a wrapper. It''s very little effort for a very big reward.

quote:Original post by Anonymous Poster
The reality of the situation is that it takes very little time to abstract the code into a rendering class as shown above.

I disagree. There are quite a few architectural differences which won''t allow a simple wrapper class. For example:

- the different handling of render-to-texture
- the concept of vertex streams vs. interleaved/non-interleaved data
- the handling of vertex buffers
- the concept of dynamic/managed resources in D3D

I think the separation should be done at a higher level. For example, imagine an architecture where you have "World" objects (meshes, terrain patches etc.) and each of them has a "Renderable" counterpart when the engine has decided it''s likely to be visible. Those "Renderables" are sufficiently complicated objects that create and manage vertex/index buffers, bind shaders and textures etc. You''d have a finite (read: small) number of renderables implemented in C++, and it would be possible to implement each of them per API.