I've reduced my frustration to the simple example shown below starting from a brand new Windows Game. "circle" is just a 512x512 white circle with a transparent background.

By any estimation I can muster, this combination of SourceBlend and DestinationBlend should produce additive blending, but all that comes out is a red circle overlapping a green circle. Every available combination of Source/DestinationBlend produces an identical result. (For the record, additive blending is not what I'm actually trying to accomplish, but I figure that if I can get this to work, the other RenderState options will follow suit... spriteBatch.Begin(SpriteBlendMode.Additive) works just fine.)

What am I doing wrong? Is there something else I need to set in order to enable this type of blending? Is there a hardware requirement for it?

Thanks for any suggestions.

Alpha blending requires a not-fully-opaque alpha component in your color right? But Color.Green and Color.Red have have 255 as their Alpha component.

What happens if you use a smaller alpha value, like new Color(Color.Green, 128) and new Color(Color.Red, 64) ?

Or maybe thats wrong because you said spriteBatch.Begin(SpriteBlendMode.Additive) works just fine.

Maybe spriteBatch.Begin() overwrites your render settings, maybe you have to specify a SpriteBlendMode to get what you want.

SpriteBatch.Begin will modify the render states.
For the details of modification, please refer to Shawn's blog.

Craig Martin:

Alpha blending requires a not-fully-opaque alpha component in your color right? But Color.Green and Color.Red have have 255 as their Alpha component.

What happens if you use a smaller alpha value, like new Color(Color.Green, 128) and new Color(Color.Red, 64) ?

Or maybe thats wrong because you said spriteBatch.Begin(SpriteBlendMode.Additive) works just fine.

Maybe spriteBatch.Begin() overwrites your render settings, maybe you have to specify a SpriteBlendMode to get what you want.

With SourceBlend and DestinationBlend both set to Blend.One, 1 x red (1, 0, 0) + 1 x green (0, 0.5, 0) = orange? (1, 0.5, 0) which is additive blending.

Percy Tse:

SpriteBatch.Begin will modify the render states.
For the details of modification, please refer to Shawn's blog.

If SpriteBatch.Begin() modifies the render state, should it be fixed by changing the blend options after the call to Begin? I've tried this, and nothing changes.

lumberbunny:

If SpriteBatch.Begin() modifies the render state, should it be fixed by changing the blend options after the call to Begin? I've tried this, and nothing changes.

You might have to call below after changing them if it is inside a begin/end block.

GraphicsDeviceManager.ApplyChanges();

lumberbunny:

If SpriteBatch.Begin() modifies the render state, should it be fixed by changing the blend options after the call to Begin? I've tried this, and nothing changes.

Unless the default rendering mode for SpriteBatch is SpriteSortMode.Immediate (which, unfortunately, the MSDN docs do not specify) all rendering is deferred until the call to SpriteBatch.End.  Because all rendering is encapsulated within that call, there's no way to indirectly change the blend mode.

You can directly change the rendering mode with one of the SpriteBatch.Begin overloads (see SpriteBlendMode).  You could also try changing the render mode to SpriteSortMode.Immediate and set custom blend states after calling SpriteBatch.Begin, or between calls to SpriteBatch.Draw for layer specific blending. ;)

Craig Martin:

You might have to call below after changing them if it is inside a begin/end block.

GraphicsDeviceManager.ApplyChanges();

No luck. :(

DarkSquirrel:

Unless the default rendering mode for SpriteBatch is SpriteSortMode.Immediate (which, unfortunately, the MSDN docs do not specify) all rendering is deferred until the call to SpriteBatch.End.  Because all rendering is encapsulated within that call, there's no way to indirectly change the blend mode.

You can directly change the rendering mode with one of the SpriteBatch.Begin overloads (see SpriteBlendMode).  You could also try changing the render mode to SpriteSortMode.Immediate and set custom blend states after calling SpriteBatch.Begin, or between calls to SpriteBatch.Draw for layer specific blending. ;)

Fantastic. SpriteSortMode.Immediate did the trick. It seems that the render state is modified (by the SpriteBatch) in the call to SpriteBatch.Begin and before rendering in the call to SpriteBatch.End.

It seems odd that all of the blending functionality in the render state would only be usable in the Immediate sort mode. I'd love to hear other suggestions as to how the blending options could be relevant in other sort modes or why SpriteBatch modifies the values in both places.

Also, one final question: are there any downsides to SpriteSortMode.Immediate other than that the drawing operations need to be pre-sorted?

Thanks again to everyone.
 
(PS - Calling GraphicsDeviceManager.ApplyChanges is not required.)

DarkSquirrel:

lumberbunny:

If SpriteBatch.Begin() modifies the render state, should it be fixed by changing the blend options after the call to Begin? I've tried this, and nothing changes.

Unless the default rendering mode for SpriteBatch is SpriteSortMode.Immediate (which, unfortunately, the MSDN docs do not specify) all rendering is deferred until the call to SpriteBatch.End.  Because all rendering is encapsulated within that call, there's no way to indirectly change the blend mode.

You can directly change the rendering mode with one of the SpriteBatch.Begin overloads (see SpriteBlendMode).  You could also try changing the render mode to SpriteSortMode.Immediate and set custom blend states after calling SpriteBatch.Begin, or between calls to SpriteBatch.Draw for layer specific blending. ;)

Yes of course, I forgot about that :s

lumberbunny:

It seems odd that all of the blending functionality in the render state would only be usable in the Immediate sort mode. I'd love to hear other suggestions as to how the blending options could be relevant in other sort modes or why SpriteBatch modifies the values in both places.

I don't think the blend mode is intentionally available during Immediate mode, it's just expensive to change the blend mode every Draw call.  It would be cool to have a SpriteBlendMode.Custom option which left the blend states unchanged regardless of the rendering mode.

lumberbunny:

Also, one final question: are there any downsides to SpriteSortMode.Immediate other than that the drawing operations need to be pre-sorted?

It's said Immediate mode is faster, however I believe this is due to lack of sorting, which your app may still need to do (eliminating any gains).

DarkSquirrel:

I don't think the blend mode is intentionally available during Immediate mode

I get the same impression, although why else would it be available at all? Maybe it's just an artifact of the conversion to MDX?

DarkSquirrel:

It would be cool to have a SpriteBlendMode.Custom option which left the blend states unchanged regardless of the rendering mode.

My thoughts exactly. That is, if it changes, hopefully it moves in that direction rather than cutting off the capability altogether.

Thanks again everyone for your help.

lumberbunny:

DarkSquirrel:

I don't think the blend mode is intentionally available during Immediate mode

I get the same impression, although why else would it be available at all? Maybe it's just an artifact of the conversion to MDX?

DarkSquirrel:

It would be cool to have a SpriteBlendMode.Custom option which left the blend states unchanged regardless of the rendering mode.

My thoughts exactly. That is, if it changes, hopefully it moves in that direction rather than cutting off the capability altogether.

The blend states are used heavily during 3D and custom 2D rendering, so that functionality won't be going away.  It's just not available during SpriteBatch (except during Immediate rendering mode - again I think could be unintentional), this makes SpriteBatch very user-friendly, but a little less flexible.  Overall SpriteBatch is a great rendering tool though. :)