guenter geiger wrote:

On Fri, 16 May 2003, IOhannes zmoelnig wrote:

...

i tried to outline what has to be done:

1. stability (fits to this thread...) on all platforms

Some bugtracking system, or a TODO file in CVS would be good.

probably we could use the sourceforge bugtracker ?

...

2. feature-freeze:

i think, basically that's it.

If we could find someone that is going over the documentation.

if we could..

Would be nice if the examples had some "face-lift".

Would it be possible to have "working" reference patches ?

which ones aren't working ? this is something for the BUGS file. (ah i just put it into src/Gnu which is a bad idea)

mfg.as.rd IOhannes

On Fri, 16 May 2003, IOhannes zmoelnig wrote:

...

i tried to outline what has to be done:

1. stability (fits to this thread...) on all platforms

Some bugtracking system, or a TODO file in CVS would be good.

yes, that would help.

...

2. feature-freeze:

i don't think i will have the dv-in working soon under linux (and i need some help with the class-concept for addressing two different driver-architectures) furthermore, i don't think that the new release will feature any other outputs ("gemwin"s like dv-out). this is fine for a next release.

i think, basically that's it.

for the OSX port pix_write needs to work for feature parity with win/linux. i am going to keep the same image series approach as the other platforms for now, but later i would like to make a QT recorder that makes .movs in any supported codec.

there are a few more yuv_ objects that need to be converted to pix_ but those can happen anytime. at some point yuv_ can be removed altogether.

If we could find someone that is going over the documentation. Would be nice if the examples had some "face-lift".

Would it be possible to have "working" reference patches ?

i need to add some reference patches. by 'working' you mean a fully functional patch for each object complete with gemwin? maybe a functioning chain(s) without the gemwin could work as well.

i have done 8 tutorials cover some very basic features of GEM. the next step involves more advanced demos, my list includes an explanation of YUV and RGB color-spaces, in depth texturing and texcoords, particles system, and grabbing/recording info from the gemwin (pix_snap/write). any suggestions or ideas regarding the tutorials is appreciated.

cgc

Guenter

---

GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev

Hi again,

A quick question to Jamie and Chris, Could one of you add the project builder project to the CVS repository? There seems to be an old stuffed version there in the gem top dir but nothing more recent... is that right?

I've been doing occasional mac builds with a project that I've been keeping up to date... but it makes sense to keep the project in CVS doesn't it?

I seem to recall that there was some issue with importing the project. Is that right? Maybe we can work that issue out now if it's still a problem.

Thanks, Daniel

Hi All,

On 27/5/03 10:12 AM, "tigital" tigital@mac.com wrote:

...yep, this has been a longterm "todo" of mine: I think the correct way to do it is to add a ".cvswrapper", but I haven't checked out what this entails...I think has something to do with telling cvs not to treat binaries like text files...

yeah - using cvswrapper in the repository and/or on the local machine can add a filtering step to treat directories like a single binary file. the default one on an os x box handles nibs and so on I think

i think you need to have the cvswrapping set up on both client and server for it to work on a remote repository.

...in any event, I know that there's also more to learn about uploading project files (we shouldn't include things like "tigital.pbx"!)

that's the cvsignore file... which acts on the initial import step, as far as i recall.

i have a few os x projects under my local cvs repository where i've imported the .pbproj directory and then the .pbxproj file (and used cvsignore to avoid getting the *.pbxuser). This works okay, since the pbxproj file is text anyway... but I guess you don't want CVS to attempt to do merges on it so it should be made to use "COPY" update methodology with an entry in cvswrappers.

all of that said, this in the short term I think doing a: cvs add GEM_darwin.pbproj cvs add GEM_darwin.pbproj/project.pbproj cvs commit

it would also be good to add the merge mode and ignore flags to the repository via the admin files in CVSROOT.

so I just did that with chris' project files and the pd-gem repository admin files. let me know how it works for you.

apparently there's some unreliability with the client/server behaviour unless you have local and remote copies of cvsignore. so try copying the $CVSROOT/CVSROOT/cvsignore to ~/.cvsignore (assuming $CVSROOT is the pd-gem repository here of course) and similarly for the cvswrappers file.

Daniel

You are right, ifdefs are a bad thing and I think that everyone is aware of that. Luckily C++ offers more elegant ways around this .. the problem in general I think is time.

There is the problem of getting all these new features in as fast as possible (using ifdefs) or to keep the code clean.

Maybe there should be a feature freeze and cleanup phase, (oh well, how boring ..)

Guenter

On Mon, 2 Jun 2003, chris clepper wrote:

Hi

The code in pix_texture has become appalling - the ifdefs have made it completely unreadable. Whoever has been doing #if 1 and #if 0 please remove this and decide what code you want to commit before committing it. There seems to be some sort of bracketing problem that causes crashes but it's really nearly impossible to trace it due to the ridiculous number of #ifdefs. If you have added #ifdefs to the code please go back and comment them for the other devs.

I'm about to write OSX only texturing objects because it's pretty obvious to me that texturing is OS dependent at this point. Maybe in the future this will change but this current ifdef hell is doing no one any favors at this point.

cgc

---

GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev

Zitiere Daniel Heckenberg daniel@bogusfront.org:

Hi All,

hi all.

I would certainly hope that we can avoid both #ifdef NIGHTMARES and

ahyes, the #if 1 / #if 0 nightmares certainly are mine. i'll try to remove them.

splitting the code object by object on platform lines. Both of these approaches are hard to manage in the long run.

If we can characterise the different behaviours of each platform and make the code behave accordingly at run-time that would be great. One example that comes to mind at the moment is the vertical flip required for quicktime images. That's not so much a platform issue as a behaviour (QT for Windows and DirectShow (sometimes) return "upside down" images). Writing completely separate OS-dependent classes won't help in that situation.

and the problem continues with rectangle-textures. i was thinking about making an additional "texCoordHint"-structure, that will set the basic texture-coordinates (upside-down + un/normalized textures) by the image-source. [pix_texture] and [pix_coordinate] would then just have to define a relative-coordinate (multiplication factors)

It's a similar situation with extension support I guess...

and i don't see any solution without ifdef'ing for references like GL_TEXTURE_RECTANGLE (or whatever it is called exactly), that are simply not defined in several header-files. (yes classes would move the ifdefs somewhere out of the procedures into head/foot of the files) and with [pix_texture]: there are a lot of critical #ifdef's that support openGL<1.2 (to me it even seems like some pre-version (<1.0) of openGL is supported ;-)) this could surely be wrapped into classes more elegant

btw: the long-discussed "new" animated-images sources (film*...) came into beeing just because i wanted to get rid of a lot of #ifdef's.

but really i do think we should do a (boring) feature-freeze and release. but of course, that's is dull work.

mfg.asd.r IOhannes