[GEM-dev] gemwin

[Jack]

Just try with Gem from git://pd-gem.git.sourceforge.net/gitroot/pd-gem/Gem.

[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
> >> GEM-dev at lists.iem.at
> >> http://lists.puredata.info/listinfo/gem-dev
> >>
> >
> > _______________________________________________
> > GEM-dev mailing list
> > GEM-dev at lists.iem.at
> > http://lists.puredata.info/listinfo/gem-dev
>
>
>
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at lists.iem.at
> http://lists.puredata.info/listinfo/gem-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20140820/e94f23f9/attachment.html>