[GEM-dev] Offscreen naming poll!

[james tittle]

On Nov 30, 2005, at 12:22 PM, IOhannes m zmoelnig wrote:

> B. Bogart wrote:
>> gembuffer ?
>> gembuf? (gemwin)
>> james tittle wrote:
>>> name it, and where it should go in the folder hierarchy?   Currently
>>> it's named [gemframebuffer], but really I think  [gemoffscreen]  
>>> would be
>
> as you state correctly, the name [gembuffer] would be coherent  
> with  the name [gemwindow], so the functionality should be coherent  
> too. (imo, the same goes for [gemframebuffer] and [gemoffscreen].)
> i foresee nameclashes with the multiple_windows (whenever they will  
> come...)

...[gembuffer] or [gemoffscreen] I can see being used in  
multiple_windows as equivalents to [gemwindow]...using a specific  
name for either framebuffer or pbuffer seems silly because they  
basically do the same thing; the difference being that one is easier  
to do than the other...perhaps it should be [gem_render2texture]?

>>> ...also, on my harddrive I put it in src/controls (it would be   
>>> inserted
>>> into a gemchain after [gemhead]), but I guess it could also  go in
>>> src/manips, or even src/Nongeos?
>
> could it be an option to make an alternative(!) [gemhead] out of  
> this object?.
> so people could decide whether an entire gemchain is onscreen  
> ([gemhead]) or offscreen ([???]).
> if so, i would vote for something really clumsy like [gemhead_os]  
> ("clumsy" since i cannot think of a better name, not because the  
> object _should_ be named clumsy of course)

...hmm, hadn't thought about replacing the [gemhead]:  I'll look into  
it...IIRC, I did use [gemhead] as the template originally, so...

...the bigger question I'm wrestling with is how to use it best once  
it's available?  Somewhat the same problem with [pix_texture] and  
[pix_multitexture]...[pix_texture] and [gem_offscreen] both output a  
texture ID from their right outlet, ostensibly for use in a later  
render chain...currently I've used glwrappers to create the vertices  
to display these textureID's, but this only really works if you  
already know the texture size (and use TEXTURE_RECTANGLE) or if you  
use TEXTURE_2D and power of 2 dimensions...

...so, we currently don't have an object that displays a texture  
solely from a given texture ID:  it might be necessary to have the  
textureID outlets also output the texture dimensions in a list, and  
then there could be another object that accepts these and produces  
the correct texcoords and such for passing onto a geo...?

...or is there a way to do this already that I'm not seeing?

james