Jump to content

  • Log In with Google      Sign In   
  • Create Account


#Actualcr88192

Posted 11 February 2013 - 04:11 PM

yes, personally I found OpenGL to be a little more accessible than D3D, and the portability is a bit of a plus-point (partly as I develop for both Windows and Linux, and was also considering possibilities like NativeClient and Android as well).

not to say that everything about it is necessarily good, but it works.

I had generally been using the full-featured OpenGL, and also using a fair amount of "legacy" functionality, but trying to migrate things to be able to work with OpenGL-ES is also a little bit of a challenge, mostly as lots of functionality that was taken for granted no longer exists (not all of it for entirely clear reasons), resulting in a fair chunk of the renderer recently being migrated to wrappers (for the most-part, the "fixed function pipeline" is now largely faked via wrappers, errm, partly as wrappers were the path-of-least-effort, and it was admittedly a little easier to move what bits of code that were still using glBegin/glEnd over to wrappers, than decide whether or not to prune them, or rework them to use VAs or VBOs or similar, and likewise went for faking the transformation matrices, ...).

but, in general, it isn't all that bad.


my exposure to D3D has generally been as a bunch of awkwardness involving DX version specific COM objects, PITA getting things linked correctly (since the Windows SDK and DirectX SDK are separate, and it essentially amounts to hard-coding the DX SDK install path into the build-files), and all-around a fair bit of general inconvenience doing pretty much anything, and all this with the code being largely platform-specific anyways, doesn't seem like a good tradeoff.

most of what functionality I have needed, can be found either in OpenGL or in the Win32 API (most of which is wrapped over anyways, via OS-specific code), making these generally a lot more convenient.

advanced rendering features and high-level API design issues aren't really such a big deal in this case.


EDIT, did find this:
http://en.wikipedia.org/wiki/Comparison_of_OpenGL_and_Direct3D

#2cr88192

Posted 11 February 2013 - 03:58 PM

yes, personally I found OpenGL to be a little more accessible than D3D, and the portability is a bit of a plus-point (partly as I develop for both Windows and Linux, and was also considering possibilities like NativeClient and Android as well).

not to say that everything about it is necessarily good, but it works.

I had generally been using the full-featured OpenGL, and also using a fair amount of "legacy" functionality, but trying to migrate things to be able to work with OpenGL-ES is also a little bit of a challenge, mostly as lots of functionality that was taken for granted no longer exists (not all of it for entirely clear reasons), resulting in a fair chunk of the renderer recently being migrated to wrappers (for the most-part, the "fixed function pipeline" is now largely faked via wrappers, errm, partly as wrappers were the path-of-least-effort, and it was admittedly a little easier to move what bits of code that were still using glBegin/glEnd over to wrappers, than decide whether or not to prune them, or rework them to use VAs or VBOs or similar, and likewise went for faking the transformation matrices, ...).

but, in general, it isn't all that bad.


my exposure to D3D has generally been as a bunch of awkwardness involving DX version specific COM objects, PITA getting things linked correctly (since the Windows SDK and DirectX SDK are separate, and it essentially amounts to hard-coding the DX SDK install path into the build-files), and all-around a fair bit of general inconvenience doing pretty much anything, and all this with the code being largely platform-specific anyways, doesn't seem like a good tradeoff.

most of what functionality I have needed, can be found either in OpenGL or in the Win32 API (most of which is wrapped over anyways, via OS-specific code), making these generally a lot more convenient.

advanced rendering features and high-level API design issues aren't really such a big deal in this case.

#1cr88192

Posted 11 February 2013 - 03:56 PM

yes, personally I found OpenGL to be a little more accessible than D3D, and the portability is a bit of a plus-point (partly as I develop for both Windows and Linux, and was also considering possibilities like NativeClient and Android as well).<br /><br />not to say that everything about it is necessarily good, but it works.<br /><br />I had generally been using the full-featured OpenGL, and also using a fair amount of "legacy" functionality, but trying to migrate things to be able to work with OpenGL-ES is also a little bit of a challenge, mostly as lots of functionality that was taken for granted no longer exists (not all of it for entirely clear reasons), resulting in a fair chunk of the renderer recently being migrated to wrappers (for the most-part, the "fixed function pipeline" is now largely faked via wrappers, errm, partly as wrappers were the path-of-least-effort, and it was admittedly a little easier to move what bits of code that were still using glBegin/glEnd over to wrappers, than decide whether or not to prune them, or rework them to use VAs or VBOs or similar, and likewise went for faking the transformation matrices, ...).<br /><br />but, in general, it isn't all that bad.<br /><br /><br />my exposure to D3D has generally been as a bunch of awkwardness involving DX version specific COM objects, PITA getting things linked correctly (since the Windows SDK and DirectX SDK are separate, and it essentially amounts to hard-coding the DX SDK install path into the build-files), and all-around a fair bit of general inconvenience doing pretty much anything, and all this with the code being largely platform-specific anyways, doesn't seem like a good tradeoff.<br /><br />most of what functionality I have needed, can be found either in OpenGL or in the Win32 API (most of which is wrapped over anyways, via OS-specific code), making these generally a lot more convenient.<br /><br />advanced rendering features and high-level API design issues aren't really such a big deal in this case.<br /><br />

PARTNERS