[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