On Sun, 21 May 2000, Jon M. Taylor wrote:
> 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.
There is a missunderstanding. What I meant is, how a 3d-lib has to
handle using a z-buffer _and_ using the libxmi-function, so that the
3d-lib doesn't have to have its own texture-implementation.
I hope I am clear for now.
Christoph Egger
E-Mail: [EMAIL PROTECTED]
