[GEM-dev] multiples gemhead for a framebuffer
IOhannes m zmoelnig
zmoelnig at iem.at
Mon Sep 15 15:21:22 CEST 2008
cyrille henry wrote:
>
> IOhannes m zmoelnig a écrit :
>> cyrille henry wrote:
>>> hello,
>>> thanks for the answer,
>>>
>>> that would be great i think, but is this a plan or a work in progress?
>> well, the patch i sent should actually work (with a recent Gem that
>> already has [gemreceive]), so it is already "work in progress".
> ok, cool.
> look like my 2 month old Gem was to old!
> i update / recompile and yes, this patch is working.
>
> trying to understand the use of gemreceive, i realized that replacing it with a simple receive did work.
> look like gemreceive is a receive with priority, is it true?
exactly.
it really has nothing to do with Gem per se, but as it is not in
Pd-vanilla and would be needed i added it.
>
> This mean that even with older Gem version it is possible to render multiple gemhead in the same frambuffer using something similar to your example...
oh yes. it was just a matter of show off (and of course i didn't know
whether you needed a certain render-order, which is impossible to do
with pure [receive]s)
>> ([gemhead] should be an abstraction with a [gemreceive] and some
>> "gemreset" object(s))
> the gemreset objets does not exist yet (?).
correct
> should/could it be made with GEMgl objects?
part of it could be done with GEMgl; other parts will need access to the
gem_list structure (and thus have to be done in C++)
>
>> - a [gemwin] abstraction should do the [send] and setup the viewpoint
>> and the like (rather than code hidden within GemMan)
> ok
> same question : should/could it be made with GEMgl objects?
yes, i think most of it can be done with GEMgl.
>>>
>> it is related to that.
>> though the "is in development" hurts a bit :-)
> oups, sorry, did not wanted to hurt.
well, it was just a reminder of something that should have been done for
ages.
sometimes it is good to be kicked (very lightly)
gfmasdr
IOhannes
More information about the GEM-dev
mailing list