You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The reason this line exists is to convert the vertices from world-space to clip-space.
100
100
@@ -133,20 +133,20 @@ Follow along with the steps to set up the effect.
133
133
134
134
1. We need to add a vertex shader function. To do that, we need a new `struct` that holds all the input semantics passed from `SpriteBatch`:
135
135
136
+
[!code-hlsl[](./snippets/snippet-7-09.hlsl)]
137
+
136
138
> [!tip]
137
139
> Use a struct for inputs and outputs.
138
140
>
139
141
> The default vertex shader accepts all 3 inputs (`position`, `color`, and `texCoord`) as direct parameters. However, when you have more than 1 semantic, it is helpful to organize all of the inputs in a `struct`.
140
142
141
-
[!code-hlsl[](./snippets/snippet-7-09.hlsl)]
142
-
143
143
2. Now add the stub for the vertex shader function:
144
144
145
145
[!code-hlsl[](./snippets/snippet-7-10.hlsl)]
146
146
147
147
3. And finally modify the `technique` to _include_ the vertex shader function. Until now, the `MainVS()` function is just considered as any average function in your shader, and since it wasn't used from the `MainPS` pixel shader, it would be compiled out of the shader. When you specify the `MainVS()` function as the vertex shader function, you are overriding the default `SpriteBatch` vertex shader function:
4. The shader will not compile yet, because the `VertexShaderOutput` has not been completely initialized. We need to replicate the `MatrixTransform` step to convert the vertices from world-space to clip-space.
152
152
Add the `MatrixTransform` shader parameter:
@@ -187,7 +187,7 @@ As a quick experiment, we can show that the vertex shader can indeed modify the
187
187
188
188
And change the vertex shader to add the `DebugOffset` to the `output.Position` after the clip-space conversion:
The sprites now move around as we adjust the shader parameter values.
193
193
@@ -197,7 +197,7 @@ The sprites now move around as we adjust the shader parameter values.
197
197
198
198
It is important to build intuition for the different coordinate systems involved. Instead of adding the `DebugOffset`_after_ the clip-space conversion, if you try to add it _before_, like in the code below:
Then you will not see much movement at all. This is because the `DebugOffset` values only go from `0` to `1`, and in world space, this really only amounts to a single pixel. In fact, exactly how much an addition of _`1`_ happens to make is entirely defined _by_ the conversion to clip-space. The `projection` matrix we created treats world space coordinates with an origin around the screen's center, where 1 unit maps to 1 pixel. Sometimes this is exactly what you want, and sometimes it can be confusing.
203
203
@@ -211,13 +211,15 @@ The world-space vertices can have their `x` and `y` values modified in the verte
211
211
212
212
To check, try modify the shader code to adjust the `z` value based on one of the debug values:
> Keep in mind that if you modify the `z` value _too_ much, it will likely step outside of the near and far planes of the orthographic projection matrix. If this happens, the sprite will vanish, because it the projection matrix does not handle coordinates outside of the near and far planes. In the example above, they were defined as `0` and `-1`.
0 commit comments