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