On Sat, 20 May 2000, Brian S. Julin wrote:
>
> On Fri, 19 May 2000, Jon M. Taylor wrote:
> > It would be very easy to add these two functions quickly to the MISC
> > extension, and lots of targets have accelerated cursor support. LibWMH,
> > LibGWT, LibXMI and Berlin could all use cursor functions....
>
> Just to be utterly redundant, the sprite/bob/cursor/texture feature
> management API not being developed is really what is holding GGI back
> bigtime. We need that more than we need 3D IMHO.
True. I'm hoping that the XMI stuff I'm working on now, and which
will hopefully be released this weekend, will provide part of the
solution. XMI now has:
1: Lightweight miPixmaps which contain a visual pointer and/or
directbuffer handle, rectangular coordinates, and a ggi graphtype. That
last allows XMI to use the miPixmap as the primary unit of rendering
sources and destinations instead of a heavyweight ggi_visual. You
obviously have to use matched-type visuals and miPixmaps if you are not
using a directbuffer, but if you do have a DB available you can store
whatever you want.
2: Chainable three-source blend stages which can do pretty much any type
of pixel-pipe effects: texturing, filtering, colorspace conversion, alpha
channel/test, colorkey, etc etc. The stage inputs untyped but usually
pointers to miPixmap structs for blitting, texturing and the like. The
stages are typed (XMI_BLEND_TEXTURE, XMI_BLEND_STENCIL, etc.), so it
should be easy to walk the list for each miGC struct (where they are kept)
and optimally accelerate the different stages on a per-target basis.
This is similar to DirectX's multitexturing but more generalized and
flexible.
What is missing now is the idea of an object which describes a
persistent mapping between an miPixmap and a location within a visual, and
perhaps an automatic flush-sprites-last hook for ggiFlush(), and that's
all you'd need for real sprite support, right?
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
