Jon M. Taylor writes:
> * ROP256
> * 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
Looks very nice.
> Not all of these are implemented yet |->. 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.
I find your "Alpha" blending types rather strange, (sc | dc),
(sc & dc), etc... Quite different to what I expected, which is
basically the OpenGL style:
Rdest = Rsrc * Asrc + Rdest * (1 - Asrc)
Gdest = Gsrc * Asrc + Gdest * (1 - Asrc)
Bdest = Bsrc * Asrc + Bdest * (1 - Asrc)
corresponding to BlendFunc(SRC_ALPHA, ONE_MINUS_SRC_ALPHA). (Those
formulas assume values between 0 and 1).
(BTW, the indenting in XMI_stubs_paintvisual() makes it very hard to
read, even in no-wrap mode).
> This abstraction scheme will allow for very fine-grained
> optimization of the acceleration of 2D pixel blending in the targets, but
> the back-end "intraface" I'll need to export to create a "blend" target
> set will be a strange thing for sure. Ideas are welcome here. I think
> I'm going to use Glide as my reference target implementation for
> acceleration of blending in LibXMI. I'd like to use OpenGL, but we don't
> have an OpenGL target system for LibGGI just yet so that seems a bit
> premature. Glide is simpler and easier to work with, and it has a nice
> LibGGI target to build on.
Glide sounds reasonable for development, since it works already with
LibGGI. But my experience with OpenGL is that it's pretty easy to
work with as well (apart from a minor annoyance: using a bottom-up
coordinate system from the screen and textures).
Prolly the main use of GL (or Glide for that matter) is rendering
whole primitives (like polygons), but I think for some applications is
could even be a big win just using the GL line primitives to renderer
the scanlines of an miPaintedSet (on 3D hardware of course). If I get
some time, I might try this idea out (won't be anytime soon though).
> The miPixmap objects are supposed to be "fast visuals" - opaque
> references to pixel-typed rectangular regions bound to a ggi_visual and/or
> a ggi_directbuffer which are much more lightweight than a ggi_visual
> struct and thus lend themselves well to such applications as image
> caching, sprites/pointers, typed buffers and large tree/graph data
> structures.
Yep miPixmap sounds good.
> 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.
It seems that your XMI is becoming less and less like the "real" XMI.
Removing miPaintedSet from the API would tip the barrel, making it
pretty hard to keep calling it "XMI" in my opinion. That's not a
criticism, I think it would be cool to take a big axe to the API and
make something much cleaner and more GGI-like (e.g. miPoint and
miRectangle are a bit painful unless doing lots of them).
> If you can manage to make one of the segfaults reappear reliably,
> that would be very cool. In any case, any and all feedback is
> appreciated.
Tested it here, works nicely, and no segfaults.
Had a problem compiling though, the demos check for a HAVE_RANDOM
define, but as far as I can tell there is no check for this in
configure.in (thus doesn't appear in config.h). This caused a problem
because `random' gets #defined to `rand', but both are declared in
stdlib.h here.
Cheers,
__
\/ Andrew Apted <[EMAIL PROTECTED]>
