[<<] [<] 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 [>] [>>] |