[GEM-dev] vertex operations / vertex_* (prev.. gem port to opengl-es - initial developments..)

dmotd inaudible at simplesuperlativ.es
Sat Feb 4 17:23:05 CET 2012


On Fri, 2012-02-03 at 17:04 +0100, IOhannes zmölnig wrote:
> On 02/03/2012 01:53 PM, dmotd wrote:
> > 
> > is the Vertex code obsolete? there's a lot of references to
> > apple/altivec which suggests that it was designed for a certain
> 
> i don't think there was a release ever that included the [vertex_*]
> objectfamily.
> as you guessed, they were developped mainly (almost: exclusively) by our
> apple faction (chris & jamie), and have not been touched for years.

okay, i think i'm up to speed, been reading through mailing list logs
and browsing the code, so i have a better understanding of the
intentions of cgc and tigital with their vertex experiments.. 

it makes sense to resurrect some of vertex_* code and clean it up,
although i'm a little hesitant about working with it directly as it has
a pretty limited scope and the structure is a bit loose and abstracted.
i also don't want to break anyones patches who might still be using
their code, or require it for running legacy work.

perhaps a good compromise is to create a separate set of lower level
vertex objects and in future wrap the vertex_* code in abstractions or a
general purpose vertex class?

is the vtx_ prefix available, a quick scan suggests so? if so i'll start
naming new vertex related objects thus to differentiate (and it matches
nicely to the three letter shortening of pix).

in related news, i now have a simple vertex-array triangle interacting
with gem manips and i can confirm that 'view' and 'perspec' messages to
the gemwin are operational. good fun!

i'm currently thinking the best way to replace basic geos is to wrap a
vtx_array/draw procedure in a pd abstraction instead of hard coded
objects. the abstractions could be included using autotools when a
combination of --disable-Geos and --enbable-Vertex are set. any thoughts
or am i being short sighted?

cheers!
dmotd

ps.. i'll cleanup the code tomorrow or monday and push to github. still
haven't tested a qemu environment either, but both tasks should be good
motivation for the other.




More information about the GEM-dev mailing list