[GEM-dev] off to new shores...

[chris clepper]

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