Direct3D Compatibility: Difference between revisions
| (7 intermediate revisions by 2 users not shown) | |||
| Line 2: | Line 2: | ||
In general, unless you are actually doing such a port, you should avoid these features. | In general, unless you are actually doing such a port, you should avoid these features. | ||
== BGRA vertex format == | == BGRA vertex format == | ||
| Line 10: | Line 8: | ||
OpenGL always assumes that the components of vertex attribute data from vertex arrays is formatted in RGBA order (or XYZW/STPQ order). So the first component always goes to R, the second to G, etc. | OpenGL always assumes that the components of vertex attribute data from vertex arrays is formatted in RGBA order (or XYZW/STPQ order). So the first component always goes to R, the second to G, etc. | ||
D3D has a special mode, primarily used due to the little endian nature of Intel CPUs. Colors are often stored normalized, with 8 bits per component. So the entire color fits in a 32-bit unsigned integer. The problem is the order. | D3D has a special mode, primarily used due to the little endian nature of Intel CPUs. Colors are often stored [[Normalized Integer|normalized]], with 8 bits per component. So the entire color fits in a 32-bit unsigned integer. The problem is the order. | ||
D3D has a special component ordering for such colors, commonly used in D3D applications: ARGB. When stored in that ordering in a little endian 32-bit integer, it therefore becomes BGRA. | D3D has a special component ordering for such colors, commonly used in D3D applications: ARGB. When stored in that ordering in a little endian 32-bit integer, it therefore becomes BGRA. | ||
Native OpenGL applications would normally simply use what is available on OpenGL: ABGR ordering (32-bit little-endian, thus a reversed RGBA order). But if you want to read meshes that were natively built for D3D, this becomes a problem. And while one could employ a swizzle mask in GLSL, this | Native OpenGL applications would normally simply use what is available on OpenGL: ABGR ordering (32-bit little-endian, thus a reversed RGBA order). But if you want to read meshes that were natively built for D3D, this becomes a problem. And while one could employ a swizzle mask in GLSL, this requires changing your shader code. | ||
Therefore, the {{param|size}} parameter of {{apifunc|glVertexAttribPointer}} (and {{apifunc|glVertexAttribFormat}}, in GL 4.3/{{extref|vertex_attrib_binding}}) can be replaced with {{enum|GL_BGRA}}. There are a [[ | Therefore, the {{param|size}} parameter of {{apifunc|glVertexAttribPointer}} (and {{apifunc|glVertexAttribFormat}}, in GL 4.3/{{extref|vertex_attrib_binding}}) can be replaced with {{enum|GL_BGRA}}. There are a [[D3D Vertex Format Compatibility|lot of restrictions on doing this]]. So you should only ever use it if you need to load native D3D meshes. If your application is 100% OpenGL, don't bother. | ||
== Point coord conventions == | == Point coord conventions == | ||
The ability to change the origin of [[Primitive#Point primitives|point primitive coordinates]] is primarily for D3D compatibility. D3D uses {{enum|GL_UPPER_LEFT}}, while OpenGL defaults to {{enum|GL_LOWER_LEFT}}. | |||
== Provoking vertex conventions == | == Provoking vertex conventions == | ||
{{main|Primitive#Provoking vertex}} | {{main|Primitive#Provoking vertex}} | ||
The ability to change the provoking vertex for primitives is solely for D3D compatibility. D3D uses {{enum|GL_FIRST_COORD_CONVENTION}}, while OpenGL uses {{enum|GL_LAST_COORD_CONVENTION}} by default. | |||
== Not compatibility features == | == Not compatibility features == | ||
| Line 29: | Line 29: | ||
These are features that look like D3D compatibility features, but are not. That is, they work a lot like (or exactly equivalent to) D3D features, but they're in OpenGL because they're good ideas, not just to be compatible with D3D. These are features you should use even if you aren't doing a D3D port. | These are features that look like D3D compatibility features, but are not. That is, they work a lot like (or exactly equivalent to) D3D features, but they're in OpenGL because they're good ideas, not just to be compatible with D3D. These are features you should use even if you aren't doing a D3D port. | ||
* [[ | * [[Separate Attribute Format|Separation of vertex formats from buffers]] is not in OpenGL because it looks like how D3D works. It is in OpenGL because it's a great API for specifying vertex data (that D3D happened to do first). | ||
* Explicit in-shader specification for [[Type_Qualifier_(GLSL)#Vertex shader attribute index|inputs]]/[[Type_Qualifier_(GLSL)#Fragment shader buffer output|output]] indices, [[ | * Explicit in-shader specification for [[Type_Qualifier_(GLSL)#Vertex shader attribute index|inputs]]/[[Type_Qualifier_(GLSL)#Fragment shader buffer output|output]] indices, [[Layout Uniform Location|uniform locations]], and [[Layout Binding|opaque type binding points]]. | ||
* [[ | * [[Separate Program|Program separation]], along with [[Interface Matching|explicit locations for interface variables and special linking rules for such variables]]. | ||
== Incompatibilities == | == Incompatibilities == | ||
There are a number of incompatibilities left between OpenGL and D3D. | There are a number of incompatibilities left between OpenGL and D3D. | ||
Latest revision as of 18:50, 10 February 2018
There are a number of features in OpenGL that exist mainly to provide Direct3D Compatibility in some way. These features are intended to make it easier to port applications from D3D to OpenGL. They are primarily focused on data areas: shaders and meshes. That is, they mainly make it easier to use the same mesh data between OpenGL and D3D.
In general, unless you are actually doing such a port, you should avoid these features.
BGRA vertex format
OpenGL always assumes that the components of vertex attribute data from vertex arrays is formatted in RGBA order (or XYZW/STPQ order). So the first component always goes to R, the second to G, etc.
D3D has a special mode, primarily used due to the little endian nature of Intel CPUs. Colors are often stored normalized, with 8 bits per component. So the entire color fits in a 32-bit unsigned integer. The problem is the order.
D3D has a special component ordering for such colors, commonly used in D3D applications: ARGB. When stored in that ordering in a little endian 32-bit integer, it therefore becomes BGRA.
Native OpenGL applications would normally simply use what is available on OpenGL: ABGR ordering (32-bit little-endian, thus a reversed RGBA order). But if you want to read meshes that were natively built for D3D, this becomes a problem. And while one could employ a swizzle mask in GLSL, this requires changing your shader code.
Therefore, the size parameter of glVertexAttribPointer (and glVertexAttribFormat, in GL 4.3/ARB_vertex_attrib_binding) can be replaced with GL_BGRA. There are a lot of restrictions on doing this. So you should only ever use it if you need to load native D3D meshes. If your application is 100% OpenGL, don't bother.
Point coord conventions
The ability to change the origin of point primitive coordinates is primarily for D3D compatibility. D3D uses GL_UPPER_LEFT, while OpenGL defaults to GL_LOWER_LEFT.
Provoking vertex conventions
The ability to change the provoking vertex for primitives is solely for D3D compatibility. D3D uses GL_FIRST_COORD_CONVENTION, while OpenGL uses GL_LAST_COORD_CONVENTION by default.
Not compatibility features
These are features that look like D3D compatibility features, but are not. That is, they work a lot like (or exactly equivalent to) D3D features, but they're in OpenGL because they're good ideas, not just to be compatible with D3D. These are features you should use even if you aren't doing a D3D port.
- Separation of vertex formats from buffers is not in OpenGL because it looks like how D3D works. It is in OpenGL because it's a great API for specifying vertex data (that D3D happened to do first).
- Explicit in-shader specification for inputs/output indices, uniform locations, and opaque type binding points.
- Program separation, along with explicit locations for interface variables and special linking rules for such variables.
Incompatibilities
There are a number of incompatibilities left between OpenGL and D3D.