On Thu, 8 Mar 2001, Tijs van Bakel wrote:
> hi, here's another episode in the series of "how to code your own ggi
> extension" ! :)
>
> i have coded a simple ggiPutBox() variant that doubles (or triples,
> &c) all pixels. this is very useful (to me) for displaying 320x200
> applications in higher resolutions.
>
> a few questions are troubling my mind for making a useful ggi
> extension out of this.
>
> imho it would be best if i could use this routine in conjunction with
> other targets, so that all previous ggi applications can be scaled
> without having to recompile the code. question 1: is this possible?
Yep. libblit should provide something like a ggiBltStretchBlit().
Internally it can make use of your code very well. But
note: The stretching must work in _any_ direction, not only from
lower to higher resolutions. Just think of stretching an image from
640x480 to 800x400 resolution. You see, what I mean?
> also, someone told me that this code would be well suited for a sprite
> library, and perhaps it is (although a general zooming routine would
> be even more useful). i have quite some code lying around that does
> general zooming in fairly optimized ways (especially for pentium
> plain). i'd like to share this code, but i haven't got enough time to
> set up a ggi extension library.
>
> is anyone working on the sprite library, who has more time than i
> have?
You are talking about libBSE? It is in alpha-state. And it doesn't
compile yet, until libOVL and libBLT has a stable API...
> i love writing simple routines (zoomers, rotozoomers, whatever),
> but designing libraries takes too much time (and i prefer to work
> on my own pet project library instead: a simple gui for common
> lisp (yes it uses libggi!))
>
> also, as i love optimizing -- are there some critical routines in the
> current libggi that you would love to become somewhat faster? perhaps
> i can do some useful _small_ work. it's getting a bit frustrating not
> to be able to lend a hand with a nice project that (according to some)
> needs it.
Well, there is a bug in libggi - more exactly: in ggiUnmap().
If you do something like this:
col.r = col.g = col.b = 0xFFFF;
pixel = ggiMapColor(vis, &col);
ggiUnmapPixel(vis, pixel, &col);
printf("r,g,b: (0x%X,0x%X,0x%X)\n", col.r, col.g, col.b);
gives this output:
r,g,b: (0xFF00,0xFF00,0xFF00)
instead of
r,g,b: (0xFFFF,0xFFFF,0xFFFF)
Andy is worring about a noticeable slowdown of ggiCrossBlit(), when
fixing this bug in the right way. So you can have a look at that for
optimizing... :)
CU,
Christoph Egger
E-Mail: [EMAIL PROTECTED]
