OSDev.org

Hi,

I'm going to add wallpaper for my under construction VESA GUI, so to do this i need:
1) buffer for wallpaper (triple buffer)
2) copy wallpaper to double buffer
3) draw window manager to double buffer
4) blast double buffer into VGA buffer aka (0xA000)

This is the situation, when i load 8 bit BMP (256 color)to memory my BMPloader(...) change the palette and BMP drown perfectly,but window manager palette changed too

So my question is, how to combine tow layer (tow buffer) and each one has it's own palette,
without mixing between layer palette
any comments

if necessary i will post some pictures for my GUI

CheerS ,
a.T.d

Hi,

To me this sounds like you need to dynamically create a palette that suits both the background and *each* window (not just one window); or have a predefined/standard palette that everything must use; or make everything dynamically allocate palette entries.

The first option will give you the best quality results. In this case, for each frame you'd calculate the best palette possible, then find the closest available colour for each pixel (based on it's original/desired colour). Of course this is complex and has a very high overhead.

For the last option, different pieces of software try to allocate certain ranges of palette entries. For example, the code that draws the background wallpaper might ask for 32 palette entries (and might only get 10 palette entries because not enough are free), and then it needs to figure out how to use the palette entries to get the best results. This is complex and the results won't be as good as the first option. The advantage here is that you don't need to recalculate everything for each frame (much less overhead than the first option). In this case you'd probably also want to define a certain range as standard colours. For example, use the first 16 palette entries for standard CGA colours (black, blue, cyan, green, red, ..., light magenta, yellow, white) so that all software can use these colours in addition to any extra palette entries that have been allocated.

For 8-bpp modes I use the second option. I define the palette as "3r:3g:2b"; so that there's 8 shades of red, 8 shades of green and 4 shades of blue (where any pixel can be any combination of these shades); and so that it can be used like 15-bpp ("5r:5g:5b") or 16-bpp ("5r:6g:5b") or 24/32-bpp ("8r:8g:8b") where no code needs to care about the palette at all. This makes things a lot easier but the choice of possible colours (and therefore the quality of the resulting pictures) is worse because of it. The way I see it is that if people wanted a good range of colours they'd be using 32-bpp anyway...


Cheers,

Brendan

There's of course a middle road - you could reserve 64 entires for a fixed 2:2:2 palette (so that anything can show up to some degree of accuracy</sarcasm>) and then hand out the remaining 192 entries for applications to allocate. You can then give the needed entries to the top window, whatever's left to the next, and so on. If you run out of palette entries you can go recolor whatever is unavailable to what has been picked so far. (and always able to default to the "decent" 2:2:2)

Of course you can tweak around with the fixed palette - make it 2:3:2 to divide palette space in 128/128, or use 16 / 32 entries corresponding to the default VGA palette (the 16 EGA colors, followed by 16 greyscales).

In all, the problem is always going to be, should some window have priority of color selection over another (IMO it does), and how you are going to make up the current visible palette. The choice is up to you.

Combuster wrote:In all, the problem is always going to be, should some window have priority of color selection over another (IMO it does), and how you are going to make up the current visible palette. The choice is up to you.

One could have a GUI that shows everything in greyscale except the window that has the focus. Don't know how that'd work out though :).

To the OP: I'd advise using a 16bpp or 24/32bpp mode. This is slower, yes, but it'll save you a lot of headaches. These days it doesn't make sense I think to try to create a perfect solution for 8bpp paletted modes. If you reqally want to use 8bpp, use a fixed palette as suggested by others.


JAL

Hi,

Brendan wrote: For 8-bpp modes I use the second option. I define the palette as "3r:3g:2b"; so that there's 8 shades of red, 8 shades of green and 4 shades of blue (where any pixel can be any combination of these shades); and so that it can be used like 15-bpp ("5r:5g:5b") or 16-bpp ("5r:6g:5b") or 24/32-bpp ("8r:8g:8b") where no code needs to care about the palette at all. This makes things a lot easier but the choice of possible colours (and therefore the quality of the resulting pictures) is worse because of it. The way I see it is that if people wanted a good range of colours they'd be using 32-bpp anyway...

Combuster wrote: Of course you can tweak around with the fixed palette - make it 2:3:2 to divide palette space in 128/128, or use 16 / 32 entries corresponding to the default VGA palette (the 16 EGA colors, followed by 16 greyscales).

thank you all for comments, but i read such information in wiki
http://en.wikipedia.org/wiki/8-bit_color
and without sample code

jal wrote: To the OP: I'd advise using a 16bpp or 24/32bpp mode. This is slower, yes, but it'll save you a lot of headaches. These days it doesn't make sense I think to try to create a perfect solution for 8bpp paletted modes. If you reqally want to use 8bpp, use a fixed palette as suggested by others.

and you jal , truly i have lot of headaches, so i will try more than 8 bit for palette.and i think fixed palette is bad idea since wall paper or (background image) will change from user to user
and this will change the system palette

CheerS ,
a.T.d

If you are using VGA it only has a 18-bit (3 x 6) wide DAC anyway. So you could use 64 entries for gray scales (the full scale that a VGA can handle). The remaining 192 could be mapped to any value you like. If you map you colors to entries matching their gray scale value you can treat the bitmap as kind of both a gray scale and a bitmap. Just map the gray values to every 4. palette entry and make sure to set the 2 lowest bits to zeros.

This allows you to load any bitmap and display it in gray scale, resize bitmaps and use alpha channels etc. while still being able to display some colors. It works OK when developing and testing but you should go for a 24 or 32 bit mode instead.

Hope this inspire you

clange

Hi,

i586coder wrote:and you jal , truly i have lot of headaches, so i will try more than 8 bit for palette.and i think fixed palette is bad idea since wall paper or (background image) will change from user to user
and this will change the system palette

If the system uses a fixed palette, then by definition the system palette is never changed...

In this case the basic idea for drawing a picture (that has it's own palette) is to use the original pixel's value as an index into the picture's palette data to find the intended colour (e.g. in "6r:6g:6b" format) and then use the intended colour to find the closest available colour in the system's palette. For example, if a pixel in the original bimap is "colour #12" and the picture's palette data says that entry #12 is "0x00, 0x3F, 0x00" then the closest colour in the system palette might be 0x1C (if the system palette is "3r:3g:2b") and you'd use that for the pixel. Of course it can get a lot more complex than this (e.g. error diffusion).

The other thing I didn't mention is that applications, etc may use a virtual pixel format. For example, all applications could assume that all pixels are always 32-bpp ("8r:8g:8b"), where the video driver converts the pixel data into whatever the current video mode actually needs (which could be anything at all, including strange things like "8b:8g:8r", YUV, or "3r:3g:2b" or anything else). This makes application's programmer a lot easier because you don't need to care about the underlying hardware, and means that you can add support for other any pixel format in the video driver (without needing to modify the graphics code in every application).


Cheers,

Brendan