[GEM-dev] pix_buffer* & pix_write

B. Bogart ben at ekran.org
Thu Feb 23 16:17:15 CET 2006


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 at ekran.org <mailto:ben at 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 at iem.at <mailto:GEM-dev at iem.at>
>     http://lists.puredata.info/listinfo/gem-dev
>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20060223/2e924024/attachment.pgp>


More information about the GEM-dev mailing list