James Tittle II wrote:
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...
...I'm sure we're all going to make mistakes for awhile...
absolutely. but what i can i do know ? the biggest problem with me using the CVS is, that i need it not only for sharing code with other people (e.g.: you) but also to have a code-base that i can work on from several machines under several operating systems both at work and at home. this is why i tend to check in things that are not running at all.
1a) "SIMD": i have tested it under linux and windows and it works (although i SSE2 machine at hand so i haven't tried this yet); however, i have not tried to compile it under osX yet.
...why would you try to compile it under OSX? Are you writing altivec?
no i am not writing altivec. however, the altivec functions were not named uniformly and me (in my "facist" way of thinking) have just changed this. and i have thought that each and every change to the code-base - no matter how well tested on one platform - *might* break compilation on another system.
What is it a branch of?
v0.90 (if this answers your question) for now i have branched (at least) the whole Gem/src folder.
1b) "multiple_window": (there is also a TAG with this name, so beware!)
...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?
again v0.90; everything is branched
the point is not necessarily about having multiple video-cards in one machine. i have neither (and if i would this won't matter to me as a] X could create one big desktop; and b] i can already do rendering to remote Xs for a while (this is: run 2 machines with X and do the Gem-output on one machine; or run 2 X servers on one machine and re-direct the rendering from the "patching" X to the other one))
while i don't think that their are similar mechanisms like X-forwarding on osX and win23 (as long as you don't run X of course), i think that spanning across multiple gfx-cards should not be an issue today. (ok, i have never actually used this...)
Does it seem to have conflicts with the vertex array no, why should it ?
stuff? I'm also working on changing rendering in GemMan, but my solution is not necessarily just to move it to a new object...
so why do i think we need multiple windows ? people keep bothering me with feature-requests like "i have a dual-head gfx-card and want to do a performance; the second head goes to the video-beam while i am controlling on the first head. unfortunately i cannot see the beam from where i am and they have no video-splitter for me to monitor what i am actually producing. wouldn't it be possible to display the "output" on a small monitoring window ?
the other thing is, that we (the iem) are currently working on a pd-plugin for webbrowsers. it is important (for whatever reasons) that Gem is included and that rendering is done to an "embedded window" (e.g. like with movie-player-plugins the rendering-window should be bound to the browser (scrollable and everything) and not pop-up "somewhere" on the desktop and vanish behind other windows as soon as i change some parameters on the plugin-GUI in the browser)
there *is* a lot of code in GemMan that is specific to the operating systems window handling, and even worse, there is code in there that depends on certain graphics-servers.
furthermore, a lot of code in GemMan is declared "static" (like the viewpoint). now *if* i want the ability to render to several independent windows, then i also want to be able to set different viewpoints for each window. or lighting, or background-color, or dimensions, or whatever...
how are we supposed to ever drive a cave with Gem otherwise.
...have no idea what an /src/Output directory would be good
on the long run i would like to remove the dependency on X from Gem. (e.g. if only output to an aa-terminal is needed). then there might be output-modules that only make sense for a special hardware. i have thought to isolate such objects and make them as externals to Gem.
...are we going to be auto-subscribed like last time? I'm interested in staying abreast of commits...
even i am able to learn. nobody will be subscribed automatically.
manage this? Check out multiple copies of Gem, each with it's own branch/tag/whatever?
hmm. supposed your local copy is up-to-date. then you could just update your whole source-tree to the tip of a certain branch; that's it. you are there. edit. commit. then update to another branch. edit. commit. then go back to HEAD. and so on. the only problem arise, when your local copies are modified and you don't want to check them in.
mfg.a.sdr IOhannes