Hi Chris,
This is true that I could "load" a black pixel texture to make black, and I'll probably do that, but really I'm talking about being able to have a kind of default colour for a texture that has not yet been set, white is great for debugging and seeing what is going on, but it would be nice to be able to set it for slots in the depot that have not yet been saved. I could also make the uncaptured slots transparent, but I think these are more workaround.
Yes, Johannes reminded me of "open" which scratches that one of the list. Please add it to the CVS help-patch! :) (or wait to my second email)
As for loading and saving images I do not know of a way of doing this without interfering with the gemwindow. That is I want to save something that is in the pix_buffer memory, but is not visible on the screen... I'd love to know how to do this at the patch level, please let me know.
As for pix_write I was not thinking of writing the gemlist itself, but rather doing a "normal" pix_write capture of the whole screen, except only including one gemlist (the one its conatined in). I could also do this with setting my gemlist render priorities carefully, but I have something like 10x60 gemlists so Its not likely to happen that way for this project. Actually now that I think about it, its more or less a workaround for the ability to save something in the buffer, but having to mess with putting the image I want to save in the gemwindow first, which is not possible in most cases.
More or less pix_write is a misleading name, since it should only save the texture and not the whole buffer... I can't think of another pix_ object that does not deal with textures...
I have not tried pix_record, sounds really amazing.
Ok, onto Johannes's email.
.b.
chris clepper wrote:
While I think some of these are good ideas relating to pix_buffer, none of them strike me as something which can only be done on the C code level or would pose some great advantage by doing it there - the possbile exception might be the clearing code. Loading and saving images can be done on the patching level using existing objects.
I have no idea what you would do with a gemlist written to a file. It doesn't strike me as something that would be useful for later apart from possibly debugging. What is your reasoning behind this request?
cgc
On 2/22/06, *B. Bogart* <ben@ekran.org mailto:ben@ekran.org> wrote:
Hey all, So I've been working a lot with the pix_buffer (depot) stuff and had a few ideas that would make using it even more useful: * The ability to colour the buffer black, effectively clearing it without deallocating memory. * The ability to load and save the images in a buffer, basically being able to take a snapshot of the system so that the same images that were in the buffers can be reloaded, restoring the original state. * It would be also nice to be able to save a particular frame rather than the whole buffer. "load [filename]" to pix_buffer_read could load the [filename] into the slot already set by the pix_buffer_read index. "load [wildcard] 10" would load 10 images matching the wildcard pattern into 10 slots (reallocate if needed?) "save [filename]" to pix_buffer_write would save the image in the current slot to that filename. "save [filename] 10" could save images from the first 10 slots to filename with an id appended: "file0000", "file0001" etc.. "clear 10" or "clear" to pix_write would clear the first 10 slots, or the current slot respectively. "black" may work instead of the word "clear". Oh and It would be amazing if you could put pix_write in a gemchain and have it only capture that gemlist in the buffer... or maybe the current pix_write should be called something like window_write since it does not actually save what is happening in the pix_ of a chain... Thanks! .b. _______________________________________________ GEM-dev mailing list GEM-dev@iem.at <mailto:GEM-dev@iem.at> http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev