[GEM-dev] gemwin

Jack jack at rybn.org
Wed Aug 20 15:49:42 CEST 2014


Le 20/08/2014 15:25, Cyrille Henry a écrit :
>
>
> Le 20/08/2014 13:52, Jack a écrit :
>> 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].
> did you "make clean"?
> i'm surprised that you get the gemwin object.

It was with the old repository, i will try with the new one :
git://git.code.sf.net/p/pd-gem/gem <http://git.code.sf.net/p/pd-gem/gem>
++

Jack


> c
>
>>
>> ++
>>
>> 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
>>
>>
>>
>> _______________________________________________
>> 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/c54f9e6d/attachment.html>


More information about the GEM-dev mailing list