On Fri, 9 Jun 2000, Andrew Apted wrote:
> 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)
"sc | dc" does not mean a bitwise OR between two 32-bit ggiPixel
values. It is shorthand for the individual R-G-B logical Sorry, that is
a bit confusing.
> corresponding to BlendFunc(SRC_ALPHA, ONE_MINUS_SRC_ALPHA). (Those
> formulas assume values between 0 and 1).
Well, I _could_ do this as well. Problem is, it forces alpha
representations into float[0..1] format, which requires thunking to the
mode-native alpha format and in many cases to the hardware-native format
before use.
> (BTW, the indenting in XMI_stubs_paintvisual() makes it very hard to
> read, even in no-wrap mode).
All that pixel code needs to be broken out into its own
sourcefile.
> > 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.
The important points are that it already works, it provides us
with a feature- and abstraction-rich target environment to test GGI with,
it doesn't require sub-libraries to get at the full functionality in any
environment, and it is also available on Win32. That last gives us a
chance to play with fast acceleration on a cross-platform target codebase.
> 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).
That's easy enough to fix.
> 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).
Sure.
> > 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.
Yes, although I am making an effort to minimize this.
> Removing miPaintedSet from the API would tip the barrel, making it
> pretty hard to keep calling it "XMI" in my opinion.
Well, there would still be quite a lot of stuff that would be the
same, too. Plus the CVS directory is already created and can't be deleted
|->.
> 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).
^^^^^^^^^^^^^^^^^^
That's usually what you use them for, yes. Batching primitives
like that is something that LibGGI doesn't do, and since it can be
accelerated in many cases there's justification for leaving them in the
API.
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
