[GEM-dev] releasing GEM: tag "r0-888-pre"

[tigital]

On Sunday, September 14, 2003, at 10:28  PM, chris clepper wrote:

> i added help for the following
>
>> PIX's
>> pix_background
>> pix_blur
>> pix_chroma_key
>> pix_compare
>> pix_duotone
>> pix_mix
>> pix_motionblur
>> pix_roll
>> pix_scanline

...cool!

> i'm not sure what the following objects even do (or why they exist):
>
> pix_pix2sig~.pd or pix_pix2sig.pd?
> pix_rds
> pix_test - nothing?
> pix_emboss - looks like my old yuv_ object to try and make a fast 
> emboss, which failed
> pix_dot - does this work?

...pix_rds and dot are my ports from effectTV:  I've definitely gotta 
commit patches for the things I ported...I think emboss is just a copy 
of the older yuv_ object, so I don't know if it's worthwhile keeping?

>> ...also seems paramount that we make sure that all new functionality 
>> of gemwin, pix_texture, pix_film, etc is documented in the respective 
>> helpfiles...
>
> i think there might be a place for platform specific help for these. 
> for example, pix_video on OSX uses only the first 2 args to the 
> 'dimen' message and requires a 'reset' message to have the change 
> happen.  also, it supports colorspace switching and quality modes.
>
> At 5:45 PM +0200 9/11/03, IOhannes m zmoelnig wrote:
>> if anybody has any bugfixes ready, put them into this branch.
>> i think features are quite ok for a release.
>
> i had a run through the CVS and fixed up a few little things.  for the 
> most part it was minor
>
> - #ifdef MACOSX is now __APPLE__
> - added the PPC970 ifdefs
> - there are some more drawTypes for GemShape objects
> - yuv_ is pretty much fully removed
> - pix_filmDarwin does colorspace switching using 'colorspace yuv/rgb' 
> message and loads movs into RAM using 'ram'
> - pix_videoDarwin does colorspace switching like pix_film and can 
> resize using the 'dimen x y' message

...are these changes documented in the help files and such?  (just 
checkin') ;-)

...I also committed a new pix_texture, with a fix for power of 2 
textures that were missing the rectangle_texture AGP DMA (if available, 
they should get the same speed gain), plus the addition of 
texture_range (if available), which supposedly allows for better 
hinting as to AGP or VRAM texture uploading, and hence a speedup?  Not 
well profiled, yet...

> the following i haven't committed but would like to see about doing:
>
> - i have the alpha object set up to accept multiple blend modes for 
> both src and dest which is more flexible than the current 'function'
> - make sure all of the messages to pix_film/video are the same between 
> platforms and document which ones don't work on a given platform
> - sort out the conversion objects like pix_rgba and pix_yuv once and 
> for all
> - make a list of deprecated objects and remove them

...sounds good!  I'm still hoping to get this quaternion camera 
going...where'd all my time go?

l8r,
jamie