[GEM-dev] CVS: checkins and notifications

James Tittle II tigital at mac.com
Wed Aug 18 02:57:02 CEST 2004


On Aug 17, 2004, at 10:08 AM, IOhannes m zmoelnig wrote:
>
> 1x) *stupidity*: while branching seems simple, i have experienced that 
> it is a bit beyond my reach. i have done a lot of really stupid 
> things, namely:

...this is what I'm afraid of:  many different versions going out in 
different directions, each with some small "stupidity" mistake, making 
for a fool's errand to find out if it's even worthwhile...

> however, i apologize for my stupidity and hopefully will think before 
> acting in the future.

...I'm sure we're all going to make mistakes for awhile...

> 1a) "SIMD":
> 	i have tested it under linux and windows and it works (although i am 
> a bit disapointed of the performance-gain; unfortunately i have no 
> SSE2 machine at hand so i haven't tried this yet); however, i have not 
> tried to compile it under osX yet.
> the SIMD-functions are named uniformly for all subclasses of GemPixObj 
> (and GemDualObj) and are called automatically if present.

...why would you try to compile it under OSX?  Are you writing altivec? 
  What is it a branch of?

> 1b) "multiple_window": (there is also a TAG with this name, so beware!)
> 	this separates the functionality of [gemwin] (which has vanished) 
> into 2 objects [gemcontrol] and [gemwindow], where [gemcontrol] is the 
> interface to the rendering-engine (GemMan) and [gemwindow] handles the 
> window-management. a lot of code has moved from GemMan to gemwindow;
> there is a new directory src/Output for alternative output-modules. 
> currently it only holds [gemextwin] which can be used to replace 
> [gemwindow] to render into an externally created window (this really 
> works: http://iem.at/~zmoelnig/GEM/plugin/ ); currently this object 
> compiles under windows & linux but is working only under linux.
> multiple output-modules can be connected to a [gemcontrol].
> there are still a *lot* of problems, so i guess it is not ready for 
> testing.

...this sounds vaguely interesting, but I have no way of testing 
against multiple video cards (I just have a laptop)...again, what is 
this a branch off of?  Does it seem to have conflicts with the vertex 
array stuff?  I'm also working on changing rendering in GemMan, but my 
solution is not necessarily just to move it to a new object...

> #---------------
> 2)
> new directories:
>
> apart from the Gem/src/Output directory i have also created the long 
> awaited Gem/abstractions directory. currently it is empty (it holds a 
> [gemwin]-replacement in the multiple_window branch) and waits to be 
> populated

...have no idea what an /src/Output directory would be good 
for...abstraction, yeh!  Ben's stuff should definitely be first 
candidate for there...

> #---------------
> 3)
> i have just created a  mailinglist pd-gem-cvs at lists.sourceforge.net 
> for email-notifications on CVS-changes (like the pd-cvs list); it will 
> take some hours until it is online
> i have received email-notification on the CVS-changes for some time 
> and probably someone else is interested too.

...are we going to be auto-subscribed like last time?  I'm interested 
in staying abreast of commits...

...so, sorry if I sound grumpy, but this is quickly getting outta hand, 
like subscribing to too many mailing lists:  how are we supposed to 
manage this?  Check out multiple copies of Gem, each with it's own 
branch/tag/whatever?

...my goals are simple:  try to bring Gem up to OpenGL 1.5 (1.3 would 
be a good start)...atm, unfortunately, I'm still working in the 
underlying drawing code for Tk on OSX...but hopefully will move on to 
multitexturing and other things soon...

jamie





More information about the GEM-dev mailing list