in order to get into releasing (finally), i have branched the Gemsources in the Cvs with the tag "r0-888-pre"
if anybody has any bugfixes ready, put them into this branch. i think features are quite ok for a release.
windows: could pix_videoDS could be made the standard (alias to [pix_video]; the only important thing would be to add support for all messages that are understood by [pix_video] right now.
mfg.as.r IOhannes
ps: added some very minor changes to the cvs (like uncommenting the debug.messages in pix_texture)
On Thursday, September 11, 2003, at 11:45 AM, IOhannes m zmoelnig wrote:
in order to get into releasing (finally), i have branched the Gemsources in the Cvs with the tag "r0-888-pre"
if anybody has any bugfixes ready, put them into this branch. i think features are quite ok for a release.
windows: could pix_videoDS could be made the standard (alias to [pix_video]; the only important thing would be to add support for all messages that are understood by [pix_video] right now.
...I think we still need to do this with pix_videoDarwin, too...
...I've made a few updates to code, but unfortunately am running at only 28Kbs(stupid phone lines!?!) for the near future, so I'll try to get them up ASAP: they mostly have to do with power of two textures on OSX (weren't taking advantage of AGP texturing) and addition of texture_range extension (supposedly necessary for fully realizing AGP texturing speedup)...
...Also curious about supposed incompatibility of pix_kaleidascope and linux builds: has anyone else tested this? The code was supposed to be very cross-platform, so I'd like to understand what went wrong and where...
...In any event, I hope that there won't be quite so long of space between this release and the next one...
l8r, jamie
On Thursday, September 11, 2003, at 11:45 AM, IOhannes m zmoelnig wrote:
in order to get into releasing (finally), i have branched the Gemsources in the Cvs with the tag "r0-888-pre"
if anybody has any bugfixes ready, put them into this branch. i think features are quite ok for a release.
...coupla more questions:
- I'm not that familiar with cvs tag/branching, and I don't think this can be selected from within project builder on OSX: notoriously bad cvs support :-( - IIRC, pix_depot and pix_buffer are the same? Yet pix_depot is still around? Same thing with pix_texture/pix_texture2, and others: shouldn't we remove objects from the compile that are aliased elsewhere? - I really don't think we should release until there are help patches for all objects...here's a list I made of orphaned objects, and I'll try to knock out more this weekend: GEOS cuboid newWave ripple rubber slideSquares
MANIPS polygon_smooth
MARKEX abs m_control? multiselect? reson? strcat?
PARTICLES part_info part_render part_vector?
PIX's pix_background pix_backlight pix_blur pix_buffer (read/write?) pix_chroma_key pix_color pix_colorreduce pix_compare pix_convert pix_crop pix_delay pix_depot (get/put?) pix_dot pix_duotone pix_dv pix_emboss pix_grey pix_info pix_levels pix_lumaoffset pix_mix pix_motionblur pix_pix2sig~.pd or pix_pix2sig.pd? pix_posterize pix_rds pix_roll pix_scanline pix_sig2pix~.pd or pix_sig2pix.pd? pix_snap2tex pix_test pix_tIIR pix_yuv
...also seems paramount that we make sure that all new functionality of gemwin, pix_texture, pix_film, etc is documented in the respective helpfiles...
l8r, jamie
hmmm is pix_blur the same as pix_motionblur?
If you need a hand with the helpfiles I'd like to help out. I guess you could split off the list for me. How recent a checkout should I use? I think the one I'm on is a couple weeks old.
I think my gem source reading ability would be sufficient to the task.
Ben
On Thursday, September 11, 2003, at 11:45 AM, IOhannes m zmoelnig wrote:
in order to get into releasing (finally), i have branched the Gemsources in the Cvs with the tag "r0-888-pre"
if anybody has any bugfixes ready, put them into this branch. i think features are quite ok for a release.
...coupla more questions:
- I'm not that familiar with cvs tag/branching, and I don't think this
can be selected from within project builder on OSX: notoriously bad cvs support :-(
- IIRC, pix_depot and pix_buffer are the same? Yet pix_depot is still
around? Same thing with pix_texture/pix_texture2, and others: shouldn't we remove objects from the compile that are aliased elsewhere?
- I really don't think we should release until there are help patches
for all objects...here's a list I made of orphaned objects, and I'll try to knock out more this weekend: GEOS cuboid newWave ripple rubber slideSquares
MANIPS polygon_smooth
MARKEX abs m_control? multiselect? reson? strcat?
PARTICLES part_info part_render part_vector?
PIX's pix_background pix_backlight pix_blur pix_buffer (read/write?) pix_chroma_key pix_color pix_colorreduce pix_compare pix_convert pix_crop pix_delay pix_depot (get/put?) pix_dot pix_duotone pix_dv pix_emboss pix_grey pix_info pix_levels pix_lumaoffset pix_mix pix_motionblur pix_pix2sig~.pd or pix_pix2sig.pd? pix_posterize pix_rds pix_roll pix_scanline pix_sig2pix~.pd or pix_sig2pix.pd? pix_snap2tex pix_test pix_tIIR pix_yuv
...also seems paramount that we make sure that all new functionality of gemwin, pix_texture, pix_film, etc is documented in the respective helpfiles...
l8r, jamie
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
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
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?
...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
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
cgc
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
tigital wrote:
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 have been ill the last days and thus have done a lot of documentation. somebody has noted a while ago: great minds tend to think alike ;-) i have integrated yours into mine and committed them but will commit mine for quite all the rest (still missing and NOT on my TODO-list are: pix_convert pix_dv pix_emboss pix_depot pix_get pix_put pix_movieYUV pix_test
some of them might be in my local copy only ;-) )
i'm not sure what the following objects even do (or why they exist):
pix_pix2sig~.pd or pix_pix2sig.pd?
well, the object should be named [pix_pix2sig~] (which is in fact an alias for [pix_pix2sig]). it is the inverse of [pix_sig2pix~] (which is documented neately now) and btw is a very cool object (in my opinion)
pix_test - nothing?
really nothing, it is just somthing to test. have i committed it to the cvs ?
pix_emboss - looks like my old yuv_ object to try and make a fast
it is. i consider it not functional and have not documented it.
pix_rds pix_dot - does this work?
i have also made changes to the srces:
one of my major issues is to get rid of values between 0 and 255. this range exists for purely technical reasons. In Gem all these ranges (eg: colors) have been handled as floats (0..1) for a long time. This (the history of Gem) is the only reason why i think we should try to make all limited ranges go from 0.0 to 1.0. and i think it is nice to have only one range to remember.... and now the big: SO::
[pix_duotone], [pix_posterize], [pix_backlight], [pix_mix] now all work with values between 0..1. this will surely break some patches :-( most of the controls for these objects had to be commited via a message to the first inlet. i have made additional inlets for the controls. this would have made it easy to give different names to (the old) uchar- and to (new) normalized values, but unfortunately i have thought of this very lately. i think one of the objects features this, but the others will break things.
[pix_chroma_key]: changed the default to m_processOnOff=1. it is very disturbing if some of the pix_fx have to be turned on, while others work as soon as they are connected. we cannot change the default behaviour for all pix_fx to not do anything before they are explicitly turned on (because it would break all(!) patches with pix'es) and i don't think that it is good to have some turned on and some turned off.
[pix_compare]: m_processOnOff=1 (see above). additionally i have changed the behaviour to compare luminances rather than the rgb-channels separately. this should make it more compatible to the YUVprocessing.
some YUV/Gray support for [pix_]-objects Geos: [rubber]/[ripple]: both have now arguments that allows to specify the number of segments of the grid. i haven't yet changed it, but i would prefer the ctrX and ctrY value be rather normalized. What should the sizeMess do exactly ? Right now it does nothing. Should we remove it or just put a glScale inside the object (but this could be done outside too) i have made at least the "height" message do something intelligent.
i have no idea what the inletFov is for at [ripple]
[newWave]: added some sense to the heightMess
On Wednesday, September 17, 2003, at 09:30 AM, IOhannes m zmoelnig wrote:
tigital wrote:
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 have been ill the last days and thus have done a lot of documentation. somebody has noted a while ago: great minds tend to think alike ;-) i have integrated yours into mine and committed them but will commit mine for quite all the rest (still missing and NOT on my TODO-list are: pix_convert pix_dv pix_emboss pix_depot pix_get pix_put pix_movieYUV pix_test
some of them might be in my local copy only ;-)
hey Iohannes,
...well, you've been quite busy! I'm still going thru a bunch of the changes, but just wanted to say "great job" on some of the help patches: the gop and color blocks make for a wholly different impression...now to move that kinda design into all the other patches :-)
i have also made changes to the srces:
one of my major issues is to get rid of values between 0 and 255. this range exists for purely technical reasons. In Gem all these ranges (eg: colors) have been handled as floats (0..1) for a long time. This (the history of Gem) is the only reason why i think we should try to make all limited ranges go from 0.0 to 1.0. and i think it is nice to have only one range to remember.... and now the big: SO::
...um, after working on GEM for just over a year, why have I never heard this design philosophy? It makes sense, but it's awful bad form to just up and say "everything should be done this other way"...
...anyway, I've been doing some committing myself the last few days, and will post about them asap...also been using cvs2cl, and am going to add a nice ChangeLog to the project...much easier to deal with...
soon, jamie
-
ben＠ekran.org -
chris clepper -
IOhannes m zmoelnig -
tigital