On Nov 29, 2005, at 1:03 PM, B. Bogart wrote:
gembuffer ? gembuf? (gemwin)
does the buffer store pixels? or gemlist info?
...neither: this is a texture on the graphics card, so you can imagine it as tho it is an offscreen window that you never see unless you apply it to a primitive like any other texture...
manips makes sense I think, or a buffer folder?
...I tend toward control and manips: I don't think we need a whole new folder, because we should be able to roll in backward's compatibility via c++ magic...
I think the buffer calling should be like the pix_buffer stuff, where you have a name [symbol] that stands for that buffer. I've not started using the pix_buffer stuff yet, but I hope you can also use a "float" as the name for looping through the buffers...
...this is pretty different from pix_buffer, and works at a whole other level...however, this "named buffer" stuff is applicable to the eventual bigger idea of the multiple_window branch, where you'd be able to associate multiple chains to either offscreen or onscreen windows (or both?)...but this is kind of a first step that enables lotsa cool stuff NOW ;-)
I've not looked at multitexture yet... I need more time.. I'm already taking time off work to do all the PD stuff on my plate.
...multitexture was really part of a "trilogy" of related changes to bring GEM into the current "state of the art"...
l8r, james