Index:
[thread]
[date]
[subject]
[author]
From: Andreas Beck <becka@rz.uni-duesseldorf.de>
To : ggi-develop@eskimo.com
Date: Sat, 3 Jul 1999 16:15:20 +0200
Re: Got to be a faster way.
> > DirectBuffer structure and see if it has shift/mask entries for
> > red/green/blue. If yes, the rest is pretty simple: Two nested loops going
> > through the visual, doing something like
> > *pixel=((bg.red>>shift.r)&mask.r) | ... green | ... blue.
> Well my development machine is limited to an S3 924 VLB card. SVGA lib
> doesn't like it in true color mode, and only a few resolutions work with 16
> bit color.
16 Bit will suffice for that to work. With true-color I rather mean "with
direct-mapped-colors".
> So I'm pretty much stuck with paletted modes on it.
In that case you use the clut-shift and offset and set a reasonable clut.
> > If that doesn't work, as you are using a palettized visual, you will very
> > probably want to set up the palette in a way that allows to calculate the
> > palette entry from the pixelvalues. Everything else is slow.
> How is the pallete set with ggiSetColorfulPallete? Is it a full 3-2-3 bit
> distribution? Or something else?
This is undefined. To allow for window-systems e.g. which have a common
palette to apps. On these a ColorfulPallete will include already set values
and try to optimize to get most colors with least additional ones.
You have to set up the palette yourself to be in control.
> With the pallete with set with 3 red, 2 green, and 3 blue (or some similar
> configuration (I might weight green heavier as the human eye is more
> sensitive to green)) and then set the pallete in order like:
>
> 000-00-000
> 000-00-001
> ...
> 111-11-110
> 111-11-111
Yes. I'd probably give the 2 to blue.
> So black is pal[0], white is pal[255], and all other colors are between
> starting with the blues. That way the byte value of low-order truncated
> color is also the pallete enty. Is that what you ment?
Yes. For palletized modes, this is the only really fast way. BTW: as two bit
are not very much: Who says you have to use bits ? It's a little more
performant, right, but you can as well use e.g. a 6*7*6 values setup,
which gives a fairer relation between the color channels.
> Should I use ggiPutHline or ggiPutBox? I'm redrawing the whole screen
> everytime (as the few times I don't are so rare that testing for them, would
> probally cost more time than saved when they happen).
That shouldn't matter much. 200x calling overhead isn't sooo much. You use
less memory with Hline, so I'd use that.
> > Setting a palette with an indexing
> > the can be calculated from the RGB values helps there.
> Like I was saying above?
Yep.
> Sorry, I don't follow. Lets just forget about the format of the visual,
> lets just concentrate on the pixel buffer. Or do I need to worry about the
> format if I use ggiPackColors?
No. However you might be faster doing the conversion yourself, as you can
make better use of the properties of the set up palette.
> Basicly what I'm asking, in an 8 bit palleted mode, will I find 1 byte per
> pixel that is the pallete entry?
Yes. Though you should rather query that using the ggiGetPixelFormat() call.
> For say a 24 bit mode, will I find 3 bytes per pixel?
Yes, though it will probably be padded to 4 bytes. Again use
ggiGetPixelFormat() to get the full information.
> At first I was using 2 dimentional arrays for all my buffers, thinking the
> screen has two dimentions. But then it hit me, if I know the width of the
> screen, after that many entries into my 1 dimentional array I'm on the next
> line. Very cool, no more nested loops. But I'm sure everyone here already
> knew that. :) Anyway, I'm friends with linear buffers now.
Yes. It's exactly what the compiler does for you when using multidimensional
arrays.
CU, ANdy
--
= Andreas Beck | Email : <andreas.beck@ggi-project.org> =
Index:
[thread]
[date]
[subject]
[author]