hello,
i will, but i don't have time yet.
can you try this exemple and tell me if both texturing mode work?
cyrille
vade a écrit :
can you change the shader and patch I posted to use rectangular
textures? I tried and only had a single texel mapped.
Maybe its an OS X thing?
On Jan 2,
Super nice !
I didn't know about the texunit 0 message you can send to
pix_texture. Are there other things I should know regarding
[pix_texture] before I start over again my texture storage
abstractions ?
Regarding texture coordinates, we can not access gl_MultiTexCoord1 due
to a bug in
Alexandre Quessy a écrit :
Super nice !
I didn't know about the texunit 0 message you can send to
pix_texture. Are there other things I should know regarding
[pix_texture] before I start over again my texture storage
abstractions ?
Regarding texture coordinates, we can not access
can you change the shader and patch I posted to use rectangular
textures? I tried and only had a single texel mapped.
Maybe its an OS X thing?
On Jan 2, 2008, at 12:18 PM, cyrille henry wrote:
using coordinate mode 0 : texture coordinate goes from (0,0) to
(size.x,size.y), so it's easier
very interesting, but also a good example on how to lock the computer
completely with gem - at least my old powerbook. i had to hard reset
because complete unresponsiveness. with [frame 10( it runs nicely
though. see my last post on how to avoid the lock-up.
max
Am 24.12.2007 um 21:35
Am 25.12.2007 um 20:53 schrieb vade:
What is the proper way of handing this in PD/GEM? Sorry for causing a
crash. I saw your PD Jitter patch, but frankly I think some drop frame
system should be built into GEM to handle this automatically.
maybe, i guess it's arguably if that's a feature or a
Of course :) Non realtime rendering would not have to evoke the drop
frame infrastructure at all :) for reference this works within Jitter,
so it ought to be possible.
On Dec 25, 2007, at 3:00 PM, Claude Heiland-Allen wrote:
vade wrote:
I think some drop frame
system should be built into
vade wrote:
I think some drop frame
system should be built into GEM to handle this automatically.
Please make this feature optional, as non-realtime rendering synced to
audio is a lot easier without auto-frame-dropping.
Claude
--
http://claudiusmaximus.goto10.org
Hm. Interesting. GEM does not have a drop frame system? Im not sure
about the scheduler differences between PD and Max/Jitter, but most
Jitter events are in a different queue and have a drop frame handling
method built in to each object, and when drawing with openGL one
should use a
vade a écrit :
Hm. Interesting. GEM does not have a drop frame system?
no.
i don't fell it would be very usefull.
that would create more problem that what it could solve.
of course, nothing should crash, just slow down the system.
Im not sure
about the scheduler differences between PD
cyrille henry wrote:
i think gem sheduling is just like using a metro with jitter.
(but no qmetro)
In my experience Gem scheduling is exactly in sync with Pd's (logical)
clock, measured with [timer] I always get 40ms when running at 48000Hz
audio, 25fps gemwin, with 60fps screen refresh rate.
Interesting. Again, I am speaking only from tangential knowledge, but
at least with Jitter, drawing to OpenGL with a regular metro is a big
NO NO, and can also hang your system, or at least seem to lock it up.
Thank you for the explanation Claude and Cyrille.
Max: I have a similarly spec'd
vade a écrit :
Yes, very efficient, and also give you LOTS of flexibility . the
regular GL_BLEND_MODES do not offer that many variations (not many are
useful for video). Want to make a GPU powered chroma key - shader.
Want to make feedback but have FSAA on, probably shader :)
why can't
Am 26.12.2007 um 00:06 schrieb Claude Heiland-Allen:
cyrille henry wrote:
i think gem sheduling is just like using a metro with jitter.
(but no qmetro)
In my experience Gem scheduling is exactly in sync with Pd's (logical)
clock, measured with [timer] I always get 40ms when running at
Am 25.12.2007 um 23:56 schrieb cyrille henry:
of course, nothing should crash, just slow down the system.
it doesn't crash, but it takes all cpu and there is no other way out
than making a hard reset (i tried everything exept maybe term though
ssh from a different computer).
m.
if you use feedback with a low alpha for the gl_clear_color, the
double/quadruple buffering for FSAA actually erases your previous frame. Thats
one technique.
:)
On Tuesday, December 25, 2007, at 06:43PM, cyrille henry [EMAIL PROTECTED]
wrote:
vade a écrit :
Yes, very efficient, and also
I just tried my powerbook 1.67 with OS X 10.4.9 and PD 0.4.03 nightly
12/24 (same as before), no crashing, solid 60fps with 2 QT movies
playing.
:)
On Dec 25, 2007, at 1:04 PM, Max Neupert wrote:
very interesting, but also a good example on how to lock the computer
completely with gem -
Nice, works for me. Is the idea that shaders are a efficient way of
mixing video?
.hc
On Dec 24, 2007, at 12:04 PM, vade wrote:
Hello
Here is a 2 channel mixer using overlay blend mode with GLSL. This
works, is decently fast and gives me the expected result.
If you want more blend
Yes, very efficient, and also give you LOTS of flexibility . the
regular GL_BLEND_MODES do not offer that many variations (not many are
useful for video). Want to make a GPU powered chroma key - shader.
Want to make feedback but have FSAA on, probably shader :)
etc etc. Want to make 4 way
19 matches
Mail list logo
