Advertisement Jump to content

Bitblitting with transparency

Recommended Posts

I'm writing my software renderer, and I'm trying to optimize bit blitting.

So I did write the blitter, but have hard understanding of how to do transparency. I know the usual way is to check if the pixel is black for example, is to skip that pixel.. but what about if I'm doing the blitting line by line ? What should I do in that case?

void Rasterizer::DrawSprite(sprite_ptr sprite)
    int numPixelsOnLine = sprite->width;
    int bytesToMove = numPixelsOnLine * 1;
    const uint8_t* src = sprite->frames[sprite->curr_frame];

    for (int y = 0; y<sprite->height; y++)
        uint8_t* destP =&m_FrameBuffer[(sprite->y + y)*320 + sprite->x];
        const uint8_t* srcP = &src[y * sprite->width];
        if (destP < m_FrameBuffer || destP > m_FrameBuffer + 240 * 320 || *srcP == 0x00)
        memcpy(destP, srcP, bytesToMove);

        destP += bytesToMove;


Share this post

Link to post
Share on other sites

MemCpy can't help here. But that routine is still useful for cases where you know transparency is not required (e.g. the user disables transparency on the sprite).

For transparent sprites, a 1-bit transparency could be done fast by replacing the overwrite with AND/OR and a mask generated from the transparent bit in the sprite. Prototype it in regular C code, then rewrite it with intrinsics (get inspired from how memcpy or memset are implemented) to make things a tad faster.

If the memory you're writing to is write-combined (e.g. some display buffer) then be careful to write continuously. The worst thing to do is an if-statement that skips writing to the target location for transparent pixels. But I must also mention that such memory types are not usually primed for reads, so it is generally a bad idea to do any pixel blending on such memory.

Share this post

Link to post
Share on other sites

One more idea to add is RLE-style memcpys/skips for 1-bit transparency. Depending on the transparency pattern in the sprite, this can either be very fast or more taxing (e.g. dithered transparency will be the worst case).

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!