Jump to content
  • Advertisement
Sign in to follow this  
lanceking

Quickly draw 8-bit bitmap into 16-bit frame buffer?

This topic is 4730 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I am writing a 2D blitter in software. All I can access is a 16-bit frame buffer pointer. When the bitmap is also 16-bit I can easily draw them use memcpy. But many of my bitmaps are 8-bit and I can't think of a way to draw them quickly. And are there any fast open-source software blitter available? I only want some simple functions like draw bitmap and something like png files. Rotate and scale is not very important for me. Many thanks!

Share this post


Link to post
Share on other sites
Advertisement
Is your 8-bit image indexed (i.e. a 256-colour palette), or some sort of RGB format? If it is indexed, does the palette contain 16-bit colours or 24-bit?

Assuming it's 8-bit indexed into a 16-bit palette:


blit8(surface16 *dst, unsigned int dx, unsigned int dy, unsigned int w, unsigned int h, unsigned int sx, unsigned int sy, surface8 *src)
{
for (uint y = 0; y < h; ++y)
{
for (uint x = 0; x < w; ++x)
dst[(dy + y) * dst.pitch + dx + x] = src.palette[src[(sy + y) * src.pitch + sx + x]]; // assuming pitch is in pixels, and **palette contains 16-bit colours**
}
}






Basically, instead of writing the source directly to the destination, you use the value at the source pixel as in index into the palette and write the value at that palette index to the destination. If your pixel at (38,22) has value 56, you write palette[56] to the framebuffer, not just 56. This assumes that the colours in the palette are also 16-bit and not 24. If that's not the case, you'll have to do some more work to get 16-bit colours from your palette.

Share this post


Link to post
Share on other sites
Thank you for your reply!
But I think this method is a bit slow compare to memcpy.
I want to know if other advanced blitters are doing the same thing?

Share this post


Link to post
Share on other sites
Why are you writing a software blitter in the first place? Using something like SDL is (usually) hardware accelerated and would probably be a lot faster.

Share this post


Link to post
Share on other sites
I am doing some work on cellphone and there seems no hardware support.. :...(
And I found normal bmp's palette is 24-bit... How can I use it on a 16-bit cellphone?

Share this post


Link to post
Share on other sites
Quote:
Original post by lanceking
I am doing some work on cellphone and there seems no hardware support.. :...(
And I found normal bmp's palette is 24-bit... How can I use it on a 16-bit cellphone?


Reduce the bit depth, naturally. If your 16-bit format is RGB 565, you grab the top 5 bits of the red channel, the top six bits of the green channel, and the top 5 bits of the blue channel, then pack them.

What's stopping you from converting all your images to 16-bit at load-time (or even offline?)

Share this post


Link to post
Share on other sites
Thank you superpig, I just think of this.
Then there is only one question left, is this assign
copy method( dest = palette[src]; ) fast enough?
Does there exist some way to accelerate it?

Share this post


Link to post
Share on other sites
I think that's about as fast as you can get it, I'm afraid; that's the operation you're doing conceptually, it can't really be boiled down any further. I guess your only option for optimization is to look into the rate of instruction execution - things like unrolling the loop, or using SIMD/vectorization to lookup/write more than one pixel per instruction.

Share this post


Link to post
Share on other sites
If you have enough memory, you can always convert the 8bit images to 16bit when loading and use the presumably faster 16bit copy at runtime.

Share this post


Link to post
Share on other sites
The deal with memcpy (at least on x86), is that it basically does what he outlined above but, because it's just an assign and there's no intermediate step, you can have the for loop run on the processor with a single instruction (rep movsd, probably). There's no way to do that if you need to do something like cast, go through a palette, etc, so that's your best bet. I'd probably convert everything to 16-bit at load or creation time, or if that takes too much memory see if there's an 8-bit display mode on the device.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!