-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Matteo Sisti Sette wrote:
Ohhh, ok!!!
[env ( is the way the texture blends with the color of the survace (i.e.
the one set by [color])!!!
ah right. that answer was late at night...
That's useless to my purpose: by blending mode I meant the
IOhannes m zmölnig escribió:
by blending mode I meant the way the
object (with its resulting color however it results from its color and
rexture) blends with its background
yep. you should be able to control this on low level with
[GEMglBlendFunc] and [GEMglAlphaFunc]
Great, I'll try to
IOhannes m zmölnig escribió:
yep. you should be able to control this on low level with
[GEMglBlendFunc]
It seems I must first enable blending using glEnable, that is, I guess,
[GEMglEnable]
Having a look at this link
http://pyopengl.sourceforge.net/documentation/manual/glEnable.3G.html
i forgot the patch.
++
Jack
Le dimanche 29 novembre 2009 à 15:41 +0100, Jack a écrit :
Le dimanche 29 novembre 2009 à 12:07 +0100, IOhannes m zmölnig a écrit :
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Matteo Sisti Sette wrote:
Ohhh, ok!!!
[env ( is the way the
Jack escribió:
I have done this patch, is it correct to use different blend modes ?
Er which patch?
--
Matteo Sisti Sette
matteosistise...@gmail.com
http://www.matteosistisette.com
___
GEM-dev mailing list
GEM-dev@iem.at
Matteo Sisti Sette escribió:
Now the question is (and it extends to all [GEMglAnything] objects): how
do I pass these constant values? I guess I cannot use symbolic names,
can i?
Ohhh great, it seems the answer is Yes you can!!
--
Matteo Sisti Sette
matteosistise...@gmail.com
Jack escribió:
i forgot the patch.
Excellent (as Miller would say... or Mr Burns)
That's exactly what I was trying to do.
I thought I could simply send [symbol GL_BLEND( (and other constant
names) to the GL objects.
Also, I was missing the necessary [alpha] object.
By the way, in your
By the way, it seems to me that with this approach I can achieve:
- additive blending (by setting both sfactor and dfactor to GL_ONE)
- multiplicative blending (by setting for example sfactor=GL_ONE and
dfactor=GL_SRC_COLOR)
but NOT for example subtraction or difference... or am I missing
Errata corrige:
Matteo Sisti Sette escribió:
- multiplicative blending by setting for example sfactor=GL_ONE and
dfactor=GL_SRC_COLOR
I meant sfactor=GL_ZERO
However the question remains:
but NOT for example subtraction or difference... or am I missing something?
--
Matteo Sisti Sette
Hi,
Consider the following patch, where the [gemhead] is connected to all
[separator]s (I'm not so good with ascii-art):
[gemhead]
...
[separator] [separator] [separator]
|| |
[color 1 0 0] | |
|
Matteo Sisti Sette a écrit :
Hi,
Consider the following patch, where the [gemhead] is connected to all
[separator]s (I'm not so good with ascii-art):
[gemhead]
...
[separator] [separator] [separator]
|| |
[color 1 0 0] |
cyrille henry escribió:
separator only separate geometry.
pix_separator separate textures.
i think nothing separate the color.
So am I the only one who misses an object that just separate
everything
By the way, as far as I have experimented, separator also separates
Matteo Sisti Sette a écrit :
cyrille henry escribió:
...
use trigger then.
Well that would oblige me to render things in a given order (namely the
coloured square last in this case) that may conflict with other order
requirements.
if you wish to render something white, then red, then
cyrille henry escribió:
if you wish to render something white, then red, then white, with the
same gemhead, you obviously need at least 2 color objects.
That's obvious only once one knows that [separator] won't reset the
color to its default value as it does with other things (not only
Hi Jack,
The image I'm wanting to get from the framebuffer into pix_ domain is
not, and should never be, rendered to the gemwin.
Unless I can render stuff to the gemwin that we can't see in the gemwin,
I don't see how pix_snap can help.
I suppose a workaround could be using a gemwin sized black
15 matches
Mail list logo
