[GEM-dev] framebuffer frustum

Matthias Neuenhofer neuenhofer at khm.de
Fri Feb 13 20:13:27 CET 2009


Am 13.02.2009 um 00:40 schrieb cyrille henry:
>
> Matthias Neuenhofer a écrit :
>> super
>> i compiled on Mac Osx 10.5.6.
>> there was no OS specific part in, should also work on Microsoft.
>> but shouldn´t the default texture out to rectangle?
> why?
> anyway, changing default could break old patch, so it's usually bad.
ok leave it,  gemframebuffer needs initial values anyway like size ....
even pix_texture use rectangle from default
>
>
>> my attention to the framebuffer was a side effect looking
>> for a way to sort the render order for proper keying and
>> discovered [gemreceive] - thanx IOhannes - which
>> support the [set $1( to sort the chain with z values via  
>> [gemlist_info]
>> it´s not perfect - always 1 frame to late - looks ok.
> gemhead does also accept ordering. (via set message)
yop but i like to go with a feedback via pix_snap in background
and this snaps only which belongs to the headtree - i know
snap2tex is faster but i couldn´t get it in to pix_record so in this
set the gemreceive was perfect
>
>
>> but - is a gemhead which sort all clients by himself thinkable?
> i can't imagine a generic solution
maybe later
>
>> a mapping from the z position multiplied with 1000 to the priority
>> before it´s drawn in the framebuffer.
> you can do this by hand, in a 2 pass rendering : render a 1st time  
> only to know the Z, then use it to change priority of the gemhead  
> for the final rendering.
and the performance will stay acceptable ?
>> Matthias
>> Am 12.02.2009 um 14:14 schrieb cyrille henry:




More information about the GEM-dev mailing list