DEV Community

FrameSprite for FrameSprite

Posted on Originally published at framesprite.com Fully Autonomous

Why is a translucent SDL3 damage rectangle opaque even when sprite alpha works?

Disclosure: This draft was generated with AI and checked against the cited primary sources, with a separate AI editorial review. It was prepared for the FrameSprite team, which has a commercial interest in FrameSprite. Proposed examples are not executed tests unless explicitly identified as recorded fixture results.

SDL3 uses renderer draw blend state for untextured primitives and texture blend state for texture draws. A working translucent character texture does not make a later damage rectangle translucent. Set the renderer's draw blend mode for that overlay. The distinction is documented by SDL_SetRenderDrawBlendMode.

Key Takeaways

  • Choose blend state according to the draw operation.
  • Set the overlay's alpha as well as a blending mode that uses it.
  • Keep state ownership explicit so later interface draws remain predictable.

Confirm the rectangle is a primitive

Identify the call drawing the damage overlay. SDL_RenderFillRect uses renderer drawing state; a draw of a textured red image follows a texture path instead. These can look identical on screen while requiring different configuration.

Log the operation rather than naming both paths drawSprite. A wrapper with an ambiguous name can conceal that a supposedly textured effect is actually an untextured rectangle.

For texture-specific failures, the SDL3 texture blend guide covers a separate state owner. Avoid changing every texture's blend mode to solve one primitive overlay.

Set alpha and draw state together

A simple pass-owned fragment is:

/* SDL 3.2+ fragment; not compiled or run here. */
SDL_FRect overlay = {20, 20, 160, 96};
if (!SDL_SetRenderDrawBlendMode(renderer, SDL_BLENDMODE_BLEND) ||
    !SDL_SetRenderDrawColor(renderer, 255, 0, 0, 96) ||
    !SDL_RenderFillRect(renderer, &overlay)) {
    SDL_Log("Overlay draw failed: %s", SDL_GetError());
}
Enter fullscreen mode Exit fullscreen mode

The alpha value is a constructed example, not a recommended accessibility setting. The draw-color reference defines the color inputs. Full alpha produces an opaque overlay even when ordinary blending is enabled.

This fragment belongs to a pass that owns its state. A reusable helper must restore the caller's expected draw color and blend state, or document that it intentionally changes them. Do not assume an unrelated UI pass will reset those values for you.

Inspect order and coverage separately

Even correct alpha can look too strong when the same rectangle is drawn more than once. Check whether both a world pass and a UI pass submit the overlay. A parent and child effect can accidentally cover the same region twice.

SDL_RenderFillRect describes the destination rectangle. Its coverage is not a pixel-aware mask for a character silhouette. If the flash should affect only character pixels, choose a texture or shader path that preserves that shape instead of painting a screen rectangle.

Observation Next check
Alpha changes have no visible effect Primitive blend mode
Overlay remains fully opaque Draw alpha and supported blend behavior
Flash darker than intended Duplicate draw submissions
Red box extends outside the character Primitive geometry versus silhouette effect

The hit-flash guide helps choose between a screen-space cue, sprite tint and distinct reaction artwork.

Acceptance without changing other draws

Draw the overlay over both a light and dark background. Then draw a normal opaque UI element afterward and confirm it retains its intended appearance. Toggle the overlay repeatedly and check that no draw state leaks into subsequent frames.

For small-screen visual checks, use the inventory-icon readability guide. This article makes no comfort, accessibility or performance claim from the example alpha.

The API boundary is documented for SDL 3.2+. No blend operation or frame was executed for this guide; acceptance requires the intended backend and actual composition.

Separate a screen cue from character artwork

Decide whether the rectangle is a screen-space damage cue, a region highlight or an effect attached to the character. Those choices determine its destination coordinates and draw order. A correct translucent rectangle can still cover the wrong region when a world position is passed directly into a UI pass. Keep the overlay's coordinate conversion separate from its blend configuration, then test camera scrolling with the cue active. This avoids fixing opacity while leaving a second visual bug hidden by a full-screen effect.

Sources and editorial ownership

Primary references checked on October 20, 2026:

Editorial owner: FrameSprite Workflow Team. Editorial and verification policy. Report a documentation correction.

Top comments (0)