{"id":2740,"date":"2023-08-02T19:14:04","date_gmt":"2023-08-03T00:14:04","guid":{"rendered":"https:\/\/badecho.com\/?p=2740"},"modified":"2024-05-16T13:19:46","modified_gmt":"2024-05-16T18:19:46","slug":"alpha-spritebatch","status":"publish","type":"post","link":"https:\/\/badecho.com\/index.php\/2023\/08\/02\/alpha-spritebatch\/","title":{"rendered":"Changing Opacity of an Entire MonoGame SpriteBatch"},"content":{"rendered":"\n
\"Changing<\/figure><\/div>\n\n\n\n

Recently, while working on the Bad Echo game framework, I required the ability to apply an overriding amount of transparency to all sprites drawn within a particular SpriteBatch<\/code> batch operation.<\/p>\n\n\n\n

Unfortunately, as the first reply to this forum post<\/a> indicates, MonoGame’s SpriteBatch<\/code> class does not support such an operation. The suggestion given by the developer was to mess around with the internals of SpriteBatch<\/code> to implement said functionality.<\/p>\n\n\n\n

Reading this inspired me to solve this problem by doing just that, albeit in my own way. This article explores the solution I devised for this problem and the things I learned while solving it.<\/p>\n\n\n\n

The Problem<\/h2>\n\n\n\n

Let’s spend some time reviewing what I was having trouble doing. After that, I’ll demonstrate how to enhance the SpriteBatch<\/code> class to do what we want.<\/p>\n\n\n\n

A color’s transparency is specified by its alpha channel<\/em>, one of its components most commonly represented by the final element in a standard RGBA<\/strong> tuple.<\/p>\n\n\n\n

A minimum alpha value is fully transparent, while a maximum value is fully opaque.<\/p>\n\n\n\n

The Typical Way of Applying Transparency<\/h3>\n\n\n\n

Applying some degree of transparency to a texture or sprite we’re rendering is actually a straightforward affair. All we need to do is multiply the Color<\/code> we’re applying to the sprite by the desired alpha (the alpha being a float-type value between 0 and 1).<\/p>\n\n\n\n

SpriteBatch.Draw with Transparency<\/h6>\n\n\n
\n\/\/ Half transparency\nspriteBatch.Draw(firstTexture, position1, Color.White * 0.5f);\n\n\/\/ Less transparency\nspriteBatch.Draw(secondTexture, position2, Color.White * 0.8f);\n\n\/\/ Fully opaque\nspriteBatch.Draw(thirdTexture, position3, Color.White);\n<\/pre>\n\n\n
If this satisfies all your needs, you can stop reading right now! If your rendering logic is structured so that each component draws to its own sprite batch operation, it probably does.<\/p>\n\n\n\n
No Control Over Hierarchical Rendering Using a Single Batch<\/h3>\n\n\n\n
If you’re using a hierarchy of components, all drawing to the same SpriteBatch<\/code> within a single batch operation, the above approach isn’t helpful if we wish to exert control from the root.<\/p>\n\n\n\n
For example, let’s say we have a root rendering object that initiates a batch operation via SpriteBatch.Begin<\/code>. After creating the batch operation, the root passes said SpriteBatch<\/code> instance to its children, rendering objects responsible for calling SpriteBatch.Draw<\/code>.<\/p>\n\n\n\n
Given something like I just described, each of the children mentioned above will need to play ball if we wish to impose some batch-wide transparency effect.<\/p>\n\n\n\n
Where I Ran Into Issues<\/h3>\n\n\n\n
The Bad Echo game framework includes components that match this description exactly. In particular, the user interface system it makes available. It consists of a Screen<\/code> object that contains layers of controls and is responsible for measuring, arranging, and rendering on the screen.<\/p>\n\n\n\n
This user interface system is made available as a discrete game state<\/em> by the ScreenState<\/code> class, whose Draw<\/code> override is where I originally wanted a way to apply opacity to an entire sprite batch.<\/p>\n\n\n\n
A feature of the framework’s game states system is the animated transitioning of a state’s activation and deactivation. I desired to have entire user interfaces (controls and all) be able to fade in or out during these transitions (if so configured).<\/p>\n\n\n\n
ScreenState.cs Draw Override<\/h6>\n\n\n
\n\/\/\/ <inheritdoc \/>\npublic override void Draw(SpriteBatch spriteBatch)\n{\n    \/\/ Activation progress is exposed by the ActivationPercentage property.\n    spriteBatch.Begin(SpriteSortMode.Immediate,\n                      blendState: BlendState.AlphaBlend,\n                      samplerState: SamplerState.PointClamp,\n                      rasterizerState: new RasterizerState { ScissorTestEnable = true });\n    \n    _screen.Draw(spriteBatch);\n\n    spriteBatch.End();\n}\n<\/pre>\n\n\n
The code begins a sprite batch operation and then sends it off to the _screen<\/code>, which will itself be passing it to potentially many, many controls. It would sure be nice to have a way to set the opacity to a value based on the mentioned ActivationPercentage<\/code> property at the top here.<\/p>\n\n\n\n
One might quickly notice that SpriteBatch.Begin accepts an effect<\/code> named parameter that allows us to provide a different Effect<\/code> type to use during rendering passes. <\/p>\n\n\n\n
What if we try passing an instance of BasicEffect<\/code>, which is a built-in type that exposes a lovely Alpha<\/code> parameter for us to set!<\/p>\n\n\n\n
Using BasicEffect — Won’t Work<\/h6>\n\n\n
\n\/\/\/ <inheritdoc \/>\npublic override void Draw(SpriteBatch spriteBatch)\n{\n    var alphaEffect = new BasicEffect(spriteBatch.GraphicsDevice)\n                      {   \/\/ Using a power curve for a less boring animation.\n                          Alpha = (float) Math.Pow(ActivationPercentage, 3)\n                      };\n\n    spriteBatch.Begin(SpriteSortMode.Immediate,\n                      blendState: BlendState.AlphaBlend,\n                      samplerState: SamplerState.PointClamp,\n                      rasterizerState: new RasterizerState { ScissorTestEnable = true },\n                      effect: alphaEffect);\n    \n    _screen.Draw(spriteBatch);\n\n    spriteBatch.End();\n}\n<\/pre>\n\n\n
Boy, that’d make for a nice short article if this worked. But, it won’t. More than likely, nothing will visibly render on the screen when this code runs.<\/p>\n\n\n\n
Even though SpriteBatch<\/code> allows us to provide it with an effect, it internally relies on the SpriteEffect<\/code> type for things to actually end up being rendered correctly. <\/p>\n\n\n\n
Using a general-purpose effect like BasicEffect<\/code>, while perhaps sensible when dealing with vertex buffers and the like, isn’t going to fly at all with specialized renderers like SpriteBatch<\/code>.<\/p>\n\n\n\n
How We’ll Solve This<\/h3>\n\n\n\n
We’re on the right track. What we need is an effect that is like SpriteEffect<\/code>, in that it does what needs to be done in order for SpriteBatch<\/code> to work correctly, but one that also makes available an Alpha<\/code> parameter, like BasicEffect<\/code>.<\/p>\n\n\n\n
So, we’ll make our own effect. This will consist of a managed Effect<\/code>-based class that exposes an Alpha<\/code> property which we can manipulate, and the HLSL code for the actual shader which will be running on our pixels to make them transparent.<\/p>\n\n\n\n
Let’s start with the scary stuff: the HLSL shader code.<\/p>\n\n\n\n
Custom Shader Code<\/h2>\n\n\n\n
Shaders<\/a> are an advanced game development topic that I am starting to scratch the surface of myself. They are programs that (very simply put) run on every vertex\/pixel our graphics card is rendering.<\/p>\n\n\n\n
HLSL is the C-like language used when targeting DirectX with our shader; we use GLSL if we’re targeting OpenGL.<\/p>\n\n\n\n
From what I understand, we will always use HLSL with MonoGame, even if we’re targeting OpenGL. This is because we process shader code with the mgfxc<\/a> utility, which only accepts HLSL, but will convert the HLSL to GLSL using a parser if needed.<\/p>\n\n\n\n
This parser used is MojoShader, which translates bytecode as opposed to source code, and one which (from what I understand) MonoGame is moving away from.<\/p>\n\n\n\n
The reliance on MojoShader, coupled with the requirement to support many platforms, requires us to code our shaders using the effect format<\/em><\/a>, which is technically deprecated now with newer versions of DirectX.<\/p>\n\n\n\n
While it’s unfortunate to be learning to code using a deprecated format, we don’t have much of an option with MonoGame — it’s not a waste of time as far as learning goes, however, as the only difference between modern shader setups and effect files is that shaders would be in individual .hlsl<\/code> files as opposed to all of them being in a big .fx<\/code> file, combined through the defining of a technique<\/em>.<\/p>\n\n\n\n
What the Shader Needs to Do<\/h3>\n\n\n\n
With that rambling preamble concluded, let’s look at what our shader has to do:<\/p>\n\n\n\n