nanogui: Thread: Alpha blending under the X-Windows driver for MW


[<<] [<] Page 1 of 1 [>] [>>]
Subject: Alpha blending under the X-Windows driver for MW
From: "Erik Hill" ####@####.####
Date: 5 Apr 2000 22:18:11 -0000
Message-Id: <20000405220759.38688.qmail@hotmail.com>

Ok, well, after a false start (overwrote my own code during a mad 
file-copying shuffle), I have done the first part of adding alpha-blending 
to the X-Windows driver under microwindows.  It works, such as it is.  
Screen-to-Memory and Memory-to-Screen work, at least under 16 and 24/32 bit 
modes.  Memory-to-Memory, since it depends on the fb* drivers, may already 
work, if not I'll add it.  Screen-to-Screen, which I don't imagine will 
often be used for alpha-blending anyway, is not yet supported, but will be.  
My motivation for changing the X-Windows driver (other than completeness, 
and my open-source soul) were so that I had a platform I could test my 
sprite system on.  Next I will be adding:

Generic, optimized, inlined functions for doing constant-alpha calculations 
on packed-pixel (frame-buffer style) display data.  This will speed up my 
current solution, which is macro based and is done color-by-color rather 
than pixel-by-pixel.  Also, it will allow all the frame-buffer style drivers 
to depend on the same functions, allowing code-reuse and reducing bugs.

Generic, optimized, inlined functions to do variable-alpha blending.  This 
is necessary for sprites.  It allows pixel-by-pixel control of the level of 
alpha between the source and destination.  It allows, for example, a sprite 
to be shaped (have parts completely see-through while other parts are partly 
or wholly opaque).  It also allows different parts of the sprite to be 
different levels of transparency, I think this will be usefull for all sorts 
of neat effects in video games and stuff.  I want variable-alpha blending to 
be handled by the driver as well, and not be local to the sprite system, for 
a lot of reasons.  Namely, it will allow hardware support of cards which can 
do alpha in hardware, and allow the sprite system to be bit-map/frame-buffer 
agnostic, without slowing it down.

My brother is also considering writing a bit-map driver for the Amiga, the 
computer that won't die.  I think microwindows would be good for the Amiga, 
personally.  Imagine sticking it on top of Linux-CE and running it on an 
Amiga -- a worthy (and acutually superior) replacement for 
AmigaOS/Intuition.  Anyone have any ideas for doing things under bitmaps?  
Especially a fast way of doing alpha-blending with bitmaps -- think about it 
-- not as easy as you may think.  Of course, it would be easy enough to 
"compile" the bits, run the standard alpha-blending code on it, and then 
"distribute" them back, but that will be PAINFULLY slow, especially on old 
hardware (like the Amiga).

Erik Hill

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

[<<] [<] Page 1 of 1 [>] [>>]


Powered by ezmlm-browse 0.20.