hi GEMers !
last night i have updated some files in the Gem-CVS and had no time for sending out a mail ... sorry, here it goes:
1. [pix_film]/[pix_movie] under linux: has no support for libavifile. i have only tried to compile it vs. libavifile0.7 (i guess). this should enable reading of many video-files, but i haven't had that much luck. it kept crashing when i tried to load the anim-1.mov file, and it still has some serious troubles with image-formats. also i don't have any idea, how to make libavifile use codecs from windows-dll's, anyone ? libavi is no real news, since it is in CVS for approx one week. but i might have forgotten to tell. anyhow it is still very much unstable.
2. fonts you can now choose to compile Gem without font-support (under linux with "./configure --without-gltt") there is a "USE_FONTS" define in Base/TextBase.h which should disable all the font-specific stuff in text2d.cpp ...
3. [separator] hopefully i have fixed the bug that kept it crashing when it was used with images.
4.[pix_buf] hopefully fixed the bug that kept it crashing when it was used with images. [pix_buf] will store image-data into a separate buffer. all pix_ objects below [pix_buf] will have access to the buffered data instead of the original one. thus you can split the image-processing chain and will not have the chains effect each other ([separator] does this for openGL-stuff) normally [pix_buf] updates its buffer, whenever a new image comes in. you can now force an update by sending it a |bang(. (there was a request for this once, because you had to reload a static image if you wanted an effect to take place, when you changed parameters.) you can also send it an |auto 1/0( message, which enables forced buffering each render-cycle. This is probably a not so good idea, because it might be quite CPU-intensive.
5. [pix_crop] i thought i had checked this in long ago (but obviously had not, and now i have found the original code again) it takes sub-images of images (withan offset x/y pair and a dimen w/h pair)
6. what else ? a minor configure-script update + "cannot remember"
mfg.a.dr IOhannes
Following up on this, I have checked in the changes that I proposed for the "Gemlibs".
glm.c is now in Geos/model_loader.cpp
the particle stuff is in Particle/partlib_***.cpp
I changed the configure script accordingly. The only GemLibs part thats left is the orb stuff.
Greetings,
Guenter
hi GEMers !
last night i have updated some files in the Gem-CVS and had no time for sending out a mail ... sorry, here it goes:
<snip>
- [separator]
hopefully i have fixed the bug that kept it crashing when it was used with images.
as you note in the source, there is now a memory leak in the separator object. i have yet to figure out what the problem is, but calling free on that pointer should cause a warning not a crash (it doesn't segfault on OSX). maybe a linux bug??
4.[pix_buf] hopefully fixed the bug that kept it crashing when it was used with images. [pix_buf] will store image-data into a separate buffer. all pix_ objects below [pix_buf] will have access to the buffered data instead of the original one.
- [pix_crop]
i thought i had checked this in long ago (but obviously had not, and now i have found the original code again) it takes sub-images of images (withan offset x/y pair and a dimen w/h pair)
i was thinking of making an object that combined both of these functions so one could 'cut up' and image and process each part differently. maybe it would be called [pix_split] or [pix_cut(up)] or [pix_slice]? basically the user would send messages selecting the area to output and a for loop would move the pixels around. it would be nice to have N number of outlets for this object, but i'm not sure how possible that it with GEM.
i have also written a mode of processing called processSubImage() that only processes a user specified area of the image. it's probably not practical to add this to each and every object so maybe [pix_split] is a better way to go....
- what else ?
a minor configure-script update
- "cannot remember"
there were some updates to GemBase with the ultra-informative log entry of '???'. what happened there?
cgc
Hey Devs
From Coder's POV pix_buf may be more accurate, but I think pix_separator makes more sense from the user perspective.
B.
On Friday, March 7, 2003, at 02:28 PM, chris clepper wrote:
hi GEMers !
last night i have updated some files in the Gem-CVS and had no time for sending out a mail ... sorry, here it goes:
<snip>
- [separator]
hopefully i have fixed the bug that kept it crashing when it was used with images.
as you note in the source, there is now a memory leak in the separator object. i have yet to figure out what the problem is, but calling free on that pointer should cause a warning not a crash (it doesn't segfault on OSX). maybe a linux bug??
4.[pix_buf] hopefully fixed the bug that kept it crashing when it was used with images. [pix_buf] will store image-data into a separate buffer. all pix_ objects below [pix_buf] will have access to the buffered data instead of the original one.
- [pix_crop]
i thought i had checked this in long ago (but obviously had not, and now i have found the original code again) it takes sub-images of images (withan offset x/y pair and a dimen w/h pair)
i was thinking of making an object that combined both of these functions so one could 'cut up' and image and process each part differently. maybe it would be called [pix_split] or [pix_cut(up)] or [pix_slice]? basically the user would send messages selecting the area to output and a for loop would move the pixels around. it would be nice to have N number of outlets for this object, but i'm not sure how possible that it with GEM.
i have also written a mode of processing called processSubImage() that only processes a user specified area of the image. it's probably not practical to add this to each and every object so maybe [pix_split] is a better way to go....
- what else ?
a minor configure-script update
- "cannot remember"
there were some updates to GemBase with the ultra-informative log entry of '???'. what happened there?
cgc
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
chris clepper wrote:
- [separator]
hopefully i have fixed the bug that kept it crashing when it was used with images.
as you note in the source, there is now a memory leak in the separator object. i have yet to figure out what the problem is, but calling free
me too...
on that pointer should cause a warning not a crash (it doesn't segfault on OSX). maybe a linux bug??
i'd hate to admit this. but anyhow, it crashed on windows too, so maybe it's a win/lin-bug. the memory leak should of course not be considered final.
- [pix_crop]
i thought i had checked this in long ago (but obviously had not, and now i have found the original code again) it takes sub-images of images (withan offset x/y pair and a dimen w/h pair)
i was thinking of making an object that combined both of these functions so one could 'cut up' and image and process each part differently. maybe it would be called [pix_split] or [pix_cut(up)] or [pix_slice]?
well, [pix_crop] (i took the name someone suggested on the list), does buffering of the subimage anyhow. So you already have the functionality you need.
basically the user would send messages selecting the area to output and a for loop would move the pixels around. it would be nice to have N number of outlets for this object, but i'm not sure how possible that it with GEM.
this is possible, but you have to duplicate chunks of the GemBase-class.
i have also written a mode of processing called processSubImage() that only processes a user specified area of the image. it's probably not practical to add this to each and every object so maybe [pix_split] is a better way to go....
when applying more than one effect to subimages, processSubImage() might not even be faster. but of course, you could do beautiful things. Even more beautiful things could be done if we had a separate "selection channel" (i disused the alpha-channel for this purpose in [pix_a_2grey]) But of course, this is going to be very slow.
Anyhow, now we have a secondary colour model that does not support alpha, we probably should change the iamgeStruct to support such selection channel.
- what else ?
a minor configure-script update
- "cannot remember"
there were some updates to GemBase with the ultra-informative log entry of '???'. what happened there?
well, i guess, '???' means: "cannot remember" now that i have looked at GemBase.* again, i'm quite sure that i just had a look at the code, accidentally hit a key, saved the file and commited it as "modified".
mfg.a.sdr IOhannes
-
bbogart -
chris clepper -
guenter geiger -
IOhannes zmoelnig