Re: [PD] [GEM-dev] (GEM) color invasion
IOhannes m zmoelnig escribió: it saves the texture, modelview and color matrix stack (the latter obviously not being the "color"). i wonder why it's not saving the projection matrix stack as well. Great, thank you i suggest to create a wee little abstraction "myseparator", which looks like: Oh yes! Should have thought about it :$ the reason why the color is not stored and restored is simply performance. it's way faster to just set the color again than query it from the current openGL state (and color is a vertex based attribute; but this is really getting internal) Good to know that! Thanks again m. -- Matteo Sisti Sette matteosistise...@gmail.com http://www.matteosistisette.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [GEM-dev] (GEM) color invasion
Matteo Sisti Sette wrote: > > Is it that [separator] only separates certain things and does not > separate others? If so, where can I find a list (or a rule) that tells > me what it separates and what not? it saves the texture, modelview and color matrix stack (the latter obviously not being the "color"). i wonder why it's not saving the projection matrix stack as well. > > You may suggest that I can create separate [gemhead]s, but if I want the > resulting scene( to be rendered into a texture all chains must be > "children" of a single [gemframebuffer] and so of a single [gemhead] and > I can only "separate" them with [separator]s. > > So up to now my only solution is to put a [color 1 1 1] on every object > that I don't want to be coloured, but that's a bit unhandy well. i suggest to create a wee little abstraction "myseparator", which looks like: [inlet] | [separator] | [pix_separator] | [color 1 1 1] | [outlet] not so unhandy :-) the reason why the color is not stored and restored is simply performance. it's way faster to just set the color again than query it from the current openGL state (and color is a vertex based attribute; but this is really getting internal) gfamdsr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [GEM-dev] (GEM) color invasion
cyrille henry escribió: if you wish to render something white, then red, then white, with the same gemhead, you obviously need at least 2 color objects. That's "obvious" only once one knows that [separator] won't "reset" the color to its default value as it does with other things (not only geometry). If you wish to render something without alpha, then something with alpha enabled, then something without alpha again with the same gemhead, you _don't_ need at least two alpha objects, provided you use separators. -- Matteo Sisti Sette matteosistise...@gmail.com http://www.matteosistisette.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [GEM-dev] (GEM) color invasion
Matteo Sisti Sette a écrit : cyrille henry escribió: ... use trigger then. Well that would oblige me to render things in a given order (namely the coloured square last in this case) that may conflict with other order requirements. if you wish to render something white, then red, then white, with the same gemhead, you obviously need at least 2 color objects. That is, the fact of applying certain things to a given subchain shouldn't be necessarily vinculated to the fact of implying a certain rendering order: they are two different concept and independent requirement... no? it is like this in Gem, because of the way openGL is made. Gem is very close to the way openGL works. if you read all Gem documentation and need more, then you should read a openGL book. Cyrille ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [GEM-dev] (GEM) color invasion
cyrille henry escribió: separator only separate geometry. pix_separator separate textures. i think nothing separate the color. So am I the only one who misses an object that just "separate everything" By the way, as far as I have experimented, separator also "separates" [GEMglBlendFunc], that is, this object applied after a separator, affects the blending function only of the "subchain" under it, and does not apply to other "subchains", no matter the trigger order. (fortunately for me) Another thing that [separator] does separate independently of trigger order, is [alpha]. (fortunately again) So, since I can't tell whether blending and alpha belong to "geometry" or to "textures" (I'd say none) the question remains of which things (not related to geometry) [separator] separates. And by the way, what's the philosophical justification for [color] not being separated and [alpha] being separated? use trigger then. Well that would oblige me to render things in a given order (namely the coloured square last in this case) that may conflict with other order requirements. That is, the fact of applying certain things to a given subchain shouldn't be necessarily vinculated to the fact of implying a certain rendering order: they are two different concept and independent requirement... no? -- Matteo Sisti Sette matteosistise...@gmail.com http://www.matteosistisette.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [GEM-dev] (GEM) color invasion
Matteo Sisti Sette a écrit : Hi, Consider the following patch, where the [gemhead] is connected to all [separator]s (I'm not so good with ascii-art): [gemhead] ... [separator] [separator] [separator] || | [color 1 0 0] | | || | [translateXYZ...][translateXYZ...] | || | [square 2] [square 2][square 2] (with suitable values in translations so that all squares are visible) The 'issue' is that all squares are red. Is it normal/expected??? yes. I would expect only the square in the left chain to be red. Is it that [separator] only separates certain things and does not separate others? If so, where can I find a list (or a rule) that tells me what it separates and what not? separator only separate geometry. pix_separator separate textures. i think nothing separate the color. so you can either using trigger so that the red square is rendered last, or use a color object after each separator. You may suggest that I can create separate [gemhead]s, but if I want the resulting scene( to be rendered into a texture all chains must be "children" of a single [gemframebuffer] and so of a single [gemhead] and I can only "separate" them with [separator]s. So up to now my only solution is to put a [color 1 1 1] on every object that I don't want to be coloured, but that's a bit unhandy use trigger then. Cyrille ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [GEM-dev] [GEM]
Loic Kessous wrote: Hi, I just want to report this but I don't know if it's related to gem-dev or usual pd-gem, so sorry for cross-posting. I am using pix_movement and pix_movement2 on os X and MSW vista and apparently with pix_movement the display is not correct on MSW, It doesn't show the video processed but the original one. On os X it's working correctly. For pix_movement2 it's working on the 2 plateforms. this is as expected. when you are using [pix_movement] with an RGBA image-stream (which is the default on w32), it will store the difference images in the alpha-channel. if you send [pix_movement] a greyscale image (which has no alpha channel) it will output the processed data in the grey-channel as well. [pix_movement2] seems to internally convert the image to greyscale and work on the grey channel directly. you could: - convert the pix-stream to greyscale using [pix_grey] (before [pix_movement]) - turn on alpha-blending with the [alpha] object to let the alpha-channel have an effect. i know that this is somewhat inconsisten (for legacy reasons). storing the processed data in the alpha-channel sounded like a good idea back then. it doesn't sound that right now. it will stay like this for legacy reasons. (but thinking of it: it might be a good idea to turn the functionality of [pix_movement] into [pix_movement1] (consistent with [pix_movement2]) and make [pix_movement] an abstraction using the new object and mimicking the old behaviour. fhmasdr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [GEM-dev] GEM: something wrong with help patches location
This build of Gem for Windows should be included in the latest nightly builds. It would be great if someone tested everything to make sure the abstractions and help patches are in the right place. Instead of spending the time on a single manual install, this way everyone will benefit. http://autobuild.puredata.info/auto-build/ .hc On May 2, 2008, at 9:56 AM, IOhannes m zmoelnig wrote: > marius schebella wrote: >> hi matteo, >> the help patches for gem usually go into doc/5.reference/Gem (the > > no they don't. > they used to go there for old Pd-versions. > > > > anyhow: the .bat "installer" seems to be outdated. > > manual instructions are like (i am improvising now, so it might not > work...) > > create a \extra\Gem directory. > copy the "Gem.dll" from to \extra\Gem\ > copy all abstractions from \abstractions\ to \extra\Gem\ > copy all help-patches from \help\ to \extra\Gem\ > > after that you should have: > \extra\Gem\Gem.dll > \extra\Gem\gemwin-help.pd > > > fmgasdr. > IOhannes > > ___ > GEM-dev mailing list > [EMAIL PROTECTED] > http://lists.puredata.info/listinfo/gem-dev 'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink-collar temp pool day. - “Hijab Scene #2", by Mohja Kahf ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [GEM-dev] GEM: something wrong with help patches location
marius schebella wrote: > hi matteo, > the help patches for gem usually go into doc/5.reference/Gem (the no they don't. they used to go there for old Pd-versions. anyhow: the .bat "installer" seems to be outdated. manual instructions are like (i am improvising now, so it might not work...) create a \extra\Gem directory. copy the "Gem.dll" from to \extra\Gem\ copy all abstractions from \abstractions\ to \extra\Gem\ copy all help-patches from \help\ to \extra\Gem\ after that you should have: \extra\Gem\Gem.dll \extra\Gem\gemwin-help.pd fmgasdr. IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [GEM-dev] GEM: where to find gem-CVS20060412-NT-i686-bin (windows binaries)
Matteo Sisti Sette wrote: > > I remember a few months ago I asked the list (pd-list or gem-dev) for > versions more recent than the prehistoric 0.90, and somebody directed me to > a directory somewhere at iem.at with lots of cvs snapshot (is that what they > are?) and that's where I found gem-CVS20060412-NT-i686-bin.. but I can't > find neither that page nor the thread in the list archives. > > Can anybody help me find gem-CVS20060412-NT-i686-bin.zip? all these should be in http://gem.iem.at/releases/0.91 the old builds are just hidden, so that people do not get confused. you are most likely looking for: http://gem.iem.at/releases/0.91/gem-CVS20060412-NT-i686-bin.zip/view anyhow, the old binaries are hidden on purpose: the latest binary (which is visible) is meant to be a release-candidate. if yo are experiencing problems, please elaborate so that they can hopefully be fixed within the next days (or weeks): which things do NOT work? which behave differently? mfgasd.r IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [GEM-dev] GEM: something wrong with help patches location
hi matteo, the help patches for gem usually go into doc/5.reference/Gem (the capital letter G makes no difference on Windows). but there is no rule about this, and since the subdirectories of 5.reference are *not* searched by default, you can also put them directly into doc/5.reference. otherwise you have to add the path in your settings, which for vanilla is probably not set by default. good luck, marius. Matteo Sisti Sette wrote: > Hi, > > I've just installed the latest 0.91 beta GEM version for windows, using the > .bat installer that comes in the package, which copies all help and > documentation files where (supposedly) needed. > I installed it over a pd-vanilla 0.41-2. > > In the installer patch I edited the following lines: > > REM where does PD reside ?? > set PDPATH="%PROGRAMFILES%\pd 0.41-2" > REM which pd-version do we have ? > set PDVERSION=0.41 > > If I create an [alpha] or [color] or [gemwin], [gemhead], [pix_texture], > [rectangle] or ALMOST any objects, and then right-click on them and select > "help", I get the message: > >sorry, couldn't find help patch for "alpha.pd" > > But I do can get the help patch for [pix_film] and [pix_movie] (they > seem to be the only 2 objects whose help I can open, among the ones I have > tried). > > What am I doing wrong? > > I now see that all the help patches have been copied to > %PDPATH%/extra/help-Gem > > I have also tried by manually copying them also into > %PDPATH%/doc/5.reference/gem > but it doesn't work either. > > Where should I put the help patches??? > > On another machine where I installed an older version of GEM it used to > work.. > > > ___ > GEM-dev mailing list > [EMAIL PROTECTED] > http://lists.puredata.info/listinfo/gem-dev > ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [GEM-dev] Gem = vertex
Hello, Chris McCormick a écrit : > On Thu, Dec 27, 2007 at 08:03:31AM +0100, Frank Barknecht wrote: >> Hallo, >> Patrice Colet hat gesagt: // Patrice Colet wrote: >> >>> You don't have any idea how it is frustrating to not have such feature >>> because of the graphic card, or something, for me shading and vertex is >>> a myth. >> For me, too. But it's optional. > > It's not optional if you want to move verticies around in space though > (e.g. to deform a mesh) since there is no other inexpensive way to do > it in Gem. > > I think we have the same GFX card. :( > A friend of mine upgraded his computer and sold me a right Nvidia 6600 GC, so I tried Gem-91. That has both resolved the frustration of not being able to use glsl functionnalities, and some other object issue( pix_snap work like it's expected in the doc file with this 'new' GC, before the snaped texture came from somewhere I couldn't explain, once I had the VNC stream rendered into the texture, :o, under linux pix_snap worked correctly). @+ pk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [GEM-dev] gem : using texture for vertex position
You are most likely turning on software rendering by accessing the texture in the vertex shader. Textures are uploaded as 8 bit per component which is the standard for images and video. Changing this to 32 bit floats is extremely inefficient. There might be a way to specify the GPU storage to be 32 bit float, but typically the driver would do the conversion slowly and not the GPU. Render to texture using gemframebuffer with a 'format FLOAT' message will give a float texture to read from in the shaders. I see that you filed a bug that this object does not work on your machine though. Maybe you can try another? You could try changing the code in pix_texture and recompiling. Change the format from GL_UNSIGNED_BYTE to GL_FLOAT to see if that works and speeds it up. The uploaded texture will not contain the right values since the GPU expects a float and the image is still 8 bit. I probably won't have time to work on this for a few weeks, but I want to get the framebuffer working better. On 9/9/07, cyrille henry <[EMAIL PROTECTED]> wrote: > > hello, > > i'm tring to do more physics on the GPU, and i'm facing some problems. > simulation results can be compute on texture (just like the wave example i > send month ago), so now i'd like to use this texture to move vertex. > > if i acces to a texture with a vertex shader just like on a fragment > shader, then it's very slow. > (cpu is at 100%) > > i found that : > "vertex textures must be 32-bit-per-component textures, floating point, > and they can't use any filtering mode except nearest filtering." > > i tryed "quality 0" to pix_texture in order to have the nearest filtering > mode, but i'm not sure about the 32 bit per component texture. > is it the default on Gem? > if no, is it possible to change it? > > anyone already have an exemple how to use a texture to displace vertex? > > > thanks > > cyrille > > ___ > GEM-dev mailing list > [EMAIL PROTECTED] > http://lists.puredata.info/listinfo/gem-dev > ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [GEM-dev] Gem Compiling os x xcode problems
Both Pd-extended auto-builds should work, so please report on either/ both. I am also seeing problems. If I manually run "make gem" it seems to work, but not as an auto-build... arg. .hc On May 9, 2007, at 11:15 AM, <[EMAIL PROTECTED]> wrote: > I went to the "latest" folder and downloaded this one: > > Pd-0.39.2-extended-rc2-macosx104-powerpc.dmg > > The build date is 9-May-2007. Is that the one I should have used? > Alain > >> >> From: IOhannes m zmoelnig <[EMAIL PROTECTED]> >> Date: 2007/05/09 Wed AM 11:14:37 EDT >> CC: Pure Data List , [EMAIL PROTECTED] >> Subject: Re: [GEM-dev] [PD] Gem Compiling os x xcode problems >> >> [EMAIL PROTECTED] wrote: >>> Thats cool, I think thats an elegant solution. Then I dont get >>> why I still get this message from Gem: >>> >>> [text2d]: Gem has been compiled without FONT-support ! >>> >>> This is from the latest auto-build (may 9). >> >> which autobuild? currently there are several versions of pd-extended >> built each night, probably one of them uses the old non-font Gem? >> >>> Well I'm still very green at this, hope you can figure it out. I >>> will keep testing the nightly-builds for > font >>> support. This process has been my first experience with >>> compiling anything. BTW i was able to > get >>> text support going by including the static library within the Gem >>> build. Gem blew up to 4.2MB, its a >>> fatty but it works for my purposes. >> >> well, that's the joy auf static linking (and that is one of the >> reasons >> why on w32 and os-x most apps are so huge, while on linux most of >> them >> are tiny) >> >> mfg.adr >> IOhannes >> >> ___ >> GEM-dev mailing list >> [EMAIL PROTECTED] >> http://lists.puredata.info/listinfo/gem-dev >> > > > ___ > GEM-dev mailing list > [EMAIL PROTECTED] > http://lists.puredata.info/listinfo/gem-dev Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism.- retired U.S. Army general, William Odom ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [GEM-dev] Gem Compiling os x xcode problems
I went to the "latest" folder and downloaded this one: Pd-0.39.2-extended-rc2-macosx104-powerpc.dmg The build date is 9-May-2007. Is that the one I should have used? Alain > > From: IOhannes m zmoelnig <[EMAIL PROTECTED]> > Date: 2007/05/09 Wed AM 11:14:37 EDT > CC: Pure Data List , [EMAIL PROTECTED] > Subject: Re: [GEM-dev] [PD] Gem Compiling os x xcode problems > > [EMAIL PROTECTED] wrote: > > Thats cool, I think thats an elegant solution. Then I dont get why I still > > get this message from Gem: > > > > [text2d]: Gem has been compiled without FONT-support ! > > > > This is from the latest auto-build (may 9). > > which autobuild? currently there are several versions of pd-extended > built each night, probably one of them uses the old non-font Gem? > > > Well I'm still very green at this, hope you can figure it out. I will keep > > testing the nightly-builds for font > > support. This process has been my first experience with compiling > > anything. BTW i was able to get > > text support going by including the static library within the Gem build. > > Gem blew up to 4.2MB, its a > > fatty but it works for my purposes. > > well, that's the joy auf static linking (and that is one of the reasons > why on w32 and os-x most apps are so huge, while on linux most of them > are tiny) > > mfg.adr > IOhannes > > ___ > GEM-dev mailing list > [EMAIL PROTECTED] > http://lists.puredata.info/listinfo/gem-dev > ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [GEM-dev] Gem Compiling os x xcode problems
[EMAIL PROTECTED] wrote: > Thats cool, I think thats an elegant solution. Then I dont get why I still > get this message from Gem: > > [text2d]: Gem has been compiled without FONT-support ! > > This is from the latest auto-build (may 9). which autobuild? currently there are several versions of pd-extended built each night, probably one of them uses the old non-font Gem? > Well I'm still very green at this, hope you can figure it out. I will keep > testing the nightly-builds for font > support. This process has been my first experience with compiling anything. > BTW i was able to get > text support going by including the static library within the Gem build. Gem > blew up to 4.2MB, its a > fatty but it works for my purposes. well, that's the joy auf static linking (and that is one of the reasons why on w32 and os-x most apps are so huge, while on linux most of them are tiny) mfg.adr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [GEM-dev] Gem Compiling os x xcode problems
Thats cool, I think thats an elegant solution. Then I dont get why I still get this message from Gem: [text2d]: Gem has been compiled without FONT-support ! This is from the latest auto-build (may 9). I can clearly see the libfreetype.6.dylib in the correct path. Well I'm still very green at this, hope you can figure it out. I will keep testing the nightly-builds for font support. This process has been my first experience with compiling anything. BTW i was able to get text support going by including the static library within the Gem build. Gem blew up to 4.2MB, its a fatty but it works for my purposes. Alain > > From: Hans-Christoph Steiner <[EMAIL PROTECTED]> > Date: 2007/05/09 Wed AM 12:49:15 EDT > To: Nose Hair <[EMAIL PROTECTED]> > CC: [EMAIL PROTECTED], Pure Data List > Subject: Re: [GEM-dev] [PD] Gem Compiling os x xcode problems > > > Actually, using Fink, I have scripted the build system to > automatically include any dynamic libs that are needed. This is > already working well for ogg, vorbis, speex, and now PDP stuff. I > see no reason why it shouldn't work for Gem too. > > If you look in Pd.app/Contents/lib you can see all the included .dylibs. > > .hc > > On May 8, 2007, at 10:24 PM, Nose Hair wrote: > > > I tested last nights auto-build and it still says gem is compiled > > without font support. I will give tonight's build a shot and let > > you know. BTW I think that a static lib pointing to the X11 > > freetype is the way to go because if someone already has x11 > > installed they don't have to compile and install freetype from > > scratch. It's not hard but it would be more of a pain as opposed > > to installing the X11 package from their Tiger DVD. > > Alain > > > > On May 8, 2007, at 9:00 PM, Hans-Christoph Steiner wrote: > > > >> > >> Does freetype have to be statically linked? Will it work with > >> dynamic? Right now, the auto-build compiles with a dynamic > >> freetype lib, and I have a script that includes all the required > >> dynamic libs. > >> > >> .hc > >> > >> On May 8, 2007, at 10:26 AM, chris clepper wrote: > >> > >>> Use static linking for freetype and FTGL on OSX. > >>> > >>> On 5/8/07, [EMAIL PROTECTED] < [EMAIL PROTECTED]> > >>> wrote: > >>> I have gotten Gem to compile sucesfully with font support using > >>> the xcode project somewhat. I get 1125 > >>> warnings, mainly this is the location of the previous > >>> definition. My biggets problem is that in my machine > >>> I have the latest freetype under usr/local/lib and I also have > >>> the freetype that comes with x11 under usr/ > >>> X11R6/lib. When I load gen in my machine it loads up fine with > >>> text support, but when I load up gem in a > >>> machine with only the freetype in usr/X11R6/lib Gem will not load > >>> up because it keeps looking for the > >>> libfreetype.6.dylib in usr/local/lib. I dont know how to remedy > >>> this. Any help would be great. > >>> Thanks, > >>> Alain > >>> > >>> > >>> ___ > >>> PD-list@iem.at mailing list > >>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ > >>> listinfo/pd-list > >>> > >>> ___ > >>> GEM-dev mailing list > >>> [EMAIL PROTECTED] > >>> http://lists.puredata.info/listinfo/gem-dev > >> > >> > >> > >> - > >> --- > >> > >> All information should be free. - the hacker ethic > >> > >> > >> > >> > > > > > > > > >¡El pueblo unido jamás será vencido! > > > > ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [GEM-dev] Gem Compiling os x xcode problems
Actually, using Fink, I have scripted the build system to automatically include any dynamic libs that are needed. This is already working well for ogg, vorbis, speex, and now PDP stuff. I see no reason why it shouldn't work for Gem too. If you look in Pd.app/Contents/lib you can see all the included .dylibs. .hc On May 8, 2007, at 10:24 PM, Nose Hair wrote: I tested last nights auto-build and it still says gem is compiled without font support. I will give tonight's build a shot and let you know. BTW I think that a static lib pointing to the X11 freetype is the way to go because if someone already has x11 installed they don't have to compile and install freetype from scratch. It's not hard but it would be more of a pain as opposed to installing the X11 package from their Tiger DVD. Alain On May 8, 2007, at 9:00 PM, Hans-Christoph Steiner wrote: Does freetype have to be statically linked? Will it work with dynamic? Right now, the auto-build compiles with a dynamic freetype lib, and I have a script that includes all the required dynamic libs. .hc On May 8, 2007, at 10:26 AM, chris clepper wrote: Use static linking for freetype and FTGL on OSX. On 5/8/07, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote: I have gotten Gem to compile sucesfully with font support using the xcode project somewhat. I get 1125 warnings, mainly this is the location of the previous definition. My biggets problem is that in my machine I have the latest freetype under usr/local/lib and I also have the freetype that comes with x11 under usr/ X11R6/lib. When I load gen in my machine it loads up fine with text support, but when I load up gem in a machine with only the freetype in usr/X11R6/lib Gem will not load up because it keeps looking for the libfreetype.6.dylib in usr/local/lib. I dont know how to remedy this. Any help would be great. Thanks, Alain ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list ___ GEM-dev mailing list [EMAIL PROTECTED] http://lists.puredata.info/listinfo/gem-dev - --- All information should be free. - the hacker ethic ¡El pueblo unido jamás será vencido! ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [GEM-dev] Gem Compiling os x xcode problems
I tested last nights auto-build and it still says gem is compiled without font support. I will give tonight's build a shot and let you know. BTW I think that a static lib pointing to the X11 freetype is the way to go because if someone already has x11 installed they don't have to compile and install freetype from scratch. It's not hard but it would be more of a pain as opposed to installing the X11 package from their Tiger DVD. Alain On May 8, 2007, at 9:00 PM, Hans-Christoph Steiner wrote: Does freetype have to be statically linked? Will it work with dynamic? Right now, the auto-build compiles with a dynamic freetype lib, and I have a script that includes all the required dynamic libs. .hc On May 8, 2007, at 10:26 AM, chris clepper wrote: Use static linking for freetype and FTGL on OSX. On 5/8/07, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote: I have gotten Gem to compile sucesfully with font support using the xcode project somewhat. I get 1125 warnings, mainly this is the location of the previous definition. My biggets problem is that in my machine I have the latest freetype under usr/local/lib and I also have the freetype that comes with x11 under usr/ X11R6/lib. When I load gen in my machine it loads up fine with text support, but when I load up gem in a machine with only the freetype in usr/X11R6/lib Gem will not load up because it keeps looking for the libfreetype.6.dylib in usr/local/lib. I dont know how to remedy this. Any help would be great. Thanks, Alain ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list ___ GEM-dev mailing list [EMAIL PROTECTED] http://lists.puredata.info/listinfo/gem-dev -- -- All information should be free. - the hacker ethic ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [GEM-dev] Gem Compiling os x xcode problems
Does freetype have to be statically linked? Will it work with dynamic? Right now, the auto-build compiles with a dynamic freetype lib, and I have a script that includes all the required dynamic libs. .hc On May 8, 2007, at 10:26 AM, chris clepper wrote: Use static linking for freetype and FTGL on OSX. On 5/8/07, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote: I have gotten Gem to compile sucesfully with font support using the xcode project somewhat. I get 1125 warnings, mainly this is the location of the previous definition. My biggets problem is that in my machine I have the latest freetype under usr/local/lib and I also have the freetype that comes with x11 under usr/ X11R6/lib. When I load gen in my machine it loads up fine with text support, but when I load up gem in a machine with only the freetype in usr/X11R6/lib Gem will not load up because it keeps looking for the libfreetype.6.dylib in usr/local/lib. I dont know how to remedy this. Any help would be great. Thanks, Alain ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list ___ GEM-dev mailing list [EMAIL PROTECTED] http://lists.puredata.info/listinfo/gem-dev All information should be free. - the hacker ethic ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
