> 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.
Please be precise with terms here. What you are talking about here is either
a convenience function or something that could be coded as a function in an
extension, but a _target_ is a different, though possible thing in that
context.
A "pixel doubling target" would be something like the palemu or the multi
target i.e. something you can hook into the target chain of LibGGI and thus
make the thing pixeldouble automatically.
This would in deed be a very useful thing to have and thus I would really
encourage people to write one.
It is a relatively simple thing to write, so anybody interested, please go
ahead. While this somebody is at it, (s)he might also want to write a
"turn" target that will turn the output 90, 180 or 270 degrees.
> 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?
Yes - with a target, see above. Not with an API call, as an API call is by
definition something you link to, so the recompile would be due.
> plain). i'd like to share this code, but i haven't got enough time to
> set up a ggi extension library.
If you want to scale the _whole_visual_ Don't do extension stuff.
It is useful as well to scale only blits, but that belongs to libblit IMHO.
> is anyone working on the sprite library, who has more time than i have?
C.Egger is working on all the sprite/overlay stuff.
Please also note, that I would like to see precise terminology here.
A Sprite is a _hardware_ thing that gets overlayed without disturbing
framebuffer content. You are talking about a blitter object (BOB) which
can be used to emulate sprites.
> also, as i love optimizing -- are there some critical routines in the
> current libggi that you would love to become somewhat faster?
Which routines are slow in particular ?
Try it. But please make sure to still have things portable. Assembly will
not be useful, unless it is nicely autoconf'ed. And being _exact_ is another
issue. It doesn't help to have a fast linedrawer that is not exact, as this
might lead to strange artefacts when for some reason the accelerator is
temporarily unavailable. (draw line with accel, remove it in SW, => pixels
remain, if the two don't agree).
CU, Andy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
