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
Copy file name to clipboardExpand all lines: articles/tutorials/advanced/2d_shaders/05_transition_effect/index.md
+11-2Lines changed: 11 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,6 +5,15 @@ description: "Create an effect for transitioning between scenes"
5
5
6
6
Our game is functional, but the jump from the title screen to the game is very sudden. We can make it feel much more polished with a smooth transition instead of an instant cut.
7
7
8
+
> [!note]
9
+
>
10
+
> In the previous chapters, we focused on the shader development workflow.
11
+
> 1. We set up a hot-reload system in [Chapter 02](./../02_hot_reload/index.md),
12
+
> 2. We set up a `Material` class in [Chapter 03](./../03_the_material_class/index.md),
13
+
> 3. We set up a debug UI using `ImGui.NET` in [Chapter 04](./../04_debug_ui/index.md).
14
+
15
+
> All of this prior work is going to finally going to pay off! In this chapter, you will be able to leverage the hot-reload and debug UI to experiment with shader code in realtime without ever needing to restart your game. You can start the game, make changes to the shader, tweak shader parameters, all without needing to recompile your project.
16
+
8
17
In this chapter, we will dive into our first major pixel shader effect: a classic [Screen Wipe](https://www.youtube.com/watch?v=8NAhAEQUk8M) we will learn how to control an effect over the whole screen, how to create soft edges, and how to use textures to drive our shader logic to create all sorts of interesting patterns.
9
18
10
19
At the end of the chapter, you will have a screen transition effect like the one below.
@@ -93,7 +102,7 @@ And recall that unless the `Progress` parameter is actually _used_ somehow in th
93
102
94
103
Now you can use the slider in the debug UI to visualize the `Progress` parameter as the red channel.
95
104
96
-
> [!caution]
105
+
> [!warning]
97
106
> But wait, how does the game know to render a `Progress` slider?
98
107
>
99
108
> Recall from [Chapter 03: The Material Class](./../03_the_material_class/index.md#setting-shader-parameters)'s _Setting Shader Parameters_ section that MonoGame's `EffectParameterCollection` knows about all of the compiled shader parameters The Debug UI we created in [Chapter 04: Debug UI](./../04_debug_ui/index.md#building-a-material-debug-ui) draws a slider for each parameter in the `EffectParameterCollection`. This means that as soon as a shader parameter is included in the compiled shader code, it will appear in the Debug UI without us needing to manually add or remove it.
@@ -121,7 +130,7 @@ The following shader helps visualize the x-coordinate of each pixel:
121
130
122
131
That results in this image, where the left edge has an x-coordinate of `0`, it has no red value, and where the right edge has an x-coordinate of `1`, the image is fully red. In the middle of the image, the red value interpolates between `0` and `1`.
123
132
124
-
> [!caution]
133
+
> [!warning]
125
134
> Where did the `Progress` slider go?
126
135
>
127
136
> When the shader is compiled, the `Progress` parameter is being optimized out of the final compiled code, because it was not being used in the final output of the shader in any way. The MonoGame shader compiler is good at optimizing away unused parameters, which is good because it helps the performance of your game. However, it can be confusing, because the `Progress` parameter appears to _vanish_ from the shader. Indeed, it no longer appears in the `EffectParameterCollection`, so the debug UI has no way of knowing it exists to render it.
0 commit comments