[GEM-dev] Re: "blend"-messages

[IOhannes m zmoelnig]

tigital wrote:
> On Tuesday, July 22, 2003, at 05:06  AM, IOhannes m zmoelnig wrote:
> 
>> hi
>>
>> i don't think, that there is any performance-issue in this, and it 
>> could save us all (jamie) a lot of time...
> 
> 
> ...sure, I'd love to save some time:  who wouldn't?  I've actually been 
> reading stroustrup to bone up on c++ stuff (remember:  I was schooled as 
> a neurobiologist, not a computer scientist); when I started the porting 
> of GEM to OSX last year (and we are about at it's one year mark), I knew 
> nothing beyond c...

do i hear some sarcasm?
anyhow, great things you have done so far.

> 
> ...chris and I actually talked about this blending stuff last weekend;  
> we knew that alpha was a possibility, but didn't know if it was a full 
> replacement...also, it takes less space in a patch to have a number 
> going into a blend message than it does to have a number going into a 
> colorRGB that goes into alpha that goes into the geo...I was just 
> uninformed of other ways to do blending and needed a transparent 
> cube...but at the same time you mention that alpha is somehow 
> inconsistent:  how so?   Does it allow internal transparancy (back to 
> front & front to back)?

hm.
i cannot quite follow the example with all the numbers going in and out 
objects (that's the second mail today, i don't understand, maybe i get 
old ?)
basically, you are saying, that it is preferrable to have smaller 
patches than bloated ones.
this of course is true, but i don't think 2 additional objects will 
bloat a patch.
then i think, a patch is clearer if its functionality is defined by its 
(graphical) structure (connecting [objects]) and not by internal states 
of objects (connecting with [messages( )

as for the inconsistency:
back then in february, i added an argument to the [alpha] object which 
allowed the setting of the blending function.
right now, there are only 2 blending functions  (GL_ONE and 
GL_ONE_MINUS_SRC_ALPHA) and they are addressed arbitrarily with "1" and 
everything else - this is i find not very intuitive which i addressed as 
"inconsistent".

as for documentation:
indeed gem has become big and undocumented (alas!, this is no news), 
when even the developers are not informed on features.


> ...don't recall this, and again, there is no help patch for 
> polygon_smooth...

mfg.asrd
IOhannes