gum-raylib-rendering

Raylib's BlendMode.Alpha applies the same SrcAlpha/OneMinusSrcAlpha factors to the alpha channel, leaving the render target's alpha below 255. When your game composites that target a second time weighted by its alpha, translucent regions darken. Use a straight replace-copy or flatten the alpha first.

Renderer.Draw routes all blend state changes through BatchDrawCallCounter, and per-element renderables like Sprite, NineSlice, and Text call BeginBlendMode/EndBlendMode whenever Blend.HasValue. Since StandardElementsManager assigns Blend.Normal by default, this path fires for virtually all content.

No, raylib uses its own renderer with BatchDrawCallCounter and BlendModeExtensions, while MonoGame, KNI, and FNA go through a different renderer entirely. The MonoGame render-target gotcha is documented in docs/code/rendering/gumbatch.md, but raylib has no equivalent documentation yet.

BeginBlendMode calls TryGetSimpleRaylibBlendMode first, which maps Blend.Normal and Additive directly to canned raylib blend modes without checking _renderTargetBlendActive. Only Replace, ReplaceAlpha, SubtractAlpha, and MinAlpha reach the premultiply-aware path, so the protection never engages for ordinary translucent content. Tracked in issue #4204.

Single-pass compositing is unaffected because the color channels are still computed correctly. The Gum tool and gumcli screenshot --backend raylib never re-consume the leftover alpha, so the darkening only appears when a host application composites the render target a second time.