Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


a way to port a code?


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
4 replies to this topic

#1 moeen k   Members   -  Reputation: 471

Like
0Likes
Like

Posted 15 March 2013 - 10:49 AM

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



Sponsor:

#2 Joyal   Members   -  Reputation: 137

Like
1Likes
Like

Posted 15 March 2013 - 11:15 AM

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, 15 March 2013 - 11:27 AM.


#3 blueshogun96   Crossbones+   -  Reputation: 1047

Like
2Likes
Like

Posted 16 March 2013 - 02:43 PM

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.


Follow Shogun3D on the official website: http://shogun3d.net

 

blogger.png twitter.png tumblr_32.png facebook.png

 

"Yo mama so fat, she can't be frustum culled." - yoshi_lol


#4 Bacterius   Crossbones+   -  Reputation: 9055

Like
1Likes
Like

Posted 17 March 2013 - 06:32 AM

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, 17 March 2013 - 06:33 AM.

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#5 chetanjags   Members   -  Reputation: 203

Like
1Likes
Like

Posted 18 March 2013 - 03:31 PM

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)

 

 


My Game Development Blog : chetanjags.wordpress.com





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