[GEM-dev] vertices...questions without answers

james tittle tigital at mac.com
Tue Nov 22 19:20:29 CET 2005

On Nov 22, 2005, at 12:04 PM, IOhannes m zmoelnig wrote:
> i am currently trying to re-do the vertex stuff in a manner that  
> everybody can live with.

...hurry up, it's becoming more outta date by the moment ;-)

> i think we agree on following (synching brains):



> i thought it would be very nice, to be able to "merge" 2 arrays of  
> different lengths, so there are "lsize" and "rsize".
> but when i converted the first code snippets, i just started to  
> wonder, whether this is a good idea?
> most likely SIMD-optimization (especially streaming extensions)  
> will be disabled with such feature turned on.

...this seems like a laudable endeavor, but IIRC we don't yet allow  
this flexibility with dual pix objects, so why include it for vertex  
arrays?  They're both arrays, right?

> so would it be better to just have a dedicated [vertex_resize]  
> object that does the extrapolation to bigger/smaller arrays  
> (however well this might work), and enforce the 2 arrays to be of  
> the same size??

...part of me thinks this should be necessary to enforce the user to  
understand that they are doing something unconventional, much the  
same as if we could do the same in mixing different sized pix's with  
a [pix_resize] (not that we CAN do that)...

> quite minor question, but i'd like to get some feedback.
> additionally, what do you think of it in general?

...in general it seems fine...I think that the main thing at this  
point is to ensure quick upload of data to the card and then just use  
gpu programming, but that won't really be the same until we get  
better offscreen rendering support for multiple pass rendering...

> it would be nice if the function would have to be coded only once  
> and the compiler/preprocessor would expand it to all eventualities.
> i would hate to use weird preprocessor magic.
> and the resulting code must be as fast as if it was written  
> explicitely.
> anybody has any ressources on this?

...beyond me!

More information about the GEM-dev mailing list