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]