GEM-dev June 2011

gem-dev@lists.iem.at

11 participants
54 discussions

pix_gst2pix doesn't work ?
by Antoine Villeret 01 Jun '11

01 Jun '11

hi, I can't get pix_gst2pix to work on my machine (Ubuntu 10.04). I tried the test patch gst2pix.pd but the texture stays blank... I've put some post() in the code to try to track from where the bug comes now I just know that all functions are well called but pix_info sends only -1 on all outlets when I put it between pix_gst2pix and pix_texture even the 6th and 7th outlet are sending -1 whereas they used to send list... and nothing is sent throught the 8th outlet does anyone have any idea to fix this ? thanks antoine -- do it yourself http://antoine.villeret.free.fr http://drii.ensad.fr -- Google lit ce mail... si vous refusez cela, utilisez l'adresse antoine.villeret [at] free.fr pour me contacter

2 2

Re: [GEM-dev] [ pd-gem-Bugs-3309231 ] RGB32 frambuffer can't be initialised with a loadbang
by cyrille henry 01 Jun '11

01 Jun '11

thanks Iohannes for the quick fix. c Le 01/06/2011 18:06, SourceForge.net a écrit : > Bugs item #3309231, was opened at 2011-05-30 11:07 > Message generated for change (Comment added) made by zmoelnig > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3309231&group_… > > Please note that this message will contain a full copy of the comment thread, > including the initial issue submission, for this request, > not just the latest update. > Category: None > Group: None >> Status: Pending >> Resolution: Fixed > Priority: 5 > Private: No > Submitted By: Cyrille Henry (nusmuk) > Assigned to: Nobody/Anonymous (nobody) > Summary: RGB32 frambuffer can't be initialised with a loadbang > > Initial Comment: > When sending "format RGB32" to gemframebuffer, a valid context have to be present. Otherwise, default RGB format is used. > > This was not the case prior to revision 3807. > > here is the relevant part of the diff (gemframbuffer.cpp) > > 398c398,400 > < tmp_format = GL_RGB_FLOAT32_ATI; > --- >> if(GLEW_ATI_texture_float) { >> tmp_format = GL_RGB_FLOAT32_ATI; >> } > > > Since a loadbang is usually used to set the framebuffer format, this behaviors break all my patch that need 32bit framebuffer (including the GPGPU example) > > test patch in attachment. > > ---------------------------------------------------------------------- > >> Comment By: IOhannes m zmlnig (zmoelnig) > Date: 2011-06-01 18:06 > > Message: > thanks. > > this should be fixed with rev.3957 > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3309231&group_… > > _______________________________________________ > GEM-dev mailing list > GEM-dev(a)iem.at > http://lists.puredata.info/listinfo/gem-dev >

1 0

[ pd-gem-Bugs-3309231 ] RGB32 frambuffer can't be initialised with a loadbang
by SourceForge.net 01 Jun '11

01 Jun '11

Bugs item #3309231, was opened at 2011-05-30 11:07 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3309231&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending >Resolution: Fixed Priority: 5 Private: No Submitted By: Cyrille Henry (nusmuk) Assigned to: Nobody/Anonymous (nobody) Summary: RGB32 frambuffer can't be initialised with a loadbang Initial Comment: When sending "format RGB32" to gemframebuffer, a valid context have to be present. Otherwise, default RGB format is used. This was not the case prior to revision 3807. here is the relevant part of the diff (gemframbuffer.cpp) 398c398,400 < tmp_format = GL_RGB_FLOAT32_ATI; --- > if(GLEW_ATI_texture_float) { > tmp_format = GL_RGB_FLOAT32_ATI; > } Since a loadbang is usually used to set the framebuffer format, this behaviors break all my patch that need 32bit framebuffer (including the GPGPU example) test patch in attachment. ---------------------------------------------------------------------- >Comment By: IOhannes m zmlnig (zmoelnig) Date: 2011-06-01 18:06 Message: thanks. this should be fixed with rev.3957 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3309231&group_…

1 0

[ pd-gem-Bugs-3309225 ] rectangle message to pix_texture brocken in some condition
by SourceForge.net 01 Jun '11

01 Jun '11

Bugs item #3309225, was opened at 2011-05-30 10:50 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3309225&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Pixes (pix_ objects) Group: None >Status: Pending >Resolution: Fixed Priority: 5 Private: No Submitted By: Cyrille Henry (nusmuk) Assigned to: Nobody/Anonymous (nobody) Summary: rectangle message to pix_texture brocken in some condition Initial Comment: In some specific condition, the rectangle message to pix_texture become useless. One have to use shader in order to noticed this effect since texturing usually work in both mode. Conditions that make the rectangle message to be brocken are mainly caused when pix_texture did not receive the gem_state 1 message. So, if you initialize rectangle mode with a loadbang, and if you inhibit the gemhead during the windows creation, then pix_texture will never be able to switch to rectangle texture. same problem when creating a patch : if you create pix_texture, and send it "rectangle 1" before connecting it on a gemhead, then it will never switch to rectangular texture. here is a simple test patch. ---------------------------------------------------------------------- >Comment By: IOhannes m zmlnig (zmoelnig) Date: 2011-06-01 16:38 Message: thanks for the bug-report. this issue should be fixed with rev.3955 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3309225&group_…

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

GEM-dev June 2011