Direct3D Compatibility: Difference between revisions
Line 27: | Line 27: | ||
== Not compatibility features == | == Not compatibility features == | ||
These are features that look like D3D compatibility features, but are not. | 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. | ||
* | * [[Vertex Specification#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 | * Explicit in-shader specification for [[Type_Qualifier_(GLSL)#Vertex shader attribute index|inputs]]/[[Type_Qualifier_(GLSL)#Fragment shader buffer output|output]] indices, [[Type_Qualifier_(GLSL)#Explicit uniform location|uniform locations]], and [[Type_Qualifier_(GLSL)#Binding_points|opaque type binding points]]. | ||
* Program separation, along with explicit locations for varying variables. | * [[Shader Compilation#Separate programs|Program separation]], along with explicit locations for varying 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. |
Revision as of 23:24, 28 July 2013
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.
This article is a stub. You can help the OpenGL Wiki by expanding it. |
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 is not entirely reasonable.
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
Provoking vertex conventions
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 varying variables.
Incompatibilities
There are a number of incompatibilities left between OpenGL and D3D.