[PD-dev] [GEM] cvs ci *.cpp *.h

[chris clepper]

>hi.
>
>a few commits i made to the gem-cvs (and probably a lot i have 
>commited but haven't kept in mind)
>i tried to comment all of them (and it was very tiresome...)
>
>Pixes:
>1.
>merged [pix_texture] and [pix_texture2] again.
>still the old pix_texture2.cpp is not deleted (but [pix_texture] 
>already adds an alias to [pix_texture2])
>i have added the rectangle-texturing for nvidia-cards.
>however, it might work or not on other machines than mine.
>please ! do test it.
>also i think i have fixed a bug, that crashed [pix_texture] when no 
>image was present.

this seems to work with pix_filmYUv but not pix_film for me.  maybe 
something is broken for pix_film?  i'm still using the old pix_film 
stuff since i had trouble loading the new one due to some undefined 
symbol errors.

>2.
>pix_video (under linux):
>now has a message for setting the colour-space (like [color grey( or 
>[color RGBA()
>apropos:
>chris said something about openGL not liking to swap colour-spaces 
>on the fly. i think this was a bug in [pix_texture] (i think). the 
>base-texture has to be the same colour-space as the sub-texture.
>after i had changed this, i could switch between colour-spaces.

i'll try adding a message to switch color spaces between loading 
movies.  that would be a nice feature to have.

>(but unfortunately the yuv422 provided by the video4linux-drivers 
>seem to be something different to what an nvidia-card expects as 
>yuv422-texture)

there are a few types of 4:2:2 formats out there so that's not too 
surprising.  we use 2vuy in GEM, but maybe the card wants yuv2?  i 
initially wrote all of the yuv stuff on a Geforce4MX card so i can't 
imagine that the hardware support for the textures would be different 
on a Mac vs Linux or Windows.  I guess the drivers could be changing 
the order of the pixels, but why??

>
>Particles:
>1.
>the long awaited [part_render] (couldn't think of a better name) !
>everything that is below the [part_render] will be used as a basic 
>particle (like textured models (ok, this might be a little bit 
>exhaustive))

this is really nice.  i have changed the demo patch to include a 
pix_filmYUV and pix_texture and it workds really great even with DV! 
very little extra CPU load for 5 generated particles and a killold of 
10 to 20.  make your own particles is the way to go.

>2.
>[part_info] is similar to [part_render] but doesn't actually 
>transform a render-list but rather provides all particle-properties 
>as lists.

this is great too.  so dead simple i couldn't believe it.  now the 
thing i want to add is doing some sort of alpha blending and color 
fading on the particles as they 'age'.  so instead of just 
disappearing when they die they fade to black.  i have tried to do 
this using the position output and the 4th arg to [color] but it's 
not very effective.  the particle lib doesn't seem to do much with 
alpha channels that i've found so maybe this has to be added in.

>1+2.
>there are 2 demo-patches in particle
>i hope, this will make the particle-system finally "useful" 
>(personally i didn't like the dot/line particles)

yeah this is an improvement, a big one.  thanks.

cgc

>the rest i cannot remember...
>
>mfg.as.d
>IOhannes
>
>