This is a bug with Nvidia's drivers which do not handle YUV textures properly. You can sned pix_film a 'colorspace rgb' message, but this will drastically reduce performance. If you want to get an ATI card like an 8500 or better, then that will solve the problem quite well. You can also go back to a version of OSX before 10.2.6 and that might work, but it's been quite some time since I've tried that.
Also, I think you are mistaken about pix_movie not doing this - it's the exact same code as pix_film + pix_texture just wrapped in a single object. Maybe the default is set to RGB colorspace - I don't recall off hand. This is also the first I've heard of starting and stopping rendering 'fixing' the problem. This issue has been confirmed by many other developers including the VLC people, and an official bug is on file with Apple (Nividia have no real OSX developer support at all).
cgc
Quoting Etienne Desautels titi@sat.qc.ca:
Hi,
I'm actually developing some patches on PD 0.37 with Gem 0.9 on os X, but I find a bug with the [pix_film] object. I'm using the binary for the G4 of Gem 0.9 and it works perfectly on my laptop (PB 667 with ATI Radeon M6 16Mb ram agp) but I have a problem on a dual 1GHz with a GeForce4 Mx 64Mb agp. When I load a DV file with the [pix_film] object, the video appears like it was duplicate one time horizontally but put in the same space and all the colors are wrong (purple and dark). If I stop and then start again the rendering of the gemwin, the video will become normal but I'll have to do that every time I'm loading a DV file. This problem doesn't exist with the [pix_movie] of 0.9 or in the 0.87 version.
Do you have any ideas ?
Thanks
Etienne
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
chris clepper wrote:
This is a bug with Nvidia's drivers which do not handle YUV textures properly. You can sned pix_film a 'colorspace rgb' message, but this will drastically reduce performance. If you want to get an ATI card like an 8500 or better, then that will solve the problem quite well. You can also go back to a version of OSX before 10.2.6 and that might work, but it's been quite some time since I've tried that.
you could also try sending a message "yuv 0" to the [pix_texture] object before(!) anything else (at least, before the first image arrives at the texture-object). this should turn convert and texture any yuv-image as RGB.
mfg.as.dr IOhannes
Hello,
There is something i dont understand in the gem framebuffer handling. It seems that the frame is cleared, projection reinitialised for each frame. Is that normal ? I personnally want to use precedent images and viewing transformations, is there a way to avoid that ? I've tried to look inside the code but i dont see any glClear commend that could explain that.
I'd also like to code some externals, but i cant figure out the overall gem structure. Is there somewhere a description of the internal structure of Gem ?
this question may be the consequence of my gem ignorance but: why can i find a render object (id like to do multipass rendering, usefull to set render to texture features)
Thanx for the Help Ronan
You will find the clearing and buffer swapping code in GemMan :: swapBuffers(). To keep the contents of the window from clearing try sending a 'buffer 1' message to the gemwin.
I don't really know what you mean by a 'render object', but GemMan sets up most of the render states and then clears them while individual objects send GL drawing commands in immediate mode. It's really fairly primitive (pardon the pun) right now, but that might change at some point.
cgc
On Jul 9, 2004, at 10:19 AM, Ronan Puce Muse wrote:
Hello,
There is something i dont understand in the gem framebuffer handling. It seems that the frame is cleared, projection reinitialised for each frame. Is that normal ? I personnally want to use precedent images and viewing transformations, is there a way to avoid that ? I've tried to look inside the code but i dont see any glClear commend that could explain that.
I'd also like to code some externals, but i cant figure out the overall gem structure. Is there somewhere a description of the internal structure of Gem ?
this question may be the consequence of my gem ignorance but: why can i find a render object (id like to do multipass rendering, usefull to set render to texture features)
Thanx for the Help Ronan
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
Oki thanx a lot for the answer chris.
buffer 1 works well. In fact i did not know how to use it and did not know that gemhead had to be banged to launch single buffer mode display. As it seems automatic in double buffer mode. By the way, i've done some things with a lot of vertexes (about 4000) displayed in point mode. Im glad it works quite well but something embrassing: the fact that it is using single buffer makes it flicker.
I've compiled a version of the gem dll without the line 1290 (should be) //glClear(m_clear_mask);
I dont see why there should be such an initialisation because we have a quite complete wrapper for opengl. But i can understand why it stands here. Why not setting a particular message to gemwindow that could disable ALL initialisations (buffers, projections, model views, etc...) for a correct use of the wrapper.
If no one does yet, i could do some help files for the wrapper use (i didnt find any)
i'd like to add some extensions functionalities like texture rendering using pixel buffers, i believe that considering that like extensions of the Opengl wrapper, that could be easy ?
i hope that my remarks will be usefull Ronan
----- Original Message ----- From: "chris clepper" cgc@humboldtblvd.com To: "Ronan Puce Muse" r.leboite.pm@birdsinplane.com Cc: "Pd List" pd-list@iem.at; gem-dev@iem.at Sent: Friday, July 09, 2004 7:08 PM Subject: Re: [GEM-dev] Some newbie questions (sorry)
You will find the clearing and buffer swapping code in GemMan :: swapBuffers(). To keep the contents of the window from clearing try sending a 'buffer 1' message to the gemwin.
I don't really know what you mean by a 'render object', but GemMan sets up most of the render states and then clears them while individual objects send GL drawing commands in immediate mode. It's really fairly primitive (pardon the pun) right now, but that might change at some point.
cgc
On Jul 9, 2004, at 10:19 AM, Ronan Puce Muse wrote:
Hello,
There is something i dont understand in the gem framebuffer handling. It seems that the frame is cleared, projection reinitialised for each frame. Is that normal ? I personnally want to use precedent images and viewing transformations, is there a way to avoid that ? I've tried to look inside the code but i dont see any glClear commend that could explain that.
I'd also like to code some externals, but i cant figure out the overall gem structure. Is there somewhere a description of the internal structure of Gem ?
this question may be the consequence of my gem ignorance but: why can i find a render object (id like to do multipass rendering, usefull to set render to texture features)
Thanx for the Help Ronan
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
On 04-07-08, at 18:18, chris clepper wrote:
This is a bug with Nvidia's drivers which do not handle YUV textures properly. You can sned pix_film a 'colorspace rgb' message, but this will drastically reduce performance. If you want to get an ATI card like an 8500 or better, then that will solve the problem quite well. You can also go back to a version of OSX before 10.2.6 and that might work, but it's been quite some time since I've tried that.
I tried with the colorspace rgb and it solve the problem but, as you said, it double the cpu usage. What do you think about using the nvidia extension of the 10.2.6 in 10.3.4?
Also, I think you are mistaken about pix_movie not doing this - it's the exact same code as pix_film + pix_texture just wrapped in a single object. Maybe the default is set to RGB colorspace - I don't recall off hand.
I did some new tests and I never have the problem with pix_movie and if I look at the cpu usage, it's about the same that when I play the same DV file with pix_film in YUV. So it gives me the feel that it was playing in YUV, but I was not able to send some colorspace message to pix_movie (err = no colorspace method()).
Also, I would like to know why is it working with Gem 0.87 and not 0.9 if it's a bug with Nvidia's drivers ?
This is also the first I've heard of starting and stopping rendering 'fixing' the problem. This issue has been confirmed by many other developers including the VLC people, and an official bug is on file with Apple (Nividia have no real OSX developer support at all).
I can replicate this behaviour anytime and if I look at the cpu usage before and after to stop/start the rendering is about the same, so it look like the file is still playing in YUV after.
On 04-07-09, at 02:36, IOhannes m zmoelnig wrote:
you could also try sending a message "yuv 0" to the [pix_texture] object before(!) anything else (at least, before the first image arrives at the texture-object). this should turn convert and texture any yuv-image as RGB.
I tried this also but it didn't worked ?
Thank you all for your support !
Etienne
mfg.as.dr IOhannes
Quoting Etienne Desautels titi@sat.qc.ca:
Hi,
I'm actually developing some patches on PD 0.37 with Gem 0.9 on os X, but I find a bug with the [pix_film] object. I'm using the binary for the G4 of Gem 0.9 and it works perfectly on my laptop (PB 667 with ATI Radeon M6 16Mb ram agp) but I have a problem on a dual 1GHz with a GeForce4 Mx 64Mb agp. When I load a DV file with the [pix_film] object, the video appears like it was duplicate one time horizontally but put in the same space and all the colors are wrong (purple and dark). If I stop and then start again the rendering of the gemwin, the video will become normal but I'll have to do that every time I'm loading a DV file. This problem doesn't exist with the [pix_movie] of 0.9 or in the 0.87 version.
Do you have any ideas ?
Thanks
Etienne
This message was sent using IMP, the Internet Messaging Program.
-
chris clepper -
Etienne Desautels -
IOhannes m zmoelnig -
Ronan Puce Muse