[PD-dev] [GEM] update

[zmoelnig at iem.at]

hi.

Zitiere chris clepper <cclepper at artic.edu>:
> Hi
> - new object [pix_motionblur] which is a revised version of pix_blur 
i have noticed this, great.

> quality.  this also frees up pix_blur so it can be changed to an 
> abstraction based on pix_convolve.
which reminds me, we have to make ánd abstraction-folder.

> - i have changed, but not committed, pix_texture so that the user can 
> switch between power of 2 and rectangle textures on the fly via a 
> 'mode' message.  one question i have is whether or not rectangle 
> textures actually work on linux or windows at the moment.  the tests 
rectangle textures work under linux if you have an nvidia-card, recent drivers 
and are compiling agains the GL-include files provided by nvidia.
but there is still some bug in the [pix_texture] object, which refuses to 
display rectangle-textures on nvidia-cards if they are not compiled against 
nvidia-sources.

> in pix_texture use GemMan::texture_rectangle_supported which works 
> fine on OSX but i'm not sure how that would affect the other 
> platforms.  let me know if this looks ok for linux/windows, i don't 
> want to break a critical object on another platform.
works great. (but of course, the underlying check for rectangle-support has to 
be adapted to meet (say) nvidia's extensions)
> 
> - i have pix_filmNEW playing in auto mode right now, but i have to 
great (thanks a lot!)
> agree with jamie's assessment that the new system really does nothing 
> at all for OSX.  
which might be true. however is there no chance that there might be other 
decoder-libs under mac some day ?

> it may solve some problems on linux, but it seems to 
it does ;-)
> actually have many of the same cross-platform issues; i've had to 
> ifdef some stuff in order to get it to even compile.  also, i don't 
> think the structure is very clean or transparent since the various 
> libs and APIs need to be taken care by platform. so doesn't it make 
> more sense to have each platform manage the libs/APIs internally 
> rather than do it in pix_filmNEW??
actually that was the idea.
maybe it is just really bad "design" what i have done.
i (hope that i) am free for any suggestions. (but of course don't want to break 
your work again)
> 
> 
> to maybe open up the communication a little bit, here are a few items 
> i'm working on, or plan to work, on in the near future:
> 
> - an object for loading pixel shaders from a file.  i only have an 
> ati 9000 right now so i can only do support for the ati extensions.
this really sounds cool

> 
> - some sort of object that will use glCopyTexImage2D to grab part of 
> the framebuffer and apply it directly to a texture.  this would be a 
> faster version of pix_snap and also enable some nifty feedback type 
> effects.
long on my todo list (since daniel talked about this) - but never had the time.

> - adding some sort of alpha info to the particle system for blending.
i thought the new libparticle already had alpha-support (the colors are now 
rgba instead of rgb)
so this might be solved already.

> - figure out a way to easily exchange info between pix, particles and 
> geos.  part_info is a good start for applying data generated by the 
> particle system to other elements in GEM, but what about using pix_ 
> data as a basis for the particle system?  or having the particle 
....
sounds great!

have a go (don't curse too often) ;-)
i'm looking forward to the next time i have access to the cvs.


mfg.as.r
IOhannes