Index:
[thread]
[date]
[subject]
[author]
From: Club Neon <clubneon@hereintown.net>
To : ggi-develop@eskimo.com
Date: Fri, 2 Jul 1999 06:02:44 -0400
Re: Got to be a faster way.
Wow, my last post was a little 'off'. I'll apologize for that right now.
> How about creating a memory target visual in your format
> and
> then crossblitting the image to the true visual and then
> getting
> the box into a raw memory buffer? Then successive draws
> will
> only require puts? Not exactly a great way, but it's better
> than nothing for now? We can call it a "hack." :P
That is still difficult. See the tiles for my engine are stored in .png
files. libpng likes to return 64 bit pixels. That is 4 16 bit componets,
red, green, blue, and alpha. That is exactly what I need. The GGI lib
seemed like a good choise because of it's 16 bit RGB componets. I wrote a
pretty spiffy layer rendering routine, that just dives down through all the
layers of tiles until it a solid pixel or falls through the bottem layer and
returns a background color. As the routine is passing through the layers,
it takes into account a scroll offset that will allow the layers to be
scrolled at different rates and/or in different directions.
The reason I give that long explaination is so it is understood that every
frame can (and more than likely will) be totally different from the last.
It also demonstrats that my final composite data is in 48 bit color form for
a reason. I have tried using initial tiles of the bit depth of the display,
but that means on an 8 bit display every tile must have the same pallete.
The rounding errors from mapping 16-16-16 bit triplets to something like
3-2-3 even if I keep the 16 alpha channel, there can be almost no color
variation and the final composite comes out as garbage. But in my (slow)
color mapping, pixel putting routine even the 8 bit results were very
exceptable.
So what I need is a fast way to get these 48 bit colors mapped down into a
buffer that can be put into the display visual. I think low-order
truncation of bits might be accurate enough for the map down.
> The great thing about GGI is the ability for anyone to
> write
> extensions. If you don't like something, write an extension
> to take advantage of the raw hardware or targets. The
> layout
> to GGI is pretty simple to understand too. A lot of other
> code i.e. [put your most hated pachage name here] is hard
> to follow through because of all the
> MACROS and all the other mess.
> ~K.P.
I'm really considering writing a put buffer manipulation extention lib. I
will stand by my belief that the core funtions in libggi are too slow to be
of any use (so why have them?). So it seems that they only way to do
anything that still slightly resembles using libggi is the put functions
from a raw buffer that isn't get'ed, but just written to.
Now for a question: Is a memory visual different than raw get/put buffer in
structure? If so (I would think that they are), can anyone give me an
explaination of both?
I guess that's enough,
Chris
Index:
[thread]
[date]
[subject]
[author]