2014-08-20 13:52 GMT+02:00 Jack <[email protected]>: > Just try with Gem from git:// > pd-gem.git.sourceforge.net/gitroot/pd-gem/Gem. >
this is the (too) old repo, up-to-date code is here : git:// git.code.sf.net/p/pd-gem/gem please try with that + a > [glsl_program] works fine. > Gem/examples/10.glsl/09 works fine. (get 0/1 from message gem_state so > vertex and fragment shaders are loaded) > > But i still get pd crash with libvlc. > > [gemkeyname] and [gemkeyboard] work fine with object [gemwin] but not with > abstraction [abstractions/gemwin]. > > ++ > > Jack > > > > > Le 20/08/2014 13:39, Jack a écrit : > > Le 20/08/2014 11:07, Cyrille Henry a écrit : > > Hello, > > > > thanks for the answer, sorry i missed that. > > things work lot's better now!!! > > > > i still have few problem : > > - when starting pd in the Gem/ folder, it start correctlly. > > when starting pd in an other folder, pd segfault when loading > gem_videoVLC plugin > > so, i just remove it : sudo rm /usr/local/lib/pd/extra/Gem/gem_videoVLC.* > > Yep, there is conflict between libvlc and other libraries. > > > > > - i did not try all example, but most work. i do however have some > problem with Gem/examples/10.glsl/05.multitexture_bis.pd > > if i open and close this patch, pd segfault (even without opening a > rendering window). The patch did work. > > The problem seems to be [glsl_program]. An exemple patch is attached ;) > > > > > - some other shader example did not render anything unless i configure > optimus to use the nvidia card. It's not a gem fault, just the intel HD and > it's driver. > > Yep. > But I also notice [gemframebuffer] with IntelHD doesn't like [format > RGB32(. > For exemple, in Gem/examples/10.glsl/09... it is possible to change > [format RGB32( to [format RGB( to have something working on IntelHD. Maybe > it is possible to add a comment in the patch (or add a new message) to > explain how to make this patch working on IntelHD ? > > > - gemwin use to send 1 / 0 when start / stop rendering. i sometime use > this to load shader, like in example Gem/examples/10.glsl/09... In this > example, i have to manually load the shader. > > I just create a patch with : > > [gemhead] > | > [route gem_state] > | > [print] > > and there is no more 0/1 in pd console when you create or destroy gemwin. > On my side, i only use [loadbang] to load vertex/geometry/fragment shaders. > > > - gemmouse work, but not gemkeyname > > [gemkeyboard] doesn't work too. > ++ > > Jack > > PS : i just notice that i am working with Gem from > http://github.com/umlaeute/Gem. > I will try with Gem from git:// > pd-gem.git.sourceforge.net/gitroot/pd-gem/Gem ... > > > > > > thanks for all good work > > cheers > > c > > > > Le 20/08/2014 10:07, IOhannes m zmoelnig a écrit : > > On 2014-08-19 18:11, Cyrille Henry wrote: > >>> hello, > >>> > >>> i just tested the current Gem git. (i'm still using on ubuntu linux > >>> 14.04, intel hd4000) > >>> > >>> gemwin did not create. Gem/gemdefaultwindow can be created. it use > >>> gemglxwindow. (i have both gemglutwindow.pd_linux and > >>> gemglxwindow.pd_linux in /usr/local/lib/pd/extra/Gem) > >>> > >>> sending the create message on this object did create an empty > >>> window. but sending "1" did not enable rendering, i only get : > >>> gemglxwindow: no method for 'float' > >>> > >>> so : why did gemdefaultwindow is not named gemwin? > > that's by design. > > >>> (sould i just make a symlink?) > > no. [gemwin] and [gem*window] are *not* the same. > > > >>> more important : how can i enable rendering? > > > the design is obviously different from what you expect. > > [gemdefaultwindow] (or rather it's underlying implementations like > [gemglxwindow] or [gemglutwindow]) is really just a very thin wrapper > around an openGL-context. > all it can do is to create/destroy an openGL-context (aka window), and > make that context the "current" one (so any openGL commands are > exectuted within this context). > > it does a lot less than [gemwin], which handles viewpoints, rendering,... > > short overview: > > starting with Gem-0.94 (that is: current git), [gemwin] is now an > abstraction (found in abstractions/). > internally it uses [gemdefaultwindow] to create/destroy/switch-to > windows/contexts, which is just another abstraction that wraps the > actual implementation (e.g. [gemglfw3window]), but you really need the > entire [gemwin] abstraction to use Gem as you used to. > > apart from separating platform-independent code (as found in the > [gemwin] abstraction) and platfrom-dependent code (the actual > [gem*window] backend), this also allows the user to change the > behaviour of [gemwin] without needing a compiler. > > conclusion: > add abstractions/ to your path, so you have a proper [gemwin]. > > fgmasdr > 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 > > > > > _______________________________________________ > GEM-dev mailing > [email protected]http://lists.puredata.info/listinfo/gem-dev > > > > _______________________________________________ > 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
