Jump to content

  • Log In with Google      Sign In   
  • Create Account


support for both OpenGL and DirectX...


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
18 replies to this topic

#1 FreJa   Members   -  Reputation: 154

Like
Likes
Like

Posted 30 May 2003 - 10:15 AM

Hi, I usually see, in game engines descriptions, the support for both APIs (DirectX and OpenGL)... how can I offer support for both in my game engine... being all the drawing done, now, with opengl? Thanks

Sponsor:

#2 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

Likes

Posted 30 May 2003 - 10:28 AM

If you already are drawing everything with OpenGL, is there really a need to add Direct3D support

#3 FreJa   Members   -  Reputation: 154

Like
Likes
Like

Posted 30 May 2003 - 10:37 AM

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?

#4 Viquel   Members   -  Reputation: 122

Like
Likes
Like

Posted 30 May 2003 - 10:47 AM

For my 3D engine I manage both renderer with virtual function and inheritance...

basicly I have:

class CEngine
{
virtual Render ();
}

class CEngineDX8 : public CEngine
{
virtual Render ();
}

class CEngineOGl : public Engine
{
virtual Render ();
}


(It''s not the true code, just to give an idea)

So in the game I can create a pointer to a CEngine that hold both a CEngineDX8 and a CEngineOGl.

Most important is to make a difference between the engine and the renderer.

Hope that''s help.
Good luck.

#5 sphinx23   Members   -  Reputation: 188

Like
Likes
Like

Posted 30 May 2003 - 10:49 AM

they create an additional layer between the renderer and the graphics API.

Graphics API <-> Render Device <-> Game Engine

For example: the render device is an abstract class (C++), and you dynamically allocate the render device:


class AbstractRenderDevice {...};

class OpenGLRenderDevice : public AbstractRenderDevice
{
... Implements AbstractRenderDevice ...
}

class D3DRenderDevice : public AbstractRenderDevice
{
... Implements AbstractRenderDevice ...
}

Initialization code:

AbstractRenderDevice *ARenderDevice;

// decide which device to use:

if (UserRequest == D3D)
ARenderDevice = new D3DRenderDevice;
else if (UserRequest == OpenGL)
ARenderDevice = new OpenGLRenderDevice;


The render devices support the graphical functions the engine needs.

#6 FreJa   Members   -  Reputation: 154

Like
Likes
Like

Posted 30 May 2003 - 10:53 AM

Thanks!

#7 mittens   Moderators   -  Reputation: 1315

Like
Likes
Like

Posted 30 May 2003 - 02:41 PM

Popular topic, as it should be, here''s my favorite link for the whole sha-bang:

http://www.gamedev.net/reference/articles/article1672.asp

Trent Polack
trent.codershq.com
trent@codershq.com
Author of Focus on 3D Terrain Programming

#8 Raduprv   Members   -  Reputation: 997

Like
Likes
Like

Posted 30 May 2003 - 04:33 PM

Is there a GOOD reason for having both OpenGl and D3D rendering support?

Height Map Editor | Eternal Lands | Fast User Directory

#9 Namethatnobodyelsetook   Members   -  Reputation: 1256

Like
Likes
Like

Posted 30 May 2003 - 04:59 PM

OpenGL for non-windows portability, and card where OpenGL is faster than DirectX. DirectX for windows using cards with flaky, slow, or otherwise useless OpenGL drivers. DirectX for XBox ports.


#10 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

Likes

Posted 31 May 2003 - 05:00 AM

You really should ask yourself if the time spent supporting both OpenGL and Direct3D couldn''t be better spent somewhere else.

I think this is one of the many tar pits that attracts the inexperienced and/or overambitious and traps them while others actually finish their game engines.

If you want portability, use OpenGL. If you don''t, pick one and move on.

#11 assen   Members   -  Reputation: 145

Like
Likes
Like

Posted 01 June 2003 - 08:53 AM

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.

#12 CGameProgrammer   Members   -  Reputation: 640

Like
Likes
Like

Posted 02 June 2003 - 12:22 AM

I support both in my engine. I did it mainly to learn both APIs and their strengths and weaknesses. Right now I''m definitely liking Direct3D more as it seems much easier to optimize. And I do it the only way support for multiple renderers is done -- an abstract interface with the Direct3D/OpenGL code derived from it.

~CGameProgrammer( );



#13 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

Likes

Posted 02 June 2003 - 06:14 AM

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;







#14 cowsarenotevil   Crossbones+   -  Reputation: 2010

Like
Likes
Like

Posted 02 June 2003 - 06:39 AM

quote:
Original post by assen

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.


Read the FAQ before saying crap like that. It's also usually a good idea to have some form of backup for your argument. You don't have a list of every single game ever made, and you don't know what API's each of them uses, so don't say stuff like that.

quote:

Please don't respond with thousands of exceptions, you know you're wrong.



That's the line that get's me. Saying "you know you're wrong" is quite possibly the best way to start a flame war. And then you top it off with "Please" to really annoy people.

If you had provided a list of every 3D game ever made on the face of the earth, and shown that more used Direct3D, I would be a bit less upset.

PS. I'm not saying I prefer OpenGL to Direct3D, or even that you are neccasarily wrong , nor am I saying the opposite. I'm just saying that you should think before you post.

[edited by - cowsarenotevil on June 3, 2003 4:49:44 PM]

#15 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

Likes

Posted 02 June 2003 - 06:27 PM

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...

#16 neurokaotix   Members   -  Reputation: 100

Like
Likes
Like

Posted 02 June 2003 - 07:00 PM

Life isn''t too short if that is what you really want. It''s what I want, and it''s what I did and am doing.

James Simmons
MindEngine Development
http://medev.sourceforge.net

#17 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

Likes

Posted 03 June 2003 - 04:45 AM

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.

#18 assen   Members   -  Reputation: 145

Like
Likes
Like

Posted 03 June 2003 - 06:06 AM

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.


#19 Yann L   Moderators   -  Reputation: 1794

Like
Likes
Like

Posted 03 June 2003 - 06:27 AM

quote:
Original post by assen
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.

That's actually not even high level enough. Consider hardware assisted occlusion culling or LOD techniques, displacement mapped or fully procedural objects (where you have to take internal representations into account, when culling the object), clip plane extraction, matrix order, differences in coordinate frames, etc.

We had long discussions in our company, when the idea about multi-API support was brought up a couple of years ago. We tried several medium-level approaches, and they all failed at some point: either the OO interface became obscure and unflexible, or you had to sacrifice speed. Both were not acceptable.

We settled on a very high level approach: everything from object level on (including scenegraph, culling, visibility determination, LOD, lighting, etc) is taken by an API-specific implementation. The abstraction level of the interface is pretty high, a little like this:

class CRenderSystem {
public:

// object handling

virtual void AddObject(CObjectBase &) = 0;
virtual void RemoveObject(CObjectBase &) = 0;
virtual void ModifyObject(CObjectBase &) = 0;
virtual bool QueryObjectVisibility(CObjectBase &) = 0;
// ... etc, 20+ object manipulation methods ...


// General scene rendering

virtual void DispatchShaderClasses() = 0;
virtual void DispatchFatBuffer() = 0;
virtual void RenderNow() = 0;
virtual void RenderDeferred() = 0;
virtual void ManualBufferSwap() = 0;
// ... etc ...

};


Until now, we have our primary OpenGL renderer. A part of the team used this interface to build a non-realtime RenderMan-based raytracing engine (a totally different architecture). There were no major problems. A D3D port should also be very easy with this approach. A big advantage is maximal performance. A big drawback, however, is that the support of a new API requires the re-implementation of large parts of the engine.


[edited by - Yann L on June 3, 2003 1:30:24 PM]




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS