On Sun, 21 May 2000, Christoph Egger wrote:
>
>
> On Sat, 20 May 2000, Jon M. Taylor wrote:
>
> > 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:
> >
> > 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.
>
> Nice. But how should a 3d-lib or a 3d-extension handle the z-buffer using
> this xmi-functions?
It doesn't. LibXMI is a 2D library. There are no z-coordinates
to use with a z-buffer.
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
