On Jun 18, 2004, at 6:58 AM, IOhannes m zmoelnig wrote:
so i favour c) (with some b)): each development should be forked into a separate branch in the CVS; the core-developpers of this branch work on the code until they consider it stable and then make a call for testing via the list. after it has proven to run stable on all platforms this tree is merged back in.
i would suggest that the releasing should be done on each merge of a development-branch to the main-trunk that adds new functionality. (this can be discussed; it is just fundamentally different from the last release) the main-trunk can be used for bug-fixing...
So what determines where to branch? I can see doing one after each stable release like you have done for 0.90, but the c) point mentions 'each new feature is branched off' as well. A main and dev branch sounds ok to me, but I strongly favor as few branches and the simplest possible CVS layout as possible. Also, I'm not sure how well my current CVS setup will handle even a single branch - could mean some headaches ahead.
new features: i'm looking forward to vertex-manipulation, pixel-shaders, multiple gemwins, MMX/SSE2, new pixel-effects, pixel-analysis and tons of other things.
I'll see about getting the vertex stuff into CVS soon. It does require some additions to the basic render handling (GemCache, gemhead, etc), which need to be checked over thoroughly before adding too many new objects.
The basic Geos like sphere, etc need to have some sort of display list rendering which will greatly speed up patches that use them as static geometry. I don't know if we can come up with separate objects to insert into the GEM chain to build and call the lists for a group of Geos or if each object needs it's own code. We need as little immediate mode rendering as possible from now on.
Multiple render targets will be a necessity at some point. I think after we get them figured out and implemented we will wonder how GEM was even usable without them. Unfortunately, it looks like there isn't a nice cross-platform method for this right now, but since the basic windowing code is separated already, the OS specific rendering code can go in these files and generic wrapper functions could be used in the rest of the code.
Shaders would be good to implement once the whole GLSL has been sorted out. I have yet to see a shader perform better than client side SIMD code for the same function when it comes to total throughput. I know that flies in the face of all the marketing about shaders, but look at all of the games that use them and how poorly they perform on all but the latest and greatest hardware.
I have some pixel based stuff kicking around for 'tracking' and I want to get multiple video/camera sources working with Quicktime as well. There is a potential project coming up that would require tracking in 3D space. Might be interesting.
I'm probably not going to put much time into GEM for a little while, but I think that when I do, the focus will now be on 3D rather than 2D objects. That's probably really were both the strength and the future of GEM lies.
cgc