Skip to main content
Game Development

Return to Answer

added 53 characters in body
Source Link
user1430
user1430

When one talks about OpenGL and D3D "features," one could be referring to either:

  1. the feature sets supported by hardware that the graphics API exposes, or
  2. the feature sets of the API itself that don't really relate to the hardware.

For example, a programmable tessellation pipeline is something the hardware generally has to support (let's ignore, for the purposes of practicality, that an API could in theory implement missing hardware features in software as that's generally too slow to be of real use). Presupposing it does, you can gain access to that pipeline in both D3D and OpenGL. D3D builds the interfaces for doing so into the core API of D3D11 via the hull/domain shaders and tessellation APIs. OpenGL providesprovided an extension that was eventually promoted to part of the core API. When it comes to hardware features, OpenGL and Direct3D are generally equivalent in terms of what you can make the hardware do via either API. The differences come in how.

There are hundreds of small API features (unrelated to actual hardware capability) that differ in both APIs. It's not practical to list them all in an answer. Aside from the fact that D3D is a "traditionally COM-like" API and OpenGL is a "traditionally C-like" API, one of the biggest differences in the feature set is that OpenGL has its rich extension mechanism (and D3D has no such thing). This tends to mean that OpenGL is in theory more flexible and adaptable to new capabilities, at the cost of being slightly more cumbersome to use (thus the plethora of OpenGL extension assistance APIs like GLEW).

When one talks about OpenGL and D3D "features," one could be referring to either:

  1. the feature sets supported by hardware that the graphics API exposes, or
  2. the feature sets of the API itself that don't really relate to the hardware.

For example, a programmable tessellation pipeline is something the hardware generally has to support (let's ignore, for the purposes of practicality, that an API could in theory implement missing hardware features in software as that's generally too slow to be of real use). Presupposing it does, you can gain access to that pipeline in both D3D and OpenGL. D3D builds the interfaces for doing so into the core API of D3D11 via the hull/domain shaders and tessellation APIs. OpenGL provides an extension. When it comes to hardware features, OpenGL and Direct3D are generally equivalent in terms of what you can make the hardware do via either API. The differences come in how.

There are hundreds of small API features (unrelated to actual hardware capability) that differ in both APIs. It's not practical to list them all in an answer. Aside from the fact that D3D is a "traditionally COM-like" API and OpenGL is a "traditionally C-like" API, one of the biggest differences in the feature set is that OpenGL has its rich extension mechanism (and D3D has no such thing). This tends to mean that OpenGL is in theory more flexible and adaptable to new capabilities, at the cost of being slightly more cumbersome to use (thus the plethora of OpenGL extension assistance APIs like GLEW).

When one talks about OpenGL and D3D "features," one could be referring to either:

  1. the feature sets supported by hardware that the graphics API exposes, or
  2. the feature sets of the API itself that don't really relate to the hardware.

For example, a programmable tessellation pipeline is something the hardware generally has to support (let's ignore, for the purposes of practicality, that an API could in theory implement missing hardware features in software as that's generally too slow to be of real use). Presupposing it does, you can gain access to that pipeline in both D3D and OpenGL. D3D builds the interfaces for doing so into the core API of D3D11 via the hull/domain shaders and tessellation APIs. OpenGL provided an extension that was eventually promoted to part of the core API. When it comes to hardware features, OpenGL and Direct3D are generally equivalent in terms of what you can make the hardware do via either API. The differences come in how.

There are hundreds of small API features (unrelated to actual hardware capability) that differ in both APIs. It's not practical to list them all in an answer. Aside from the fact that D3D is a "traditionally COM-like" API and OpenGL is a "traditionally C-like" API, one of the biggest differences in the feature set is that OpenGL has its rich extension mechanism (and D3D has no such thing). This tends to mean that OpenGL is in theory more flexible and adaptable to new capabilities, at the cost of being slightly more cumbersome to use (thus the plethora of OpenGL extension assistance APIs like GLEW).

Source Link
user1430
user1430

When one talks about OpenGL and D3D "features," one could be referring to either:

  1. the feature sets supported by hardware that the graphics API exposes, or
  2. the feature sets of the API itself that don't really relate to the hardware.

For example, a programmable tessellation pipeline is something the hardware generally has to support (let's ignore, for the purposes of practicality, that an API could in theory implement missing hardware features in software as that's generally too slow to be of real use). Presupposing it does, you can gain access to that pipeline in both D3D and OpenGL. D3D builds the interfaces for doing so into the core API of D3D11 via the hull/domain shaders and tessellation APIs. OpenGL provides an extension. When it comes to hardware features, OpenGL and Direct3D are generally equivalent in terms of what you can make the hardware do via either API. The differences come in how.

There are hundreds of small API features (unrelated to actual hardware capability) that differ in both APIs. It's not practical to list them all in an answer. Aside from the fact that D3D is a "traditionally COM-like" API and OpenGL is a "traditionally C-like" API, one of the biggest differences in the feature set is that OpenGL has its rich extension mechanism (and D3D has no such thing). This tends to mean that OpenGL is in theory more flexible and adaptable to new capabilities, at the cost of being slightly more cumbersome to use (thus the plethora of OpenGL extension assistance APIs like GLEW).