[GEM-dev] gemwin

[Cyrille Henry]

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 ;)
As antoine point out, this is a known bug when rendering is not enable that i was not aware.
but with this example it crash also if the gemwindow was created. This is specific to this example.

>
>>
>  > - 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(.
that's why RGBA32 was created

> 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 ?
>
all glsl path are old and should be clenaned a bit.
but on some nvidia, i had problem with RGBA32, so RGBA32 is not a drop in replacement for RGB32.
as Iohannes suggested, it would be nice if Gem can choose the correct format to use, but RGBA32 is the only one that is 32 bit and 4 channels. so i guess there is noting to replace it when not available.

>> - 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.
yes that's was i wanted to say (gem_state 1 and not only 1)
> On my side, i only use [loadbang] to load vertex/geometry/fragment shaders.
yes, this habit came from a time when shaders had to be load after windows creation. it is no longer needed.
but this trick is also use at some other place. ( in _gemlist abstraction by example)

c

>
>> - 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
>