[PD] [GEM] Bug? and strange behaviour

[IOhannes zmoelnig]

Daniel Heckenberg wrote:
> Thanks IOhannes,
>
>>>Unfortunately there are some other peculiarities:
>>>b) the view position moves from the default to 0 0 0
>>
>>this i cannot reproduce, what does it mean ? when does it change ?> 
> The viewport shifts when the (double buffered) viewport is banged... I've
> attached a sample patch to demonstrate.

uh sorry.
my mail was misleading: i could reproduce the effect (obviously 
immediately after i wrote those lines)

>>i think, i will pull the behaviour of "bang" towards "render" rather
>>than "swap-buffers".

this would be the solution to this problem:
the call of the render-chain does all the viewpoint-transformations.
since "bang" bypasses this call (in double buffered mode) the view-point 
is set to openGL's default (0,0,0) and ignores the settings in Gem.


>>does this break anything ???
 >
> hmm.  not sure.  i'll leave that one to you ;-)

well, this question was rather meant for all those people out there 
using Gem (esp. Mark)

>>>d) the pixel or texture format seems to get confused... i'm
> I did try to use a [pix_rgba] to convert the data before I used [pix_data]
> to sample the pixels and it seemed to make no difference.  In fact, I've
> cooked up a little patch to demonstrate (either my lack of understanding, or
> some problem).
> 
>>From what I can see, the [pix_rgba] doesn't have any effect on the pixel
> values read by [pix_data].  The sample patch (which I'll send to IOhannes)
> has two [pix_data] objects: one before and one after the [pix_rgba].  They
> both return the triplet in the same order.

mine too, but in the right order.
i am under linux right now and cannot boot into windows to check your 
problem. the provided AVI definitely is in BGR-mode, the linux-movies 
are colour-transformed automatically by the decoder into RGB.


mfg.dsa.dr
IOhannes

> 
> Thanks again,
> Daniel
>