GEM-dev

gem-dev@lists.iem.at

2417 discussions

ImageMagick Compiling Error w/ Gem
by m.e.grimm 21 Mar '12

21 Mar '12

Hello, Trying to compile most recent Gem git I get: libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../src -I../../src -DPD -I/Applications/Pd-extended.app/Contents/Resources/include/pd -I/sw/include/ImageMagick -g -O2 -freg-struct-return -Os -falign-loops -falign-functions -falign-jumps -funroll-loops -ffast-math -mmmx -fpascal-strings -MT gem_imageMAGICK_la-imageMAGICK.lo -MD -MP -MF .deps/gem_imageMAGICK_la-imageMAGICK.Tpo -c imageMAGICK.cpp -fno-common -DPIC -o .libs/gem_imageMAGICK_la-imageMAGICK.o In file included from /sw/include/ImageMagick/magick/MagickCore.h:148, from imageMAGICK.cpp:27: /sw/include/ImageMagick/magick/magick-type.h:179: error: conflicting declaration 'typedef struct _ExceptionInfo ExceptionInfo' /System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/MachineExceptions.h:196: error: 'ExceptionInfo' has a previous declaration as 'typedef union ExceptionInfo ExceptionInfo' make[2]: *** [gem_imageMAGICK_la-imageMAGICK.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive] Error 1 pd-extended 0.43 osx 10.7.3 ive been compiling with --without-imagemagick but just tried again and was currious about the error. Thanks! m -- ____________________ m.e.grimm | m.f.a | ed.m. megrimm(a)gmail.com _________________________________

2 7

[ pd-gem-Bugs-3508738 ] gem_filmGMERLIN video stream 0 crash
by SourceForge.net 19 Mar '12

19 Mar '12

Bugs item #3508738, was opened at 2012-03-19 07:58 Message generated for change (Tracker Item Submitted) made by megrimm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3508738&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: osx Status: Open Resolution: None Priority: 5 Private: No Submitted By: megrimm (megrimm) Assigned to: Nobody/Anonymous (nobody) Summary: gem_filmGMERLIN video stream 0 crash Initial Comment: Gem should not try to access the video stream 0 Gem crashes using gem_filmGMERLIN Plugin when opening alea.mpg when gmerlin is not compiled with libmpeg2 support. pd-extended 0.43 most recent Gem git osx 10.7.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3508738&group_…

1 0

Problem to draw line with curve3d and surface3d
by Jack 19 Mar '12

19 Mar '12

Hello, It seems that it is not possible anymore to draw line of this two objects. I need to draw a curve3d with something like [curve3d 3 1]. My config : Ubuntu 11.10 Pd-0.43-2test1 Gem 0.93.3 ++ Jack PS : An object without surface (but only a line) with the same behavior than [curve3d] would be nice. ;)

2 3

[ 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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

GEM-dev