hi all
while i am at tweaking gem a bit, the next question: is it easily feasible to change the code of [pix_texture] so, that it has 'mode 0', when instantiating such an object. having to put a 'mode 0', whenever i load a help-patch is quite a pain.
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Roman Haefeli wrote:
hi all
while i am at tweaking gem a bit, the next question: is it easily feasible to change the code of [pix_texture] so, that it has 'mode 0', when instantiating such an object. having to put a 'mode 0', whenever i load a help-patch is quite a pain.
i think the best method would be to use environmental variables.
probably i'll implement that soon. (i was wondering about that for some time...)
mfgasdr IOhannes
I changed the default to mode 0 about six weeks ago for non-OSX systems.
On 9/19/07, Roman Haefeli reduzierer@yahoo.de wrote:
hi all
while i am at tweaking gem a bit, the next question: is it easily feasible to change the code of [pix_texture] so, that it has 'mode 0', when instantiating such an object. having to put a 'mode 0', whenever i load a help-patch is quite a pain.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
oh.. didn't realize that. good to know. thanks a lot.
roman
On Thu, 2007-09-20 at 09:22 -0500, chris clepper wrote:
I changed the default to mode 0 about six weeks ago for non-OSX systems.
On 9/19/07, Roman Haefeli reduzierer@yahoo.de wrote: hi all
while i am at tweaking gem a bit, the next question: is it easily feasible to change the code of [pix_texture] so, that it has 'mode 0', when instantiating such an object. having to put a 'mode 0', whenever i load a help-patch is quite a pain. roman ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de _______________________________________________ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
chris clepper wrote:
I changed the default to mode 0 about six weeks ago for non-OSX systems.
but stull, wouldn't user-settable (runtime) defaults be an even better option? on my nvidia hardware i would very much prefer to have rectangle textures by default (the last tests i did with the gemframebuffer, only worked in rectangle-mode too; i think it is just the way to go if the card supports it); since the problem is (most likely) buggy hardware/drivers, where we have no (generic) way to predict the behaviour of the system, it would be good to let the user do some checks and adjust their system accordingly.
anyhow, probably i'll do that tomorrow: how about an environment variable "GEM_RECTANGLE_TEXTURE" which could be set to "0" to prevent the use of rectangle textures. (unset or 1 would check for rectangle-support of the driver before enabling it)
fm.adsr IOhannes
On 9/20/07, IOhannes m zmoelnig zmoelnig@iem.at wrote:
anyhow, probably i'll do that tomorrow: how about an environment variable "GEM_RECTANGLE_TEXTURE" which could be set to "0" to prevent the use of rectangle textures. (unset or 1 would check for rectangle-support of the driver before enabling it)
Is this just for Linux? The problem doesn't exist on OSX and I'm not sure how many people know how to adjust environment variables under Windows. I have never seen much performance difference between the two modes under Windows either.
Can you try a GLEW test for this? I know we have talked about using GLEW for a long time, and this seems like a good one to start with.
cgc
Quoting chris clepper cgclepper@gmail.com:
On 9/20/07, IOhannes m zmoelnig zmoelnig@iem.at wrote:
anyhow, probably i'll do that tomorrow: how about an environment variable "GEM_RECTANGLE_TEXTURE" which could be set to "0" to prevent the use of rectangle textures. (unset or 1 would check for rectangle-support of the driver before enabling it)
Is this just for Linux? The problem doesn't exist on OSX and I'm not sure how many people know how to adjust environment variables under Windows. I have never seen much performance difference between the two modes under Windows either.
Can you try a GLEW test for this? I know we have talked about using GLEW for a long time, and this seems like a good one to start with.
this would of course be better (if it works; if it really is a buggy driver thing, then i don't think that glew will be able to detect it)
roman, could you please try to install "glew" (if you are on debian|ubuntu, there is a package, called "libglew1" (or was it "glew"?)) and run "glewinfo"; then send me/us the output of this?
mfg.asdr IOhannes
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
On Thu, 2007-09-20 at 23:49 +0200, zmoelnig@iem.at wrote:
roman, could you please try to install "glew" (if you are on debian|ubuntu, there is a package, called "libglew1" (or was it "glew"?)) and run "glewinfo"; then send me/us the output of this?
here we go. i hope it is of any help.
http://www.romanhaefeli.net/glewinfo.txt
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
GL_EXT_texture_rectangle: OK
GLEW reports that your hardware supports rectangle textures (mode 1). It should work just fine and if it doesn't file a bug with whoever wrote your drivers.
On 9/20/07, Roman Haefeli reduzierer@yahoo.de wrote:
On Thu, 2007-09-20 at 23:49 +0200, zmoelnig@iem.at wrote:
roman, could you please try to install "glew" (if you are on debian|ubuntu, there is a package, called "libglew1" (or was it "glew"?)) and run "glewinfo"; then send me/us the output of this?
here we go. i hope it is of any help.
http://www.romanhaefeli.net/glewinfo.txt
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On Thu, 2007-09-20 at 19:54 -0500, chris clepper wrote:
GL_EXT_texture_rectangle: OK GLEW reports that your hardware supports rectangle textures (mode 1). It should work just fine and if it doesn't file a bug with whoever wrote your drivers.
well, i am not an expert, but when sending 'mode 1' to [pix_texture], i get in the pd-console:
[pix_texture]: using mode 1:GL_TEXTURE_RECTANGLE_ARB
and my glewinfo says:
GL_ARB_texture_rectangle: MISSING
for me it looks like gem is trying a feature, that isn't supported by my hardware. though, when compiling gem, 'configure --with-glversion=1.5' says:
using ARB-extensions : yes
am i supposed to disable ARB-extensions actively?
anyway, i don't have to send 'mode 0' to each [pix_texture] anymore, which i am very happy about. thank you again for solving this issue.
roman
On 9/20/07, Roman Haefeli reduzierer@yahoo.de wrote: On Thu, 2007-09-20 at 23:49 +0200, zmoelnig@iem.at wrote: > roman, could you please try to install "glew" (if you are on > debian|ubuntu, there is a package, called "libglew1" (or was it > "glew"?)) and run "glewinfo"; then send me/us the output of this?
here we go. i hope it is of any help. http://www.romanhaefeli.net/glewinfo.txt roman ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de _______________________________________________ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Roman Haefeli wrote:
On Thu, 2007-09-20 at 19:54 -0500, chris clepper wrote:
GL_EXT_texture_rectangle: OK GLEW reports that your hardware supports rectangle textures (mode 1). It should work just fine and if it doesn't file a bug with whoever wrote your drivers.
well, i am not an expert, but when sending 'mode 1' to [pix_texture], i get in the pd-console:
[pix_texture]: using mode 1:GL_TEXTURE_RECTANGLE_ARB
and my glewinfo says:
GL_ARB_texture_rectangle: MISSING
for me it looks like gem is trying a feature, that isn't supported by my hardware. though, when compiling gem, 'configure --with-glversion=1.5' says:
using ARB-extensions : yes
am i supposed to disable ARB-extensions actively?
yes you can do that.
apart from that: chris, i noticed that you changed the code from using GL_TEXTURE_RECTANGLE_EXT to GL_TEXTURE_RECTANGLE_ARB some weeks ago, because of dma issues on intel. this _might_ be romans problem. (which CVS version were you using? have you tried to downgrade pix_texture to revision-1.41?)
if so, one solution would be: use GL_TEXTURE_RECTANGLE_ARB is available, if not use GL_TEXTURE_RECTANGLE_EXT if available, else fall back to GL_TEXTURE_2D
so roman: please check whether [pix_texture] works with GL_TEXTURE_RECTANGLE_EXT (either check out an older version of pix_texture.cpp or just do a search and replace: s'|GL_TEXTURE_RECTANGLE_ARB|GL_TEXTURE_RECTANGLE_EXT|g' in pix_texture.cpp) if it does not work, please revert to _ARB and modify GemMan.cpp: in GemMan.cpp:1177-1180 change the occurences of "GL_EXT_texture_rectangle" to "GL_ARB_texture_rectangle".
mfg,.asdr IOhannes
On Fri, 2007-09-21 at 09:15 +0200, IOhannes m zmoelnig wrote:
Roman Haefeli wrote:
On Thu, 2007-09-20 at 19:54 -0500, chris clepper wrote:
GL_EXT_texture_rectangle: OK GLEW reports that your hardware supports rectangle textures (mode 1). It should work just fine and if it doesn't file a bug with whoever wrote your drivers.
well, i am not an expert, but when sending 'mode 1' to [pix_texture], i get in the pd-console:
[pix_texture]: using mode 1:GL_TEXTURE_RECTANGLE_ARB
and my glewinfo says:
GL_ARB_texture_rectangle: MISSING
for me it looks like gem is trying a feature, that isn't supported by my hardware. though, when compiling gem, 'configure --with-glversion=1.5' says:
using ARB-extensions : yes
am i supposed to disable ARB-extensions actively?
yes you can do that.
apart from that: chris, i noticed that you changed the code from using GL_TEXTURE_RECTANGLE_EXT to GL_TEXTURE_RECTANGLE_ARB some weeks ago, because of dma issues on intel. this _might_ be romans problem. (which CVS version were you using? have you tried to downgrade pix_texture to revision-1.41?)
if so, one solution would be: use GL_TEXTURE_RECTANGLE_ARB is available, if not use GL_TEXTURE_RECTANGLE_EXT if available, else fall back to GL_TEXTURE_2D
so roman: please check whether [pix_texture] works with GL_TEXTURE_RECTANGLE_EXT (either check out an older version of pix_texture.cpp or just do a search and replace: s'|GL_TEXTURE_RECTANGLE_ARB|GL_TEXTURE_RECTANGLE_EXT|g' in pix_texture.cpp) if it does not work, please revert to _ARB and modify GemMan.cpp: in GemMan.cpp:1177-1180 change the occurences of "GL_EXT_texture_rectangle" to "GL_ARB_texture_rectangle".
hi IOhannes
this might sound silly, but frankly i do not know, what the difference is between these two modes, thus i cannot say, if rectangle texturing works. actually, the only problem i had, was that 'mode 1' wasn't working and i had to put 'mode 0' everywhere in order to get an image at all. if you can tell me, how i could check, if rectangle texturing is working or not, i am able to say. so far, i do not notice any difference between those modes.
when switching mode, i get these messages:
[pix_texture]: using mode 1:GL_TEXTURE_RECTANGLE_ARB [pix_texture]: using mode 0:GL_TEXTURE_2D
without any error. i can't remember though, whether i had errors with the gem version, that was older than six weeks.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Roman Haefeli wrote:
hi IOhannes
this might sound silly, but frankly i do not know, what the difference is between these two modes, thus i cannot say, if rectangle texturing works.
it is not silly, but we (chris and me), assure you that the "mode" message does nothing but enable/disable rectangle texturing (if possible); i think it is a misnomer, as "mode" might mean anything...
when switching mode, i get these messages:
[pix_texture]: using mode 1:GL_TEXTURE_RECTANGLE_ARB [pix_texture]: using mode 0:GL_TEXTURE_2D
unfortunately this doesn't say much, as the object will always print this when you toggle the mode. (it is really: "if mode=1 print 'using mode 1:GL_TEXTURE_RECTANGLE_ARB'")
the good thing is, that when chris changed the code from _EXT to _ARB he basically did a search'n'replace, so it now posts "ARB" which made me have a look.
actually, the only problem i had, was that 'mode 1' wasn't working and i had to put 'mode 0' everywhere in order to get an image at all. if you can tell me, how i could check, if rectangle texturing is working or not, i am able to say. so far, i do not notice any difference between those modes.
well, actually i am trying to involve you into solving the problem. could you please apply to attached patch to the Gem-sources, re-compile and tell me if the problem is still there? please try both "mode 0" and "mode 1" messages (even if you are fine with using only "mode 0", i would prefer if both modi worked)
fmg.asdr IOhannes
On Fri, 2007-09-21 at 10:07 +0200, IOhannes m zmoelnig wrote:
Roman Haefeli wrote:
hi IOhannes
this might sound silly, but frankly i do not know, what the difference is between these two modes, thus i cannot say, if rectangle texturing works.
it is not silly, but we (chris and me), assure you that the "mode" message does nothing but enable/disable rectangle texturing (if possible); i think it is a misnomer, as "mode" might mean anything...
when switching mode, i get these messages:
[pix_texture]: using mode 1:GL_TEXTURE_RECTANGLE_ARB [pix_texture]: using mode 0:GL_TEXTURE_2D
unfortunately this doesn't say much, as the object will always print this when you toggle the mode. (it is really: "if mode=1 print 'using mode 1:GL_TEXTURE_RECTANGLE_ARB'")
the good thing is, that when chris changed the code from _EXT to _ARB he basically did a search'n'replace, so it now posts "ARB" which made me have a look.
actually, the only problem i had, was that 'mode 1' wasn't working and i had to put 'mode 0' everywhere in order to get an image at all. if you can tell me, how i could check, if rectangle texturing is working or not, i am able to say. so far, i do not notice any difference between those modes.
well, actually i am trying to involve you into solving the problem. could you please apply to attached patch to the Gem-sources, re-compile and tell me if the problem is still there?
i am sorry, if this sounds silly now, but which problem? right now, with the actual compile i can use both modi and with each the image is displayed correctly.
though, i'd be glad to help you testing, whereever i can.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Roman Haefeli wrote:
i am sorry, if this sounds silly now, but which problem? right now, with the actual compile i can use both modi and with each the image is displayed correctly.
i guess it is my turn to sound silly, but i was not able to read this from your previous emails. when i read "anyway, i don't have to send 'mode 0' to each [pix_texture] anymore, which i am very happy about. thank you again for solving this issue", i thought that you are happy now, that "mode 0" is the default. we know that "mode 0" works; so now, the [pix_texture] object works for you out-of-the-box, you would naturally not complain any more. but i also thought, that "mode 1" would still not work.
so: do you get an image in both modes? what is the output of the 2nd outlet of [pix_texture]? (for both modes; and one line is enought ;-))
though, i'd be glad to help you testing, whereever i can.
it would still be nice if you could test my patch.
mfadr IOhannes
On Fri, 2007-09-21 at 10:07 +0200, IOhannes m zmoelnig wrote:
actually, the only problem i had, was that 'mode 1' wasn't working and i had to put 'mode 0' everywhere in order to get an image at all. if you can tell me, how i could check, if rectangle texturing is working or not, i am able to say. so far, i do not notice any difference between those modes.
well, actually i am trying to involve you into solving the problem. could you please apply to attached patch to the Gem-sources, re-compile and tell me if the problem is still there? please try both "mode 0" and "mode 1" messages (even if you are fine with using only "mode 0", i would prefer if both modi worked)
i applied the patch and compiled gem with:
./configure --with-glversion=1.5
then i loaded the helppatch of [pix_texture] and tried both modi. i can't see any difference. with both the image is displayed correctly.
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Roman Haefeli wrote:
On Fri, 2007-09-21 at 10:07 +0200, IOhannes m zmoelnig wrote:
please try both "mode 0" and "mode 1" messages (even if you are fine with using only "mode 0", i would prefer if both modi worked)
i applied the patch and compiled gem with:
./configure --with-glversion=1.5
then i loaded the helppatch of [pix_texture] and tried both modi. i can't see any difference. with both the image is displayed correctly.
at least not bad :-)
still: could you send the output of the right outlet of [pix_texture] for both modi? could you try with non-power of 2 images? (e.g. video)
and finally: do you force glversion-1.5 because of the textures not working correctly or because of glsl-stuff that keeps Gem from loading?
if it is only the former, please try to compile without this option. i just want to make sure that not something else is actually solving your problem...
if it is the latter and you have time, you could also try to disable the openGL-wrappers (--disable-openGL) and delete the glsl_*.cpp from Manips/ to recompile without a forced max-openGL-version.
fmasd.r IOhannes
On Fri, 2007-09-21 at 11:38 +0200, IOhannes m zmoelnig wrote:
Roman Haefeli wrote:
On Fri, 2007-09-21 at 10:07 +0200, IOhannes m zmoelnig wrote:
please try both "mode 0" and "mode 1" messages (even if you are fine with using only "mode 0", i would prefer if both modi worked)
i applied the patch and compiled gem with:
./configure --with-glversion=1.5
then i loaded the helppatch of [pix_texture] and tried both modi. i can't see any difference. with both the image is displayed correctly.
at least not bad :-)
still: could you send the output of the right outlet of [pix_texture] for both modi?
[pix_texture]: using mode 0: TEXTURE_2D print: 3 0.613281 0.524414 3553 0
[pix_texture]: using mode 1: TEXTURE_RECTANGLE print: 3 0.613281 0.524414 3553 0
could you try with non-power of 2 images? (e.g. video)
my testimage had dimensions: 628 x 537 px (i think this should be odd enough ;-) )
and finally: do you force glversion-1.5 because of the textures not working correctly or because of glsl-stuff that keeps Gem from loading?
the latter is the case. i get 'undefined symbol: glUniform' or similar, when loading gem.
if it is the latter and you have time, you could also try to disable the openGL-wrappers (--disable-openGL) and delete the glsl_*.cpp from Manips/ to recompile without a forced max-openGL-version.
ah, ok. i'll do that tomorrow (today in a few hours).
good night roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Roman Haefeli wrote:
On Fri, 2007-09-21 at 11:38 +0200, IOhannes m zmoelnig wrote:
Roman Haefeli wrote:
On Fri, 2007-09-21 at 10:07 +0200, IOhannes m zmoelnig wrote:
please try both "mode 0" and "mode 1" messages (even if you are fine with using only "mode 0", i would prefer if both modi worked)
i applied the patch and compiled gem with:
./configure --with-glversion=1.5
then i loaded the helppatch of [pix_texture] and tried both modi. i can't see any difference. with both the image is displayed correctly.
at least not bad :-)
still: could you send the output of the right outlet of [pix_texture] for both modi?
[pix_texture]: using mode 0: TEXTURE_2D print: 3 0.613281 0.524414 3553 0
[pix_texture]: using mode 1: TEXTURE_RECTANGLE print: 3 0.613281 0.524414 3553 0
hmm, this means that you are not using rectangle textures at all (which is ok, if you card really does not support it)
however, if i read the glewinfo correctly, it should support the rectangle _EXTension.
could you also post the glxinfo output?
is there any chance in getting the outputs (of the 2nd outlet) of the last version (before my patch) and of the non-satisfying version?
furthermore, could you change the lines around GemMan.cpp:1180 from
#ifdef GL_ARB_texture_rectangle if (OpenGLExtensionIsSupported("GL_ARB_texture_rectangle")) { texture_rectangle_supported=2; } else #endif #ifdef GL_EXT_texture_rectangle if (OpenGLExtensionIsSupported("GL_EXT_texture_rectangle")) { texture_rectangle_supported=1; } else #endif texture_rectangle_supported = 0;
to something like:
#ifdef GL_ARB_texture_rectangle if (OpenGLExtensionIsSupported("GL_ARB_texture_rectangle")) { texture_rectangle_supported=2; post("ARB rectangle texturing"); } else #endif #ifdef GL_EXT_texture_rectangle if (OpenGLExtensionIsSupported("GL_EXT_texture_rectangle")) { texture_rectangle_supported=1; post("EXT rectangle texturing"); } else #endif texture_rectangle_supported = 0;
post("rectangle texturing support = %d", texture_rectangle_supported);
could you try with non-power of 2 images? (e.g. video)
my testimage had dimensions: 628 x 537 px (i think this should be odd enough ;-) )
right, should be weird... :-)
if it is the latter and you have time, you could also try to disable the openGL-wrappers (--disable-openGL) and delete the glsl_*.cpp from Manips/ to recompile without a forced max-openGL-version.
ah, ok. i'll do that tomorrow (today in a few hours).
oh, i keep forgetting that you are in canada now.... pleasant dreams..
fmga.sdr IOhannes
On Fri, 2007-09-21 at 12:43 +0200, IOhannes m zmoelnig wrote:
however, if i read the glewinfo correctly, it should support the rectangle _EXTension.
could you also post the glxinfo output?
http://romanhaefeli.net/glxinfo.txt
is there any chance in getting the outputs (of the 2nd outlet) of the last version (before my patch) and of the non-satisfying version?
could you try with non-power of 2 images? (e.g. video)
my testimage had dimensions: 628 x 537 px (i think this should be odd enough ;-) )
right, should be weird... :-)
if it is the latter and you have time, you could also try to disable the openGL-wrappers (--disable-openGL) and delete the glsl_*.cpp from Manips/ to recompile without a forced max-openGL-version.
ah, ok. i'll do that tomorrow (today in a few hours).
oh, i keep forgetting that you are in canada now.... pleasant dreams..
fmga.sdr IOhannes
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
sorry, i accidently clicked 'send', though last mail wasn't ready to send. here again:
On Fri, 2007-09-21 at 12:43 +0200, IOhannes m zmoelnig wrote:
however, if i read the glewinfo correctly, it should support the rectangle _EXTension.
could you also post the glxinfo output?
http://romanhaefeli.net/glxinfo.txt
is there any chance in getting the outputs (of the 2nd outlet) of the last version (before my patch) and of the non-satisfying version?
i think, i lost the binary of the version, where i still had to manually set to 'mode 0'. unfortunately i updated the sources in the meantime, so with the sources i have, i cannot compile a binary with the 'wanted unwanted' behaviour. if you tell me, how i can checkout a revision, that is more than 6 weeks old, i could do it, if you want.
furthermore, could you change the lines around GemMan.cpp:1180 from
i reverted everything to the actual cvs revision, i applied the changes in GemMan.cpp:1180, i deleted the files 'Manips/glsl_*.cpp', and i compiled gem:
./configure
there was apparently no need to disable the openGL wrappers.
i started pd -lib Gem, loaded pix_texture-help.pd, loaded an 628x537px image and i tried both modes:
[pix_texture]: using mode 0: TEXTURE_2D print: 1 0.613281 0.524414 3553 0
[pix_texture]: using mode 1: TEXTURE_RECTANGLE print: 1 0.613281 0.524414 3553 0
if it is the latter and you have time, you could also try to disable the openGL-wrappers (--disable-openGL) and delete the glsl_*.cpp from Manips/ to recompile without a forced max-openGL-version.
is deleting Manips/glsl_*.cpp the recommended way to get Gem working here? this is what i actually did some months ago, but someone on this list suggested using the flag '--with-glversion=1.5' instead. disabling the wrappers seems not to be necessary in my case.
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Roman Haefeli wrote:
furthermore, could you change the lines around GemMan.cpp:1180 from
i reverted everything to the actual cvs revision, i applied the changes in GemMan.cpp:1180, i deleted the files 'Manips/glsl_*.cpp', and i compiled gem:
./configure
there was apparently no need to disable the openGL wrappers.
i started pd -lib Gem, loaded pix_texture-help.pd, loaded an 628x537px image and i tried both modes:
[pix_texture]: using mode 0: TEXTURE_2D print: 1 0.613281 0.524414 3553 0
[pix_texture]: using mode 1: TEXTURE_RECTANGLE print: 1 0.613281 0.524414 3553 0
oops sorry i was unclear here: i thought, in addition to applying my first patch, you should change the lines mentioned.
then you should get some additionaly information when turning rendering on (or loading Gem,...) telling you something like "ARB texturing" or "EXT texturing" or "rectangle texturing support = 0" i would be interested in those 2 lines.
(before you do that, i would also be interested in what these lines say now, that you have reverted to CVS)
if it is the latter and you have time, you could also try to disable the openGL-wrappers (--disable-openGL) and delete the glsl_*.cpp from Manips/ to recompile without a forced max-openGL-version.
is deleting Manips/glsl_*.cpp the recommended way to get Gem working here? this is what i actually did some months ago, but someone on this list suggested using the flag '--with-glversion=1.5' instead. disabling the wrappers seems not to be necessary in my case.
deleting the files is NOT the recommended way. but when you force the max-GL version to be 1.5, you will also disable some other stuff (among them some retangle texturing stuff, which we are currently trying to debug) that is why i asked you to delete the files (in the unrecommended way) and compile with "full" openGL support.
if you want we probably should do this via a more interactive session (like irc)
fgmasdr IOhannes
On Tue, 2007-09-25 at 12:55 +0200, IOhannes m zmoelnig wrote:
if you want we probably should do this via a more interactive session (like irc)
yo, since i am in canada and in case you are only online for gem and pd stuff during usual working hours (do you do pd/Gem also in your free time?), we would be a bit timeshifted. though i am quite always logged in to #dataflow, but sometimes afk. just ping me we, when you're there.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Tue, 2007-09-25 at 12:55 +0200, IOhannes m zmoelnig wrote:
oops sorry i was unclear here: i thought, in addition to applying my first patch, you should change the lines mentioned.
np.
ok, i resume:
testprocess: ------------------------------------------------------
- create/get Gem binary
- start pd -lib Gem
- load pix_texture-help.pd
- load image (png 3-channel image of dimensions 454 x 459 px)
- try both modes 'mode 0/1'
- gather data from [pix_texture]'s second outlet.
results: ---------------------------------------------------------
TEST A
with gem binary from sources of todays cvs checkout:
[pix_texture]: using mode 0:GL_TEXTURE_2D print: 1 0.886719 0.896484 3553 0
[pix_texture]: using mode 1:GL_TEXTURE_RECTANGLE_ARB print: 1 0.886719 0.896484 3553 0
...............................................
TEST B
with gem binary made of sources more than two months old.
cvs update -D 2007-07-12 -dP
when turning rendering on, i get:
GL: invalid enumerant
no image, respectively only one pixel of the image is displayed image becomes visible after sending 'mode 0'.
[pix_texture]: using mode 0:GL_TEXTURE_2D print: 1 0.886719 0.896484 3553 0
[pix_texture]: using mode 1:GL_TEXTURE_RECTANGLE_EXT print: 1 0.886719 0.896484 3553 0
................................................
TEST C
gem binary compiled with todays sources and applied patch AND manually changed lines as proposed in previous mail of this thread.
sorry, i just realized, i cannot apply the patch anymore. i get:
roman@yoyo:~/pd-cvs/Gem-cvs/src$ patch -p0 < pixtexture.diff patching file Base/GemMan.cpp Hunk #1 succeeded at 1172 (offset -2 lines). Hunk #2 succeeded at 1196 (offset -2 lines). patching file Pixes/pix_movieNEW.h patching file Pixes/pix_texture.cpp Hunk #2 FAILED at 64. Hunk #3 FAILED at 97. Hunk #4 FAILED at 138. Hunk #5 succeeded at 189 (offset -1 lines). Hunk #6 FAILED at 231. Hunk #7 succeeded at 264 (offset -3 lines). Hunk #8 succeeded at 332 (offset -8 lines). Hunk #9 succeeded at 357 (offset -8 lines). Hunk #10 succeeded at 435 with fuzz 2 (offset -8 lines). Hunk #11 succeeded at 556 (offset -8 lines). Hunk #12 FAILED at 672. 5 out of 12 hunks FAILED -- saving rejects to file Pixes/pix_texture.cpp.rej patching file Pixes/pix_texture.h
it seems, that pix_texture.cpp was changed since the patch was created. does the patch needs an update as well?
...........................................................
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Fri, 2007-09-28 at 02:52 +0200, Roman Haefeli wrote:
On Tue, 2007-09-25 at 12:55 +0200, IOhannes m zmoelnig wrote:
oops sorry i was unclear here: i thought, in addition to applying my first patch, you should change the lines mentioned.
np.
ok, i resume:
testprocess:
create/get Gem binary
start pd -lib Gem
load pix_texture-help.pd
load image (png 3-channel image of dimensions 454 x 459 px)
try both modes 'mode 0/1'
gather data from [pix_texture]'s second outlet.
results:
TEST A
with gem binary from sources of todays cvs checkout:
[pix_texture]: using mode 0:GL_TEXTURE_2D print: 1 0.886719 0.896484 3553 0
[pix_texture]: using mode 1:GL_TEXTURE_RECTANGLE_ARB print: 1 0.886719 0.896484 3553 0
...............................................
TEST B
with gem binary made of sources more than two months old.
cvs update -D 2007-07-12 -dP
when turning rendering on, i get:
GL: invalid enumerant
no image, respectively only one pixel of the image is displayed image becomes visible after sending 'mode 0'.
[pix_texture]: using mode 0:GL_TEXTURE_2D print: 1 0.886719 0.896484 3553 0
[pix_texture]: using mode 1:GL_TEXTURE_RECTANGLE_EXT print: 1 0.886719 0.896484 3553 0
................................................
TEST C
gem binary compiled with todays sources and applied patch AND manually changed lines as proposed in previous mail of this thread.
sorry, i just realized, i cannot apply the patch anymore. i get:
roman@yoyo:~/pd-cvs/Gem-cvs/src$ patch -p0 < pixtexture.diff patching file Base/GemMan.cpp Hunk #1 succeeded at 1172 (offset -2 lines). Hunk #2 succeeded at 1196 (offset -2 lines). patching file Pixes/pix_movieNEW.h patching file Pixes/pix_texture.cpp Hunk #2 FAILED at 64. Hunk #3 FAILED at 97. Hunk #4 FAILED at 138. Hunk #5 succeeded at 189 (offset -1 lines). Hunk #6 FAILED at 231. Hunk #7 succeeded at 264 (offset -3 lines). Hunk #8 succeeded at 332 (offset -8 lines). Hunk #9 succeeded at 357 (offset -8 lines). Hunk #10 succeeded at 435 with fuzz 2 (offset -8 lines). Hunk #11 succeeded at 556 (offset -8 lines). Hunk #12 FAILED at 672. 5 out of 12 hunks FAILED -- saving rejects to file Pixes/pix_texture.cpp.rej patching file Pixes/pix_texture.h
it seems, that pix_texture.cpp was changed since the patch was created. does the patch needs an update as well?
geeezz..... sorry for complicating things so much. it turned out, that i was still using the old (2007-07-12) sources. since i was not sure, how to revert to actual state (is that what is meant by 'reset stickiness'?), i just did everything from scratch:
TEST C
- i deleted whole tree - i checked out a fresh sources - i applied IOhannes' patch from a previous post - i manually edited Base/GemMan.cpp according to a previous post of IOhannes - i deleted Manips/glsl*.cpp - aclocal && autoconf && ./configure && make
(i hope i did everything right this time)
but the test results don't seem to contain any new information, i still get:
[pix_texture]: using mode 0: TEXTURE_2D print: 1 0.886719 0.896484 3553 0
[pix_texture]: using mode 1: TEXTURE_RECTANGLE print: 1 0.886719 0.896484 3553 0
..........................................................
yo, IOhannes, in case i still did something wrong, please give me detailed instructions, even if they seem to be redundant in your eyes. otherwise you need to tell me what to do else. an interactive session (#dataflow) would probably be cool.
and sorry for the delay.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Sat, 2007-09-29 at 04:35 +0200, Roman Haefeli wrote:
On Fri, 2007-09-28 at 02:52 +0200, Roman Haefeli wrote:
On Tue, 2007-09-25 at 12:55 +0200, IOhannes m zmoelnig wrote:
oops sorry i was unclear here: i thought, in addition to applying my first patch, you should change the lines mentioned.
np.
ok, i resume:
testprocess:
create/get Gem binary
start pd -lib Gem
load pix_texture-help.pd
load image (png 3-channel image of dimensions 454 x 459 px)
try both modes 'mode 0/1'
gather data from [pix_texture]'s second outlet.
results:
TEST A
with gem binary from sources of todays cvs checkout:
[pix_texture]: using mode 0:GL_TEXTURE_2D print: 1 0.886719 0.896484 3553 0
[pix_texture]: using mode 1:GL_TEXTURE_RECTANGLE_ARB print: 1 0.886719 0.896484 3553 0
...............................................
TEST B
with gem binary made of sources more than two months old.
cvs update -D 2007-07-12 -dP
when turning rendering on, i get:
GL: invalid enumerant
no image, respectively only one pixel of the image is displayed image becomes visible after sending 'mode 0'.
[pix_texture]: using mode 0:GL_TEXTURE_2D print: 1 0.886719 0.896484 3553 0
[pix_texture]: using mode 1:GL_TEXTURE_RECTANGLE_EXT print: 1 0.886719 0.896484 3553 0
................................................
TEST C
gem binary compiled with todays sources and applied patch AND manually changed lines as proposed in previous mail of this thread.
sorry, i just realized, i cannot apply the patch anymore. i get:
roman@yoyo:~/pd-cvs/Gem-cvs/src$ patch -p0 < pixtexture.diff patching file Base/GemMan.cpp Hunk #1 succeeded at 1172 (offset -2 lines). Hunk #2 succeeded at 1196 (offset -2 lines). patching file Pixes/pix_movieNEW.h patching file Pixes/pix_texture.cpp Hunk #2 FAILED at 64. Hunk #3 FAILED at 97. Hunk #4 FAILED at 138. Hunk #5 succeeded at 189 (offset -1 lines). Hunk #6 FAILED at 231. Hunk #7 succeeded at 264 (offset -3 lines). Hunk #8 succeeded at 332 (offset -8 lines). Hunk #9 succeeded at 357 (offset -8 lines). Hunk #10 succeeded at 435 with fuzz 2 (offset -8 lines). Hunk #11 succeeded at 556 (offset -8 lines). Hunk #12 FAILED at 672. 5 out of 12 hunks FAILED -- saving rejects to file Pixes/pix_texture.cpp.rej patching file Pixes/pix_texture.h
it seems, that pix_texture.cpp was changed since the patch was created. does the patch needs an update as well?
geeezz..... sorry for complicating things so much. it turned out, that i was still using the old (2007-07-12) sources. since i was not sure, how to revert to actual state (is that what is meant by 'reset stickiness'?), i just did everything from scratch:
TEST C
- i deleted whole tree
- i checked out a fresh sources
- i applied IOhannes' patch from a previous post
- i manually edited Base/GemMan.cpp according to a previous post of
IOhannes
- i deleted Manips/glsl*.cpp
- aclocal && autoconf && ./configure && make
(i hope i did everything right this time)
but the test results don't seem to contain any new information, i still get:
[pix_texture]: using mode 0: TEXTURE_2D print: 1 0.886719 0.896484 3553 0
[pix_texture]: using mode 1: TEXTURE_RECTANGLE print: 1 0.886719 0.896484 3553 0
by accident, i probably found, what you have been looking for. when 'create'ing the gemwin, i get:
rectangle texturing support = 0
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On Sep 20, 2007, at 1:58 PM, IOhannes m zmoelnig wrote:
chris clepper wrote:
I changed the default to mode 0 about six weeks ago for non-OSX systems.
but stull, wouldn't user-settable (runtime) defaults be an even better option? on my nvidia hardware i would very much prefer to have rectangle textures by default (the last tests i did with the gemframebuffer, only worked in rectangle-mode too; i think it is just the way to go if the card supports it); since the problem is (most likely) buggy hardware/drivers, where we have no (generic) way to predict the behaviour of the system, it would be good to let the user do some checks and adjust their system accordingly.
anyhow, probably i'll do that tomorrow: how about an environment variable "GEM_RECTANGLE_TEXTURE" which could be set to "0" to prevent the use of rectangle textures. (unset or 1 would check for rectangle-support of the driver before enabling it)
How about:
[loadbang] | [mode 1( | [pix_texture]
Works well everyone else in Pd, I don't a reason for a new method of setting such things.
.hc
fm.adsr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
------------------------------------------------------------------------ ----
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
Hans-Christoph Steiner wrote:
How about:
[loadbang] | [mode 1( | [pix_texture]
Works well everyone else in Pd, I don't a reason for a new method of setting such things.
because in my opinion this is a tweak to fix a buggy 3rd party product. i would prefer to not expose this in the patches. it might break your patch once the 3rd party product is fixed. (even though in this special case it might as well not)
apart from that, your code doesn't work with dynamic patching.
finally: even if there are "other ways" to fix it, you can still use your method.
and last: i'd rather have the rectangle mode enabled by default if the card/driver reports to support it; if it doesn't it is NO problem of Gem at all: file a bug report at ATI. (i guess it is just that from a social point of view things might be more likely to be "fixed" in Gem then in the driver)
mfadr IOhannes
On Sep 21, 2007, at 2:39 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
How about:
[loadbang] | [mode 1( | [pix_texture]
Works well everyone else in Pd, I don't a reason for a new method of setting such things.
because in my opinion this is a tweak to fix a buggy 3rd party product. i would prefer to not expose this in the patches. it might break your patch once the 3rd party product is fixed. (even though in this special case it might as well not)
apart from that, your code doesn't work with dynamic patching.
finally: even if there are "other ways" to fix it, you can still use your method.
and last: i'd rather have the rectangle mode enabled by default if the card/driver reports to support it; if it doesn't it is NO problem of Gem at all: file a bug report at ATI. (i guess it is just that from a social point of view things might be more likely to be "fixed" in Gem then in the driver)
I think it's a bad idea to add a new interface specific to this one issue. Nothing else uses environment variables to change the behavior of objects.
There must be techniques for testing whether something actually supports a given feature, rather than just reports it. I haven't heard of video games having these problems, and I imagine they do some kind of testing. I'm not saying it's easy, just that it should be possible :D
.hc
mfadr IOhannes
------------------------------------------------------------------------ ----
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
Quoting Hans-Christoph Steiner hans@eds.org:
I think it's a bad idea to add a new interface specific to this one issue. Nothing else uses environment variables to change the behavior of objects.
i think you are mistaken here in a historic sense, as at least one pd-library i know uses environment variables since more then 10 years now to fix broken implementations.
mfga.sdr IOhannes
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
-
chris clepper -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Roman Haefeli -
zmoelnig＠iem.at