On Sep 13, 2005, at 1:19 AM, vade wrote:
Hello
hiya,
Playing with the gl objects in GEM (0.90) on OS X (Pd 0.38-4
Extended, via Hans) , ive noticed that GEMglClearColor has 5
inputs, one for the gem render chain, 2 - r, 3 - g, 4 - b and
presumably 5 - alpha, yet, changing alpha results in no change in
the window Changing the RGB values does, just like [color] to
gemwin (as it should).Presumably, changing the alpha would act to let the scene draw
'over' itself, and give an easy way to do trails/blurring. Jitter
supports this feature (not griping.. just saying :), any chance ,
or workaround to get similar functionality, as I love the aesthetic
of it. Id rather not use snap2pix/snap2tex.
...ok, you have the correct inputs to the object, but there are a
coupla things to make sure of:
- the rgba inputs need to be 0-1
- after [GEMglClearColor] you need a [GEMglClear] that clears the
color buffer (GL_COLOR)
3. what is the gemhead ordering? Are you trying to clear everything
via [gemhead 1]? Or are you inserting this into every drawn object's
gemchain?
...that's the theory, anyway :-) In practice in GEM, things are not
exactly as they may appear...in other words, while I think the
glWrapper is one of GEM's most powerful features, there are a few
decisions made as default behaviors that may cause unexpected
behavior and frustration...fr'instance, glClearColor is called many
times behind your back, such as windowInit, window reset, and the
color message to [gemwin]...
...hmm, now going thru this, you may just want to play with that
message to [gemwin] in conjunction with the clearmask message, which
I think you'll need to send a [GL_COLOR< - [GLdefine] to...? I'll
have to try that out when I have GEM running...
...anyway, as ya can see, there's a bit more to the glWrappers than
just trying an object...it's really important to have a copy of the
"Red Book" on hand, but in general I've found that it's an extremely
quick and powerful way to prototype: no more compiling ;-)
l8r, jamie