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