From: Evan Martin <txs@concentric.net>
  To  : ggi-develop@eskimo.com
  Date: Sat, 15 May 1999 14:21:37 -0700

Re: Semi-Snag in PyGGI...

Marcus Sundberg wrote:
> 
> Jim Meier wrote:
> > Sorry about that - just quick pseudocode. To make it make sense, the ggi_pixel p should
> > be renamed this_is_the_pixel_to_copy_many_times and the ggi_pixel*p should be renamed to
> > this_is_an_index_into_the_pixel_buffer.

Yikes!  Those names are a bit much, aren't they? :)

> > However, incorporating Evan Martin's fix of my broken pointer arithmetic, we end up
> > with:
> >
> > int block_size=(number_of_pixels*actual_pixel_size_in_bytes);
> > ggi_pixel this_is_the_pixel_to_copy_many_times=ggiMapColor(vis, &color);
> > ggi_pixel *pixel_buffer=(ggi_pixel*)malloc(block_size);
> > uint8 *this_is_an_index_into_the_pixel_buffer=pixel_buffer
> > for(i=0;i<number_of_pixels;i++){
> >
> > *(ggi_pixel*)this_is_an_index_into_the_pixel_buffer=this_is_the_pixel_to_copy_many_times;
> >
> >     this_is_an_index_into_the_pixel_buffer+=actual_pixel_size_in_bytes;
> > }
> 
> Ok that will work in concept, as long as you have one version of the
> loop for each of 8, 16, 24 and 32 bit/pixel modes, and make
> this_is_an_index_into_the_pixel_buffer a pointer to the apropriate
> type.

I don't see why it wouldn't work for different color depths.
The pointer (this_is_an_index...) will be advanced the correct number of
bytes for each depth.
Could you explain?

> But there is absolutely _no_ reason to do what you do above because
> it will be upto one hundred times slower than using ggiDrawHLine/VLine.

I apologize for giving you code that didn't quite suit the situation. 
The code I pasted
was written as an example for another person's problem.
I would have used ggiDrawHLine, but the original code involved some sort
of palette
lookup that required an operation on each individual pixel.

For drawing a line of a solid color, definately use the ggi function.

-- 
Evan Martin - txs@concentric.net - http://e.x0r.ml.org