On Wed, 7 Jun 2000, Jon M. Taylor wrote:
Hi!
I've just waited until your updates are in the snapshots.
> This is kind of a long post. You may want to skim or skip it if
> you aren't into LibXMI development or 2D graphics.
>
> The pixel pipe portion of LibXMI seems to be up and running fairly
> well now. Texture mapping (and tiling) is working, as well as the alpha
> blending that people have been wanting for a while now in GGI. It ain't
> too fast just yet (unaccelerated), but it works properly. I've got types
> made up for every kind of blending/testing operation I can think of:
>
> * ROP256
What is that? I have no book about any Microsoft-Product.
> * Colorkey (transparency)
> * Texture filter (pixel multiply, bilinear, anisotropic, etc)
> * Alpha blend
> * Alpha test
> * Stencil mask
> * Z-buffer update/test/mask passthru (Here you go Christoph)
> * Multitexture blending with an arbitrary number of stages
>
> Not all of these are implemented yet |->.
Well, I look through your polygon-code, and I think the z-buffer stuff is one
of these, right?
Aehm, why you don't remove all malloc() and free() -calls out of the
polygon-code? This calls makes the polygon-drawing-code very slow.
If I read your code correctly, you are using a left and a right edge table for
any kind of polygon.
Make a malloc()-call in xmiAttach() and a free()-call in xmiDetach().
The malloc()-call allocates enough memory for each scanline (depends on the
current visual->virt.y). You have to check at every miFillPolygon()-call, for
the case a ggiSetMode()-call is made by an app. Then you have to resize it.
Believe me, this is much faster for unaccelerated.
I have it done in that way, in my 3dtk-project
(http://home.t-online.de/home/christoph_egger/3dtk/).
Note: My 3dtk has an own bitmap_t-Type, which comes from an old development
under DOS. It's similar to the ggi_visual. Your polygondrawer is much cleaner
than the mine, but it is faster than your unaccelerated one.
I have also an special code for triangles.
BTW: I will make a ground up redesign in the alpha5-developent-series. There
will be the bitmap_t-Type replaced by the ggi_visual. I am going to use your
libxmi for the basic 2d-stuff there. Unfortunatly, nothing has happened yet,
because I want to finish one feature in the alpha4-series.
> But I think I got everything important in the world of 2D (except more
> powerful clipping, see below) accounted for. If anyone knows of any good 2D
> drawing abstractions/blendmodes/buffer update/check/whatever in any other 2D
> graphics APIs which I've neglected to snarf up for use in XMI, please let
> me know.
Have a look at Allegro (http://www.talula.demon.co.uk/allegro/).
> I want the base namespace for the blend system well fleshed out,
> so that target implementors have a good number of acceleration hooks to
> implement.
I agree.
> And finally, a tough architectural question: should we hide the
> miPaintedSet type inside the stubs code, instead of exposing it and pasing
> miPaintedSets around like footballs at the application level as we do now?
> An miPaintedSet is a collection of span sets, and was nominally intended
> to be a convenient cache object for prerendered spans in X. You
> prerendered a bunch of spans, cached them offscreen in video memory or in
> system mem if necessary, and quickly rendered them on the server side in
> whatever video mode the server was in.
>
> AFAIK we mostly handle it the same way X does. However, since we
> became a LibGGI extension, span-based rasterization is now nothing more
> than a convenient internal rendering technique for the XMI stubs library.
> If we use a target which directly accelerates whole triangles or polygons,
> we won't need to deal with the individual spans anymore. This would be
> nice, because almost every XMI drawing function now takes an miPaintedSet
> pointer as an argument. This would also make possible the removal of the
> miCopyPaintedSetToVisual() function.
>
> However, this is a fairly radical departure from the X roots XMI
> comes from. I think it is a worthy change, but it will require every XMI
> function call to be rewritten to remove the old miPaintedSet references
> and other associated applications code. I'd like to get the pain over
> with soon, while there's not yet too much code which depends on XMI. Any
> objections from those using XMI? I won't be doing this tomorrow or
> anytime soon, but be prepared for this if you don't speak up.
I suggest, to hide the miPaintedSet type inside the stubs code, because I think
that LibXMI is cleaner and more maintainable.
> ******
>
> Wow, that was much more than I had intended to write. I never
> would have thought 2D graphics could be complex and interesting to code,
> but it really is.
*hehe* I believe you...
> Not so much as 3D, but right now that is a good thing |->.
I agree. :)
> If you can, please download and test LibXMI and let me know if you find any
> bugs.
Done. Works fine for me.
> I know that there are some stubborn segfaults lurking in edge cases, some of
> which I suspect were present in the old X consortium code itself. If you can
> manage to make one of the segfaults reappear reliably, that would be very
> cool.
Sorry. I got no segfault.
Christoph Egger
E-Mail: [EMAIL PROTECTED]
