nanogui: Re: some ideas and my offer to contribute to the project.
Subject:
RE: some ideas and my offer to contribute to the project.
From:
Greg Haerr ####@####.####
Date:
3 Mar 2000 20:51:28 -0000
Message-Id: <C1962B36D9BBD311B0F80060083DFEFB0703DD@SYS.CenSoft.COM>
:In an alpha enabled system, this means that certain
:limitations are
:placed on even how it can update its own space (because its
:own background
:needs to be blended with others)
:And that's it. In your system, a layer could further support
:alpha directly
:in the layer object. (this theoretically could be done in the
:windows own
:updating routine, but would lead to some windows being translucent and
:others not supporting it)
In Microwindows, there doesn't need to be any restrictions on
what windows can draw, if they are alpha blended or not.
First, a bit is set in the window flags that states whether this
window is going to be drawn using alphablending. If so, then,
when the window draws to itself, it must first force all windows
intersecting with it underneath it to draw offscreen. then, it's
drawing is blended with this output for it's final output.
finally, all windows above this window that also have the
alphablend bit set need to be redrawn, using the same algorithm.
There you have it. It works, except that Microwindows currently
doesn't implement the offscreen part, since I ran out of time. Instead,
the drawing flickers a bit after windows are moved around...
In this model, there is no need to create a sprite
:system, one
:is already made, except for collision. If this is the case,
:my plan is to
:basically duplicate the code for windows, simplify it (just
:layers will be
:used), add collision, and that's it. It will be a seperate
:module so that
Implementing collision is as simple as IntersectRect on the
two window's frames. If the sprite doesn't use a rectangle
for collision, then use region intersection on the two
windows' sprite regions... done. No need for a separate module.
Regards,
Greg
