GEM-dev March 2012

gem-dev@lists.iem.at

9 participants
40 discussions

[ pd-gem-Bugs-3508581 ] draw message did not work with curve3d and surface3d
by SourceForge.net 19 Mar '12

19 Mar '12

Bugs item #3508581, was opened at 2012-03-19 04:10 Message generated for change (Tracker Item Submitted) made by nusmuk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3508581&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: Open Resolution: None Priority: 5 Private: No Submitted By: Cyrille Henry (nusmuk) Assigned to: Nobody/Anonymous (nobody) Summary: draw message did not work with curve3d and surface3d Initial Comment: the draw message did not change the drawing style of the primitive. see help file for this 2 objects. tested on linux / last Git ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3508581&group_…

1 0

[ pd-gem-Bugs-3508508 ] graphicsmagick compat isn't
by SourceForge.net 19 Mar '12

19 Mar '12

Bugs item #3508508, was opened at 2012-03-19 02:48 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3508508&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: build-system Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: graphicsmagick compat isn't Initial Comment: Version: Gem fresh from Git earlier today. Actual behaviour: Debian Testing with 'graphicsmagick-libmagick-dev-compat' fails to 'make' after successful './configure'. Expected behaviour: either './configure' to fail, or both './configure and 'make' to succeed (possibly with reduced functionality at runtime). Workaround: install 'libmagickcore-dev' which removes the problematic alternative magick ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3508508&group_…

1 0

Re: [GEM-dev] [PD] alternative for quicktime
by Patrice Colet 18 Mar '12

18 Mar '12

> De: "IOhannes m zmölnig" <zmoelnig(a)iem.at> > À: pd-list(a)iem.at > Envoyé: Dimanche 18 Mars 2012 12:48:15 > Objet: Re: [PD] alternative for quicktime > > On 03/18/12 00:31, Patrice Colet wrote: > > gmerlin is detected but I couldn't make it because of this: > > > > 'glutMainLoopEvent' was not declared in this scope > > do something like > $ make -k > to get over non-neccessary build steps Ok, in fact the linker couldn't use the gmerlin_avdecoder lib I've made because it's compiled statically, the build system couldn't make a dll, I'm trying to look further with svn sources, because I've used the archive... During compilation of pixes objects, all sources from pix_film.cpp to pix_zoom.cpp are ignored, whatever the configure option I use, even after a make clean. PS: I've tried different objects, the draw mode doesn't work on [curve3d] with my gem.dll > (Gem seems to find a non-freeglut installation of glut and fails to > build the [gemglutwindow] objectclass, which should be of no concern > to you) > > > > > ... > > > > ./configure --without-all > > > > don't (if you don't want nothing :-)) > > > compiles gem.dll but couldn't create some other library files > > > > /filmAVI.cpp:230: undefined reference to `AVIStreamRead@28' > > > > ah well, you disabled checks for libvfw by sepcifying (--without-all) > and configure is not so clever as to remove filmAVI in this case yet > (when building on w32) > > fgmasdr > IOhannes > > _______________________________________________ > Pd-list(a)iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list >

2 1

[ pd-gem-Bugs-3281206 ] thin white primitive borders are shown despite texture
by SourceForge.net 17 Mar '12

17 Mar '12

Bugs item #3281206, was opened at 2011-04-08 14:07 Message generated for change (Comment added) made by sistisette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3281206&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: rendering (e.g. display) Group: any operating system Status: Closed Resolution: None Priority: 7 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: thin white primitive borders are shown despite texture Initial Comment: Sometimes, depending on their size and/or position, rectangles (and I guess other polygons too but I mainly work with rectangles) are shown with a thin white border even if they are textured with a pix that has no white pixel in the proximity of the border, e.g. a completely black image or an image whose pixels close to the border are all black or transparent. This has been there for years, I've always seen this happen since I use gem, across many versions. This happens both with Linux and Windows, i don't know on Mac OS. If a rectangle is moving or changing size, the borders appear and disappear. Most of the time they are absent, I mean the values of position and size that cause the borders to appear are just a small fraction of the total. ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2012-03-17 06:38 Message: oh shit, again, it was me ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2012-03-17 06:37 Message: I've tried sending the message "quality 1" and "repeat 1" and they don't make ANY difference. With some images used as texture I even get a thin row of apparently random-coloured pixels on the edges!!!! This is particularly evident with small images used as textures (i.e. when the pixels get big). I'm testing with 0.92.3, tough ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-08-16 13:41 Message: as for [gemframebuffer], i really don't know why CLAMP is used rather than CLAMP_TO_EDGE; it was most likely forgotten... but apart from that, CLAMP_TO_EDGE is already used (and that's at least since 0.91) ---------------------------------------------------------------------- Comment By: Cyrille Henry (nusmuk) Date: 2011-08-16 12:25 Message: hello, yes, GL_CLAMP_TO_EDGE is better than GL_CLAMP. The grep does not say a lot about the code. if you have a look in pix_texture.cpp : if (type) m_repeat = GL_REPEAT; else { if(GLEW_EXT_texture_edge_clamp) m_repeat = GL_CLAMP_TO_EDGE; else m_repeat = GL_CLAMP; } when repeat mode = 0, then m_repeat is GL_CLAMP_TO_EDGE if possible, or GL_CLAMP if not. it's the same about pix_imageInPlace and pix_cubemap. it's not the same for framebuffer, but there certainly is a good reason for this. c ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-08-16 10:15 Message: Guessing at the cause here, but I'm led to believe GL_CLAMP is mostly wrong, and GL_CLAMP_TO_EDGE is to be preferred almost always... http://www.opengl.org/wiki/Common_Mistakes#Texture_edge_color_problem claude@zebimus:~/code/pd-gem$ grep -Rwn "GL_CLAMP" . | grep -v \\.svn ./Gem/ChangeLog:4473: "GL_CLAMP" when doing rectangle-textures, as they will ignore ./Gem/src/Pixes/pix_imageInPlace.cpp:216: m_repeat = GL_CLAMP; ./Gem/src/Pixes/pix_cubemap.cpp:365: m_repeat = GL_CLAMP; ./Gem/src/Pixes/pix_texture.cpp:118: // NPOT: GL_CLAMP, GL_CLAMP_TO_EDGE, GL_CLAMP_TO_BORDER ./Gem/src/Pixes/pix_texture.cpp:690: m_repeat = GL_CLAMP; ./Gem/src/Gem/glew.h:698:#define GL_CLAMP 0x2900 ./Gem/src/Controls/gemframebuffer.cpp:284: glTexParameterf(m_texTarget, GL_TEXTURE_WRAP_S, GL_CLAMP); ./Gem/src/Controls/gemframebuffer.cpp:285: glTexParameterf(m_texTarget, GL_TEXTURE_WRAP_T, GL_CLAMP); ./Gem/src/Utils/GLUtil_generated.h:86: if (!strcmp(name, "GL_CLAMP")) return GL_CLAMP; ./GemLibs/FTGL/test/FTTextureGlyph-Test.cpp:42: glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP); ./GemLibs/FTGL/test/FTTextureGlyph-Test.cpp:43: glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP); ./GemLibs/FTGL/test/FTTextureGlyph-Test.cpp:69: glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP); ./GemLibs/FTGL/test/FTTextureGlyph-Test.cpp:70: glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP); ./GemLibs/FTGL/src/FTGLTextureFont.cpp:128: glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP); ./GemLibs/FTGL/src/FTGLTextureFont.cpp:129: glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP); ./GemLibs/FTGL/include/FTGLTextureFont.h:85: * GL_TEXTURE_WRAP_S = GL_CLAMP ./GemLibs/FTGL/include/FTGLTextureFont.h:86: * GL_TEXTURE_WRAP_T = GL_CLAMP Incidentally, could these better be ...i instead of ...f function calls? claude@zebimus:~/code/pd-gem$ grep -Rn "glTexParameterf" . | grep -v \\.svn | grep -v GL_TEXTURE_PRIORITY | grep -v src/openGL | grep -v glew\.h | grep -v build/ | grep -v GEM ./Gem/src/Pixes/pix_imageInPlace.cpp:156: glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_imageInPlace.cpp:157: glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_cubemap.cpp:112: glTexParameterf(m_textureType, GL_TEXTURE_MIN_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_cubemap.cpp:113: glTexParameterf(m_textureType, GL_TEXTURE_MAG_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_cubemap.cpp:114: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_cubemap.cpp:115: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_cubemap.cpp:347: glTexParameterf(m_textureType, GL_TEXTURE_MAG_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_cubemap.cpp:348: glTexParameterf(m_textureType, GL_TEXTURE_MIN_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_cubemap.cpp:371: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_cubemap.cpp:372: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_snap2tex.cpp:90: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_snap2tex.cpp:91: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_snap2tex.cpp:365: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_snap2tex.cpp:366: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_texture.cpp:137: glTexParameterf(m_textureType, GL_TEXTURE_MIN_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_texture.cpp:138: glTexParameterf(m_textureType, GL_TEXTURE_MAG_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_texture.cpp:139: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_texture.cpp:140: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_texture.cpp:270: glTexParameterf(m_textureType, GL_TEXTURE_MAG_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_texture.cpp:271: glTexParameterf(m_textureType, GL_TEXTURE_MIN_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_texture.cpp:657: glTexParameterf(m_textureType, GL_TEXTURE_MAG_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_texture.cpp:658: glTexParameterf(m_textureType, GL_TEXTURE_MIN_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_texture.cpp:696: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_texture.cpp:697: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_movieOS.cpp:271: glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT); ./Gem/src/Pixes/pix_movieOS.cpp:272: glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT); ./Gem/src/Controls/gemframebuffer.cpp:284: glTexParameterf(m_texTarget, GL_TEXTURE_WRAP_S, GL_CLAMP); ./Gem/src/Controls/gemframebuffer.cpp:285: glTexParameterf(m_texTarget, GL_TEXTURE_WRAP_T, GL_CLAMP); ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-08-16 09:33 Message: it's hardware/driver specific as the openGL standard doesn't specify exactly how it ought to be done (afair); i mainly follow cyrille's arguing here. the workaround is to e.g. set "repeat" mode and/or the "quality" mode of texture. you can apply a global defaul by adding lines for "texture.quality" and "texture.repeat" to your gem.conf; something like: <gem.conf> texture.quality 0 </gem.conf> ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2011-08-16 09:27 Message: Sorry it was me asking the last question (damn the fake "remember me" checkbox, I reported that but the admins like the way it is) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-08-16 09:24 Message: What hardware/driver is this specific to? What's the workaround in gem.conf? ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-08-16 09:01 Message: given that the problem is hardware/driver specific, there is a workaround _and_ the workaround can be done globally using gem.conf (in >=0.93), i think this can be closed. ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2011-04-23 08:39 Message: Does the hardware really interpolate textures the wrong way? Are we sure Gem is asking the hardware the right thing? If "repeat" is the fix, i suspect it may mask the issue (i.e. make it less evident in some but not all situations) rather than fix it, but I haven't tried it actually. ---------------------------------------------------------------------- Comment By: Cyrille Henry (nusmuk) Date: 2011-04-08 15:35 Message: This is not a gem problem. it's the way the hardware interpolate a texture. i don't remember the exact configuration, but changing the default value of "quality" and/or "repeat" of pix_texture change can fix this problem. since it's not gem fault, and gem offer a solution, i think this can be closed. ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2011-04-08 14:10 Message: I hope it is ok to rise the priority. Though this is an old bug, it is a real showstopper in a range of situations. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3281206&group_…

1 0

[ pd-gem-Bugs-3281206 ] thin white primitive borders are shown despite texture
by SourceForge.net 17 Mar '12

17 Mar '12

Bugs item #3281206, was opened at 2011-04-08 14:07 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3281206&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: rendering (e.g. display) Group: any operating system Status: Closed Resolution: None Priority: 7 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: thin white primitive borders are shown despite texture Initial Comment: Sometimes, depending on their size and/or position, rectangles (and I guess other polygons too but I mainly work with rectangles) are shown with a thin white border even if they are textured with a pix that has no white pixel in the proximity of the border, e.g. a completely black image or an image whose pixels close to the border are all black or transparent. This has been there for years, I've always seen this happen since I use gem, across many versions. This happens both with Linux and Windows, i don't know on Mac OS. If a rectangle is moving or changing size, the borders appear and disappear. Most of the time they are absent, I mean the values of position and size that cause the borders to appear are just a small fraction of the total. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2012-03-17 06:37 Message: I've tried sending the message "quality 1" and "repeat 1" and they don't make ANY difference. With some images used as texture I even get a thin row of apparently random-coloured pixels on the edges!!!! This is particularly evident with small images used as textures (i.e. when the pixels get big). I'm testing with 0.92.3, tough ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-08-16 13:41 Message: as for [gemframebuffer], i really don't know why CLAMP is used rather than CLAMP_TO_EDGE; it was most likely forgotten... but apart from that, CLAMP_TO_EDGE is already used (and that's at least since 0.91) ---------------------------------------------------------------------- Comment By: Cyrille Henry (nusmuk) Date: 2011-08-16 12:25 Message: hello, yes, GL_CLAMP_TO_EDGE is better than GL_CLAMP. The grep does not say a lot about the code. if you have a look in pix_texture.cpp : if (type) m_repeat = GL_REPEAT; else { if(GLEW_EXT_texture_edge_clamp) m_repeat = GL_CLAMP_TO_EDGE; else m_repeat = GL_CLAMP; } when repeat mode = 0, then m_repeat is GL_CLAMP_TO_EDGE if possible, or GL_CLAMP if not. it's the same about pix_imageInPlace and pix_cubemap. it's not the same for framebuffer, but there certainly is a good reason for this. c ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-08-16 10:15 Message: Guessing at the cause here, but I'm led to believe GL_CLAMP is mostly wrong, and GL_CLAMP_TO_EDGE is to be preferred almost always... http://www.opengl.org/wiki/Common_Mistakes#Texture_edge_color_problem claude@zebimus:~/code/pd-gem$ grep -Rwn "GL_CLAMP" . | grep -v \\.svn ./Gem/ChangeLog:4473: "GL_CLAMP" when doing rectangle-textures, as they will ignore ./Gem/src/Pixes/pix_imageInPlace.cpp:216: m_repeat = GL_CLAMP; ./Gem/src/Pixes/pix_cubemap.cpp:365: m_repeat = GL_CLAMP; ./Gem/src/Pixes/pix_texture.cpp:118: // NPOT: GL_CLAMP, GL_CLAMP_TO_EDGE, GL_CLAMP_TO_BORDER ./Gem/src/Pixes/pix_texture.cpp:690: m_repeat = GL_CLAMP; ./Gem/src/Gem/glew.h:698:#define GL_CLAMP 0x2900 ./Gem/src/Controls/gemframebuffer.cpp:284: glTexParameterf(m_texTarget, GL_TEXTURE_WRAP_S, GL_CLAMP); ./Gem/src/Controls/gemframebuffer.cpp:285: glTexParameterf(m_texTarget, GL_TEXTURE_WRAP_T, GL_CLAMP); ./Gem/src/Utils/GLUtil_generated.h:86: if (!strcmp(name, "GL_CLAMP")) return GL_CLAMP; ./GemLibs/FTGL/test/FTTextureGlyph-Test.cpp:42: glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP); ./GemLibs/FTGL/test/FTTextureGlyph-Test.cpp:43: glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP); ./GemLibs/FTGL/test/FTTextureGlyph-Test.cpp:69: glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP); ./GemLibs/FTGL/test/FTTextureGlyph-Test.cpp:70: glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP); ./GemLibs/FTGL/src/FTGLTextureFont.cpp:128: glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP); ./GemLibs/FTGL/src/FTGLTextureFont.cpp:129: glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP); ./GemLibs/FTGL/include/FTGLTextureFont.h:85: * GL_TEXTURE_WRAP_S = GL_CLAMP ./GemLibs/FTGL/include/FTGLTextureFont.h:86: * GL_TEXTURE_WRAP_T = GL_CLAMP Incidentally, could these better be ...i instead of ...f function calls? claude@zebimus:~/code/pd-gem$ grep -Rn "glTexParameterf" . | grep -v \\.svn | grep -v GL_TEXTURE_PRIORITY | grep -v src/openGL | grep -v glew\.h | grep -v build/ | grep -v GEM ./Gem/src/Pixes/pix_imageInPlace.cpp:156: glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_imageInPlace.cpp:157: glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_cubemap.cpp:112: glTexParameterf(m_textureType, GL_TEXTURE_MIN_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_cubemap.cpp:113: glTexParameterf(m_textureType, GL_TEXTURE_MAG_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_cubemap.cpp:114: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_cubemap.cpp:115: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_cubemap.cpp:347: glTexParameterf(m_textureType, GL_TEXTURE_MAG_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_cubemap.cpp:348: glTexParameterf(m_textureType, GL_TEXTURE_MIN_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_cubemap.cpp:371: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_cubemap.cpp:372: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_snap2tex.cpp:90: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_snap2tex.cpp:91: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_snap2tex.cpp:365: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_snap2tex.cpp:366: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_texture.cpp:137: glTexParameterf(m_textureType, GL_TEXTURE_MIN_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_texture.cpp:138: glTexParameterf(m_textureType, GL_TEXTURE_MAG_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_texture.cpp:139: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_texture.cpp:140: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_texture.cpp:270: glTexParameterf(m_textureType, GL_TEXTURE_MAG_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_texture.cpp:271: glTexParameterf(m_textureType, GL_TEXTURE_MIN_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_texture.cpp:657: glTexParameterf(m_textureType, GL_TEXTURE_MAG_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_texture.cpp:658: glTexParameterf(m_textureType, GL_TEXTURE_MIN_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_texture.cpp:696: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_texture.cpp:697: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_movieOS.cpp:271: glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT); ./Gem/src/Pixes/pix_movieOS.cpp:272: glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT); ./Gem/src/Controls/gemframebuffer.cpp:284: glTexParameterf(m_texTarget, GL_TEXTURE_WRAP_S, GL_CLAMP); ./Gem/src/Controls/gemframebuffer.cpp:285: glTexParameterf(m_texTarget, GL_TEXTURE_WRAP_T, GL_CLAMP); ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-08-16 09:33 Message: it's hardware/driver specific as the openGL standard doesn't specify exactly how it ought to be done (afair); i mainly follow cyrille's arguing here. the workaround is to e.g. set "repeat" mode and/or the "quality" mode of texture. you can apply a global defaul by adding lines for "texture.quality" and "texture.repeat" to your gem.conf; something like: <gem.conf> texture.quality 0 </gem.conf> ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2011-08-16 09:27 Message: Sorry it was me asking the last question (damn the fake "remember me" checkbox, I reported that but the admins like the way it is) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-08-16 09:24 Message: What hardware/driver is this specific to? What's the workaround in gem.conf? ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-08-16 09:01 Message: given that the problem is hardware/driver specific, there is a workaround _and_ the workaround can be done globally using gem.conf (in >=0.93), i think this can be closed. ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2011-04-23 08:39 Message: Does the hardware really interpolate textures the wrong way? Are we sure Gem is asking the hardware the right thing? If "repeat" is the fix, i suspect it may mask the issue (i.e. make it less evident in some but not all situations) rather than fix it, but I haven't tried it actually. ---------------------------------------------------------------------- Comment By: Cyrille Henry (nusmuk) Date: 2011-04-08 15:35 Message: This is not a gem problem. it's the way the hardware interpolate a texture. i don't remember the exact configuration, but changing the default value of "quality" and/or "repeat" of pix_texture change can fix this problem. since it's not gem fault, and gem offer a solution, i think this can be closed. ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2011-04-08 14:10 Message: I hope it is ok to rise the priority. Though this is an old bug, it is a real showstopper in a range of situations. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3281206&group_…

1 0

pix_rom + plugins, etc
by m.e.grimm 16 Mar '12

16 Mar '12

IOhannes, all, I started (a couple years ago) looking into porting or coding something similar to Kyle Buza's jit.atari2600 (http://mmonoplayer.com/jit2600.php) but got sidetracked with life.... Looking at and messing around with the new Gem plugin system got me thinking this morning and wondering if this could also be used for an objects such as "pix_rom" where the plugins/backends could be emulators (nintendo, intellivision, etc) such as gem_romATARI, gem_romNINTENDO, etc.... I have been self-learning more and more C over the past few months but still my skills are pretty poor (still a hack)... anyway, I am wondering if there is a good place to start a "pix_rom" object? Maybe begin with "pix_model"? I know the documentation is pretty thin on recent Gem stuff right now... understandably. I am also looking for help and support if anyone is interested. I also view this as something long term and am in no rush... cheers m

2 1

[ pd-gem-Bugs-3500407 ] Ohwvat Really appreciate you sharing this blog post.Much tha
by SourceForge.net 09 Mar '12

09 Mar '12

Bugs item #3500407, was opened at 2012-03-09 04:27 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3500407&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: build-system Group: linux Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Ohwvat Really appreciate you sharing this blog post.Much tha Initial Comment: Ohwvat Really appreciate you sharing this blog post.Much thanks again. Want more. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3500407&group_…

1 0

gemcocoawindow
by m.e.grimm 06 Mar '12

06 Mar '12

so.... gemcocoawindow works on 64 bit pd-extended on 10.7 (creates gem window) is there reason its not in the autobuild? m

2 1

Problem with texcoord and gemvertexbuffer
by Jack 04 Mar '12

04 Mar '12

Thanx to look at the patch attached and its abstraction. All comments are inside. Where is my mistake with the size of the texture on each face of the cube ? ++ Jack

2 2

pix_equal (was Re: new pix_colordetect)
by Ricardo Fabbri 03 Mar '12

03 Mar '12

Hi, following up on the color classification thread, I had promised a pix_equal object to mark the pixels that are equal to a given RGBA value/range. It is quite useful in the present form; perhaps another solution could be sought for the long term, but for now this does a useful job, in particular being required to decode the output of pix_colorclassify. pix_bitmask doesn't work for this, as what I need is an "and" interval test on all RGBA channels. The code for pix_equal and its documentation is are in the 'pix_equal_new' branch at this repo: git://github.com/rfabbri/Gem.git I rebased the branch on the latest Gem git master branch. I look forward to your feedback on this simple object, and your opinion about incorporating it into Gem. Ricardo Fabbri -- Linux registered user #175401 www.lems.brown.edu/~rfabbri pt.wikipedia.org/wiki/IPRJ labmacambira.sf.net 2011/11/14 IOhannes zmölnig <zmoelnig(a)iem.at>: > On 11/14/2011 06:30 PM, Ricardo Fabbri wrote: >> That will come with a later contribution. I wrote a [pix_equal] >> external which can change any pixels "equal" to some value within a >> given cosed r & g & b range. I use it to separate the colors into >> different images, change the color label, etc. > > > actually, i think what we really would need was a (high-performant, > jit-compiled) [pix_expr] object, that would allow to create such objects > in Pd space rather than in C++ space. > > fgmasdr > IOhannes > > > _______________________________________________ > GEM-dev mailing list > GEM-dev(a)iem.at > http://lists.puredata.info/listinfo/gem-dev >

2 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

GEM-dev March 2012