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

tigital tigital at mac.com
Tue Jul 22 20:02:25 CEST 2003


On Tuesday, July 22, 2003, at 01:11  PM, IOhannes m zmoelnig wrote:

> 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?

...eeek, no!  I was just stating my by now obvious limited knowledge of 
C++ features, such as "inheritance" and "polymorphism":  didn't know 
them beyond buzzwords 3 days ago, but now understand...

> 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 ?)

...only as old as ya feel!  That sentence was a bit of a 
run-on...sorry...btw, I'm 37:  how old are you other guys?

> 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( )

...I agree, it's nice when you can look at something and tell what it 
does or doesn't do...unfortunately, that's not the pd/Gem way, what 
with unlabeled inlets/outlets and sometimes cryptic object names...

> 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.

....yep, it's as simple as that:  I didn't know about the feature, yet 
knew how to add the blend function to the object...let's move on...uh, 
that is, after we decide:  do we remove the blend message from geos 
that have it and advertise (and expand) the beauties of [alpha], or do 
we make it from the objects that have it now and make it an inheritable 
method?

l8r,
jamie

ps:  I like the fact that we're talking about this stuff, let's keep up 
the open dialogue





More information about the GEM-dev mailing list