Sign in to follow this  
moeen k

OpenGL a way to port a code?

Recommended Posts

moeen k    1432

is there any way to port our code to any other sdk? i know direct x is better than opengl.but it only supports microsft platforms. i just want to know if we want ot make a multiplatform engine what is best way? write our whole code in open gl or port our code in opengl or psgl for other platforms like linux mac and ps? foe example unreal engine is based on direcx but supports all platforms. how is it? a proggram does it?

tnx

Share this post


Link to post
Share on other sites
Joyal    137

first of all, DX is not Better than OpenGL , is just other alternative, and because OpenGL is not been built by a hugee company, sometimes takes a lot of time to be update

 

so the best way to "Port" a code, is based actually how you make your code, and OOP is the way to go,

 

a good way is usually to make a interface "RenderManager" with some methods and you used that in your entire code, and that way you can have two implementations of the "RenderManager", one can be RenderManagerOGL , and RenderManagerDX 

 

 

 

class RenderManagerOGL : RenderManager{} 
class RenderManagerDX : RenderManager{}

...

RenderManager *rm = NULL;

#ifdef WIN32
  rm = new RenderManagerDX();
#else
  rm = new RenderManagerOGL();
#endif
 

so in that way you make sure you have the same methods and your game is not going to have problem using the same code,

 

this is just a way to do it, im sure there are better solution, but that is how i would do it

Edited by Joyal

Share this post


Link to post
Share on other sites
blueshogun96    2264

Portability is something to consider BEFORE you begin coding a project.  It's best to plan out a wrapper class or function(s) to suit functionality for both APIs.  Create something fairly high level so that changing it would be simple enough to do with minimal hassle.

 

I do agree with Joyal to a certain degree, but I'd propose a slightly different approach.  If you're using Windows, I recommend instead of compiling Direct3D and OpenGL code in the same binary, create seperate .dll files that you load manually to support whatever API the user needs or requires.  This is what the Unreal Engine does (or did, at least).  In a .dll, you can explicitly export classes, functions and variables and load them manually using ::LoadLibrary and GetProcAddress.  It's also convenient if you plan on supporting multiple versions of Direct3D, because it helps prevent naming collisions and what not.  I just see it as less hassle to do it this way, unless you're under another platform besides windows that uses only one API like OpenGL, or a custom API for consoles.

 

Just make sure you think things through before taking action.  It will save you much trouble in the long run.

 

Shogun.

Share this post


Link to post
Share on other sites
Bacterius    13165

Just make sure you think things through before taking action.  It will save you much trouble in the long run.

 

And just make sure you don't think things through too much. No battle plan survives contact with the enemy, or, in other words, the design you end up implementing will almost certainly be quite different than the one you originally thought up, so don't overthink it - get a rough idea, plan things out, and start iterating, otherwise you'll spend months wasting time, conceptualizing... making UML diagrams...

Edited by Bacterius

Share this post


Link to post
Share on other sites
Chetanhl    354

Well to start just choose any API opengl or directx whichever you are more comfortable with and keep all low level platform dependent code in seperate directory or library. Create your own custom wrappers for all lowlevel functionality.

For example You can create MyRenderDevice for D3D device, MyVertexBuffer or D3DVertexBuffer, MyWindow to handle window mgt on win32,etc

Then to port your code to new platform lets say opengl you just have to replace these low level classes/libraries. 

 

One interesting way can be done is that you can try to keep header files for MyRenderDevice etc same and make implementations in #defs according to the platform its running on.

 





A Quick Example

////MyRenderDevice.h

class MyRenderDevice
{
void Init();
void RenderBegin();
void RenderEnd();
}


/////MyRenderDevice.cpp

#if GfxDriver == DirectX11

void Init()
{
ID3D11Device mydevice;
....
}

void RenderBegin()
{
}

void RenderEnd()
{
}

#elseif  GfxDriver == OpenGL

void Init()
{
OpenGLDeviceContext mydevice;
....
}

void RenderBegin()
{
}

void RenderEnd()
{
}

#endif

 

 

Another Approach can be to make an Interface from which actual RenderDevice Implementations will derive somewhat similar to what Joyal   mentioned above but it would be nice to make render in seprate libraries and keep a seprate var for choosing gfxdriver as you may want to run opengl on windows and may want to run different versions of directx (dx9 ,d3d11,etc) on windows - 

 





class IRenderDevice
{
......
}

#if Driver == DirectX11

class RenderDeviceDX11 : IRenderDevice
{
.....
}

typedef RenderDeviceDX11 MyRenderDevice;  // or #define

#elseif Driver == Opengl

class RenderDeviceGL : IRenderDevice
{
.....
}

typedef RenderDeviceGL MyRenderDevice;  // or #define

#endif


////And later in app

class Scene
{
MyRenderDevice device;

void Render()
{
device->RenderBegin();
...
device->RenderEnd();
}
}

There are many ways to do this but I would also agree with blueshogun96 it will be better to have seperate libraries.

I thing it would be a better if you can spend few days looking at some good open source cross platform engines. Here are the two of many - 

 

WildMagic

 

Ogre3D

 

(These engines also keep things in separate libraries)

 

 

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  

  • Similar Content

    • By povilaslt2
      Hello. I'm Programmer who is in search of 2D game project who preferably uses OpenGL and C++. You can see my projects in GitHub. Project genre doesn't matter (except MMO's :D).
    • By ZeldaFan555
      Hello, My name is Matt. I am a programmer. I mostly use Java, but can use C++ and various other languages. I'm looking for someone to partner up with for random projects, preferably using OpenGL, though I'd be open to just about anything. If you're interested you can contact me on Skype or on here, thank you!
      Skype: Mangodoor408
    • By tyhender
      Hello, my name is Mark. I'm hobby programmer. 
      So recently,I thought that it's good idea to find people to create a full 3D engine. I'm looking for people experienced in scripting 3D shaders and implementing physics into engine(game)(we are going to use the React physics engine). 
      And,ye,no money =D I'm just looking for hobbyists that will be proud of their work. If engine(or game) will have financial succes,well,then maybe =D
      Sorry for late replies.
      I mostly give more information when people PM me,but this post is REALLY short,even for me =D
      So here's few more points:
      Engine will use openGL and SDL for graphics. It will use React3D physics library for physics simulation. Engine(most probably,atleast for the first part) won't have graphical fron-end,it will be a framework . I think final engine should be enough to set up an FPS in a couple of minutes. A bit about my self:
      I've been programming for 7 years total. I learned very slowly it as "secondary interesting thing" for like 3 years, but then began to script more seriously.  My primary language is C++,which we are going to use for the engine. Yes,I did 3D graphics with physics simulation before. No, my portfolio isn't very impressive. I'm working on that No,I wasn't employed officially. If anybody need to know more PM me. 
       
    • By Zaphyk
      I am developing my engine using the OpenGL 3.3 compatibility profile. It runs as expected on my NVIDIA card and on my Intel Card however when I tried it on an AMD setup it ran 3 times worse than on the other setups. Could this be a AMD driver thing or is this probably a problem with my OGL code? Could a different code standard create such bad performance?
    • By Kjell Andersson
      I'm trying to get some legacy OpenGL code to run with a shader pipeline,
      The legacy code uses glVertexPointer(), glColorPointer(), glNormalPointer() and glTexCoordPointer() to supply the vertex information.
      I know that it should be using setVertexAttribPointer() etc to clearly define the layout but that is not an option right now since the legacy code can't be modified to that extent.
      I've got a version 330 vertex shader to somewhat work:
      #version 330 uniform mat4 osg_ModelViewProjectionMatrix; uniform mat4 osg_ModelViewMatrix; layout(location = 0) in vec4 Vertex; layout(location = 2) in vec4 Normal; // Velocity layout(location = 3) in vec3 TexCoord; // TODO: is this the right layout location? out VertexData { vec4 color; vec3 velocity; float size; } VertexOut; void main(void) { vec4 p0 = Vertex; vec4 p1 = Vertex + vec4(Normal.x, Normal.y, Normal.z, 0.0f); vec3 velocity = (osg_ModelViewProjectionMatrix * p1 - osg_ModelViewProjectionMatrix * p0).xyz; VertexOut.velocity = velocity; VertexOut.size = TexCoord.y; gl_Position = osg_ModelViewMatrix * Vertex; } What works is the Vertex and Normal information that the legacy C++ OpenGL code seem to provide in layout location 0 and 2. This is fine.
      What I'm not getting to work is the TexCoord information that is supplied by a glTexCoordPointer() call in C++.
      Question:
      What layout location is the old standard pipeline using for glTexCoordPointer()? Or is this undefined?
       
      Side note: I'm trying to get an OpenSceneGraph 3.4.0 particle system to use custom vertex, geometry and fragment shaders for rendering the particles.
  • Popular Now