On Tue, 14 Mar 2000, teunis wrote:
> On Sat, 11 Mar 2000, Jon M. Taylor wrote:
>
> > On Fri, 10 Mar 2000, Andreas Beck wrote:
> >
> > > > int ggiStrechCrossBlit(ggi_visual *src, int sx, int sy, int sw,
> > > > int sh, ggi_visual *dst, int dx, int dy, int dw, int dh);
> > > > It should does the same as ggiCrossBlit, except it also performs
> > > > streching.
> > >
> > > Hehe - that was in old LibGGIs. we took it out for its complexity.
> >
> > Well, it is an atomic drawing op on Savage4 hardware at least.
> > But I agree that it is not necessary to have in LibGGI.
>
> Should be in either libGGI2d (imho this belongs there)
> or in a seperate lib devoted to BITBLT's
I have never understood why people think bitblts are so scary.
They are just another type of 2D drawing operation, with an additional
read stage.
> [clip - there's lots on list]
> > > - ggi2D equivalents of all LibGGI drawing primitives that obey the extended
> > > markups above.
> >
> > Including text?
>
> dinna think that libGGI2D should include fonts/text.
> It's a complex topic and is better suited with external libs. Like
> freetype :)
Agreed.
> > > - triangles,
> >
> > All flat, no perspective stuff?
>
> Makes sense. Non-perspective triangles are acceled on many cards
Just about any card, actually. Even the old Trio64 cards can do
2D texturemapped triangles! And modern cards can do whatever they want to
with the W component of the vertex.
> and
> could be used in some drawing ops. libGGI2D shouldn't have any
> 3D-specific stuff.... yet. Or maybe ever?
> (but sharing with libGGI3D or Mesa or ... is mandatory)
This sharing will be accomplished with a LibGGI2D target for Mesa
and a LibGGI2D visual module for LibGGI3D.
> > > polygons,
> >
> > Should this be different from triangles? We'll have to decompose
> > the polygons into triangles or triangle fans in many cases anyway, in
> > order to accelerate them efficiently with some hardware. DrawPolygon(vis,
> > triangle, ...) is just a degenerate case of this.
>
> Agreed. I also don't look forward to examining the case of non-convex
> polys. Decomposing polys is a pain!
LibXMI has code for this, quite a bit of it actually.
> > > arbitrarily positioned ellipses and arcs
> >
> > Yes.
> >
> > > - rounded-edge rectangles ?
> >
> > Multisource ROP blit, superimposing a circle and a square.
>
> Also duable using a modified circle algorithm. IMHO that's actually more
> accurate. I've done it both ways and prefer this....
Doing it with a blit reduces the number of special-case drawing
functions.
> > > - spline/bezier shapes ?
> >
> > What hardware accelerates these?
>
> Does it matter? It's still duable :)
Yes it matters. You generally want to design each LibGGI
extension library to drive a specific type of acceleration. Therefore it
helps simplify the design process a lot if you stick to as few types of
accels as necessary.
> > > - streched (Cross-)blitting.
> >
> > Stretching can be handled by allowing different source and
> > destination geometries.
>
> oooohhhh... Never thought of that :)
The real trick is figuring out how to work hardware accelerated
stretchblits and/or colorspace conversion blits in there |->. The
hardware featureset in this area is nothing but a morass of special
cases....
> > > Now go for it !
> >
> > Sure. I'll try to collect all the ideas from the mailing list
> > archives and come up with a proposal over the weekend. Is there still any
> > interest in the LibXMI idea, or should I assume that we are trying to
> > design the ideal 2D library from the ground up?
>
> libXMI's still interesting... -> but I prefer accels :)
LibXMI/GGI will provide accels. Lots of accels. Have a look at
the XMI headerfiles to see what can be done with the system, it is really
quite nice.
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
