hi, although this topic isn`t an issue as such I thought I`d point something out regarding backward compatability - the nature of both x10 and x11 is to remove the fixed function pipeline but in both cases they can emulate it by default. This pretty much means that any dbp x10 or x11 build will be limited to not use x9, I don`t think lee would have a choice in the matter. SM5.0 still uses pretty much the same components of dx as SM4.0 with additions from what Ive read so far, so it would make sense to me if lee was to wait for a while and write it for x11, besides, how many users here are advanced enough to utilise the features on offer in x10/11? I`m willing to bet not many, most probably don`t have x9 nailed yet as its the shader side of coding that holds the most difference for average DBP user. DBP is basic level so I would think if he is gonna rewrite it it would be better to make x9 good and solid(its in reasonably good shape now) and put off an x11 release to such a time when x9 machine setups are no longer common place, after all it all depends on what the target audience is for DBP as thats where TGC will continue to make good sales figures as their flagship product has a specific niche audience.
Here is some info regarding x10 and x11 from a hoard of info I`ve collected that may help folk come to some understanding, sorry I`m unable to cite the source for this as I do a lot of copy/paste of relevant info from lots of sources but only hold onto info that makes some sort of sense to me;
DirectX 10 Pipeline
The DirectX 10 Pipeline offers the programmer three programmable shaders; Vertex Shader, Geometry Shader and the Pixel Shader, which are all compiled using shader model 4. There are also a couple of non-programmable stages; Input Assembler, Rasterizer, Output Merger and Stream Output Stage. Although these stages are not programmable, it is still possible to configure them by setting different render states through the DirectX API.
Input Assembler Stage
As a draw call is made, the first stop for a mesh is the Input Assembler Stage. The objective of this stage is to assemble geometric primitives from vertex and index data that is stored in the video memory, depending on the primitive topology set from the DirectX API.
In DirectX 10, there are five basic types of primitives; Point list, line list, line strip, triangle list and triangle strip. All basic primitive types, except point list, can also be stored with adjacency data providing information about neighboring primitives. The difference between a strip and a list is the way the vertices will be bound together. When the primitives have been assembled, the vertices are fed into the Vertex shader.
Vertex Shader
The Vertex shader is the first programmable shader in the pipeline and is invoked once for every vertex point in the mesh. A triangle consists of three vertex points, and each of these points describes where two polygon edges meet. Apart from positional data a vertex point usually contains other information pertaining to that point, such as normal data and texture coordinates.
From here it is possible to add various effects, such as transformation or lighting, to each vertex point and then send it further down the pipeline.
Geometry Shader
The Geometry shader is optional and is invoked once for every primitive inputted to the pipeline, which can be either a point, line or a triangle, and each vertex point on the primitive can then be accessed in the shader.
The unique ability of the Geometry shader is that it gives the programmer the possibility to create or destroy geometry in a mesh.
Output from this shader differs from the Vertex shader as it outputs primitives through a stream, which does not have to be the same as the input primitive. This stream can be either a Point stream, Line stream or a Triangle stream and will output the primitives as a strip. In order to format the output as a list the RestartStrip function has to called after each complete primitive, e.g. three vertex points if the output is a triangle list, has been appended to the stream.
Stream-Output Stage
The Stream-Output stage allows the programmer to stream vertices to a buffer from a Geometry shader, giving the programmer the possibility to perform calculations on the GPU without drawing to the back buffer. Streaming can also be done from a Vertex shader if the Geometry shader is disabled.
Rasterizer Stage
The Rasterizer Stage is responsible for transforming the vertices from homogenous clip space to 2D-coordinates residing in the view port. The x and y-coordinates of the vertex point describe the position in the view port in units of pixels, while the z-coordinate normally remains untouched as it is used for depth testing. When this transformation is done all the vertex attributes has to be interpolated linearly for each pixel to get their correct values.
It is possible to configure the Rasterizer Stage by setting a Rasterizer state. Here one can decide if triangles should be back or front face culled, the winding order of the triangles and if the triangles should be drawn in solid or wireframe mode.
Pixel Shader
The Pixel shader operates on per pixel level and is responsible for calculating the color of a pixel.
Output Merger Stage
The Output Merger stage is the last stage before a pixel is drawn to the back buffer. Here two tests can be done to determine whether a pixel should be drawn or not, a depth test and a stencil test which can be configured by setting a Depth Stencil State through the DirectX API. The tests are done using two buffers, a depth buffer and a stencil buffer, which has to be at least the same size as the back buffer.
The depth buffer stores the depth information of each pixel drawn to back buffer. The pixels in the depth buffer contains a floating point value ranging from 0.0 to 1.0, which allows the depth test to compare the current pixel's depth with the corresponding pixel's depth on the depth buffer to determine if the pixel should be drawn or not.
The stencil buffer stores a value for each pixel drawn to the back buffer, making it possible to flag pixels. This allows the stencil test to check against this buffer and determine if the pixel should be drawn to the back buffer or not.
DirectX 11 Pipeline Additions
As of the introduction of DirectX 11, two new programmable shaders were added; the Hull Shader and the Domain shader, which are compiled using shader model 5. Along with these two shaders, a fixed function tessellator was also added.
With the new shaders working with different types of patches; quads, triangles or isolines, each patch having 1 to 32 control points, 32 new primitive topologies have been added called control point patchlist, one for each number of control points.
Hull Shader
The Hull Shader consists of two functions. One main Hull shader which performs calculations on each control point separately and one patch constant function that performs calculations on the entire patch. Before the Hull shader can be called, a few attributes needs to be set:
[domain] – Specifies which type of patch the Hull shader will be working with.
[partitioning] – Indicates how the tessellator will interpret the tessellation factors.
[outputtopology] – For the tessellator to be able to create the right barycentric coordinates, it needs to be aware of which kind of primitives we want to deal with in the domain shader later on, which this attribute will tell us.
[outputcontrolpoints] – Describes the number of control points that will be output from the Hull shader.
[patchconstantfunc] – Specifies the name of the patch constant function.
Fixed function tessellator
The fixed function tessellator generates barycentric coordinates depending on a specified subdivision level, which needs to be set and passed on by the patch constant function. The tessellator splits the subdivision description into two parts, inside tessellation factor and outside tessellation factor. With a uniform tessellation factor the tessellator produces a number of vertex points equal to the factor along the border and a number of vertex points consistent with subdivision level (factor – 2) to 1 residing inside the original triangle. How the tessellator iterates over the subdivision levels depends on the partitioning attribute, e.g. setting the attribute to fractional odd the tessellator will only create new points for odd subdivision levels.
Domain Shader
The Domain shader can be seen as a post-tessellation Vertex shader and is invoked for every barycentric coordinate that is generated by the Tessellator. It is responsible for creating new vertex points using the barycentric coordinates, the primitive control points from the main Hull shader, and the patch data received from the patch constant function. How to calculate the new vertex points using this data is described in the next chapter. When tessellation is active the Geometry shader, which is located after the Domain shader, cannot use adjacency data in the mesh as it is invalidated by the recalculation of all vertex points.
Edited to make more readable (@GG - I was hoping to use snippets to hide info so that you don`t have 1 long post, didn`t realise using snippets would stretch it all the way across screen, my apologies)
Edit2: earlier I stated
Quote: "can emulate it by default"
by this I mean that in the event dbp user wishes to do something that uses dx? but is something that previous dx9 dbp wouldn`t require a shader for then lee would write the default behaviour to emulate it. This appears to be the case in the dbpx10 mod TGC provide. I should imagine this is also the case for other changes to direct x components.
