[PD] [GEM] Bug? and strange behaviour

[Daniel Heckenberg]

Hi,

I've been playing around with GEM for the past couple of days and must say
that I'm very impressed!  Great work to all involved.  System notes: windows
2000 SP2, PIII, DX 8.1, nVidia Geforce2Go.

I have, however, come across a couple of things that seem to be a little
strange:

1) Trying to use DV codec compressed AVIs causes PD to crash.  Through the
wonders of open source, I've tracked this problem down to a NULL return from
AVIStreamGetFrameOpen(m_streamVid,NULL) in pix_filmNT :: realOpen() from
pix_filmNT.cpp

This suggests that the AVI/Video For Windows system can't find an
appropriate decompressor on my system.  However, the same clips play just
fine with Media player or other apps on the system.  I have no problems in
GEM using cinepak or a couple of other codecs that I've tried.

Can anyone/everyone reproduce this behaviour, or is it specific to my
system?

2) I'm trying to do some algorithmic gem list generation.
I want to have smooth animation, so I need double buffering.

A simple example of the kind of algorithm that I'm using is the generation
of an array of a particular object.  This is easy and elegant to do
algorithmically, but would require a rat's nest of patching to do
statically.

However I've encountered a number of problems:
a) can't turn off the automatic render cycle when double buffering is
enabled

This I've worked around by setting the frame rate to 0.0001 and then banging
the gemlist heads with a metro, and banging the gemwin to trigger the flip.

Unfortunately there are some other peculiarities:
b) the view position moves from the default to 0 0 0
c) it is not possible to change the viewing position (As far as i can tell)
using the view message to the gemwin at any stage of the render/flip cycle
d) the pixel or texture format seems to get confused... i'm using pix_data
to pull colours to give to my objects and i need to reverse the order of the
triple in order to get the right colours to appear.

It seems that I'm not using GEM in the way it may have been intended, but I
think it would be very useful (and I imagine not difficult) to have the
system support this kind of thing.  I suspect it's just a matter of
rearranging the rendering code a little but I've not yet delved that far
into the code.

Daniel