The problem you see has to do with DirectShow using a different set of coordinates for drawing. An AVI clip opened with pix_film that also uses DirectShow should not have this problem. An updated version of GEM that does this can be found at
http://gem.iem.at/download/SNAPSHOTS/gem-CVS20060914-w32-i686-bin-doc.zip
pix_draw is not the fastest way to get images drawn. Try pix_texture and the rectangle object. A 640x480 or 1024x768 window is filled with [rectangle
5.33 4].
On 12/8/06, cdriko@free.fr <cdriko@free.fr> wrote:
thanks for your help
About compositing 3D
I can't use pix_snap because my GLoutput is in 1024 768
and I think that the computer will cry to pix_snap and pix_resize
continuously
About the problem with the pix_mix object
at the begining, I put a pix_flip object before the right inlet
with a result strange : picture is alternativelly flipped up and down
the solution that I found is by the pix_film source object :
before, I used a metro to changing number of image
(to get the possibility to change the rate)
in fact, if I replace this metro by a derivating bang from the gemhead of the
pix_film, the path pix_flip>pix_mix is working well
You can see the exemple patch next
the last problem is that, if I put a rate < 1 (in the |pd lecteur_video_boucle|)
the hysteric flip is recoming
but it's now very better!!!!