hi all.
now that the gem-0.90 release is out for some weeks, i think it is time to start some traffic on this list again. (but of course: what to talk about now ? we used to discuss the release for years...)
some points:
------- stable: i have branched v0_90 for bug-fixes on the latest stable release
-------------------- further development: wini has done some research on opensource-development and has found out that os-dev can be organized effectively in (surprise:) several ways to achieve an optimum development/stability-ratio: (the following is a translation from german and it is already some weeks ago, so i might use the wrong termini)
a) pope: one person revises all code and decides which parts of the development should go into the next release b) committee: a small team off people does like the pope. c) branching: each new feature is branched off the main CVS-trunk. as soon as it has become stable the branch is merged with the main trunk.
i don't think that a) would be a very good idea (as it has proven to lead to major quarrels and misunderstanding) as for b) it seems like a bit of an overhead, as the core-development team is so small, that all of us would be in the committee.
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...
------------- 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.
cheers, comments ? and happy coding
mfg.as.dr IOhannes
On Jun 18, 2004, at 7:58 AM, IOhannes m zmoelnig wrote:
hi all.
now that the gem-0.90 release is out for some weeks, i think it is time to start some traffic on this list again. (but of course: what to talk about now ? we used to discuss the release for years...)
...sounds good to me!
some points:
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...
...the only thing that I see different about this (from what we've been doing) is that we'll have several branches during development...this is fine as long as we announce that such n'such tag is being worked on for feature X: I would hate to see duplication of effort creep in ;-)
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.
...other than the above, I think it'd be nice to re-do the basic render system so that we have control over the different buffers (accumulation, depth, etc): this would go some way toward improving the opengl wrappers functionality, too...also we should integrate more opengl features beyond v1.1 ;-) (thinking specifically of multitexturing, but also a whole litany of things that exist in 1.2-1.5)...maybe it would also be good to add pbuffer support (tho I'm not so certain what the big difference is to "render to texture", and it's certainly buggy on OSX 10.3.4 :-( )...and of course, gotta add more model/animation support (3ds (I've actually almost got something for this atm), vrml, ?), perhaps even some form of game level rendering (thinking quake3 maps or such)?
that's certainly a start! jamie
Hey all,
I've got 0.90 on the powerbook and quite happy. I am (unfortunately) getting crashes, but it requires quite a bit more investigation. I can't figure out how to reproduce it, but still happens often. It is certainly related to creating the gemwin the second time... I'll send more info when I can figure it out.
As for feature requests I've got two big ones:
1. Support for loading video clips and still images with alpha channels intact! (PNG loader for stills, no idea what video formats contain alpha channels?) pix_mask is not so important per-se as long as one can actually use graphics with alpha channels. I've only even used pix_mask for loading images with custom-made masks. Mind you using the RGB channels of one video stream as the alpha of another stream could be very interesting. The most obvious example of this I can think of is using nice pre-rendered Gaussian blurred drop-shadows that still work no matter what is behind them.
2. I've made a little test of using the gem-win as an interactive interface surface. Each object calculates its own bounds, taking into consideration position and scaling. Then I convert the pixel coords of the mouse to gemcoords and each object tests if the mouse is on it and then acts accordingly. I've got scale-up rollovers and drag and drop stuff working. This is really ugly though, so I propose an object that returns the bounds (in gem units) in 3D no matter what scaling and rotation objects may be present to mess up the bounding-box. Bounding-box is the first step but ideally I would like to be able to test if a certain coordinate overlaps some part of an object in 3D space. Since a bounding-box does not actually correspond to the surface of an object unless it is a rectangle that can only be rotated by 90 degree increments. I would imagine that the more complex the geo the harder to calculate if a point overlaps? This object could grow into a number of comparison objects for collision detection, testing if objects occlude one and other etc..
3. Gemtablet working on OSX ?
Thanks all for your hard work and great contribution to a very powerful piece of software.
Ben
James Tittle II wrote:
On Jun 18, 2004, at 7:58 AM, IOhannes m zmoelnig wrote:
hi all.
now that the gem-0.90 release is out for some weeks, i think it is time to start some traffic on this list again. (but of course: what to talk about now ? we used to discuss the release for years...)
...sounds good to me!
some points:
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...
...the only thing that I see different about this (from what we've been doing) is that we'll have several branches during development...this is fine as long as we announce that such n'such tag is being worked on for feature X: I would hate to see duplication of effort creep in ;-)
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.
...other than the above, I think it'd be nice to re-do the basic render system so that we have control over the different buffers (accumulation, depth, etc): this would go some way toward improving the opengl wrappers functionality, too...also we should integrate more opengl features beyond v1.1 ;-) (thinking specifically of multitexturing, but also a whole litany of things that exist in 1.2-1.5)...maybe it would also be good to add pbuffer support (tho I'm not so certain what the big difference is to "render to texture", and it's certainly buggy on OSX 10.3.4 :-( )...and of course, gotta add more model/animation support (3ds (I've actually almost got something for this atm), vrml, ?), perhaps even some form of game level rendering (thinking quake3 maps or such)?
that's certainly a start! jamie
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
Hello,
i'm new to the list and i experience some problems with Gem 0.9 compilation
- Where are the pix_depot.cpp and pix_texture2.cpp ? may i remove them from the visual c project ? - i dont have any file of the yuv module, where i can fin it ?
Thanx for the help Ronan
Ronan PUCE MUSE wrote:
Hello,
i'm new to the list and i experience some problems with Gem 0.9 compilation
- Where are the pix_depot.cpp and pix_texture2.cpp ? may i remove them from
the visual c project ?
yes; i have only access to vc6 so it might be, that the vc7 project files were not updated.
- i dont have any file of the yuv module, where i can fin it ?
nowhere, there are none (all the yuv-functionality has been incorporated into pix_
mfg.as.rd IOhannes
Hello,
Thanx for the tip IOHannes !
I was able to compile the debug version of gem, but i got an error linking the release version. I'm sorry if that's a simple thing but i dont want to do mistakes. Here is the errors:
strmbasd.lib(wxutil.obj) : error LNK2005: "public: __thiscall CCritSec::CCritSec(void)" (??0CCritSec@@QAE@XZ) already defined in DSgrabber.obj strmbasd.lib(wxutil.obj) : error LNK2005: "public: __thiscall CCritSec::~CCritSec(void)" (??1CCritSec@@QAE@XZ) already defined in DSgrabber.obj strmbasd.lib(wxutil.obj) : error LNK2005: "public: void __thiscall CCritSec::Lock(void)" (?Lock@CCritSec@@QAEXXZ) already defined in DSgrabber.obj strmbasd.lib(wxutil.obj) : error LNK2005: "public: void __thiscall CCritSec::Unlock(void)" (?Unlock@CCritSec@@QAEXXZ) already defined in DSgrabber.obj etc...
It seems that i have to exclude one of the two libraries from the linkage. Am i wrong ? if so, which one ? strmbasd.lib is specified in the project but not DSgrabber.obj
Any1 have a clue ?
Thanx for the help Ronan
----- Original Message ----- From: "IOhannes m zmoelnig" zmoelnig@iem.at To: "Ronan PUCE MUSE" r.leboite.pm@birdsinplane.com Cc: "gem-dev" gem-dev@iem.at Sent: Saturday, June 19, 2004 7:17 PM Subject: Re: [GEM-dev] Hello
Ronan PUCE MUSE wrote:
Hello,
i'm new to the list and i experience some problems with Gem 0.9
compilation
- Where are the pix_depot.cpp and pix_texture2.cpp ? may i remove them
from
the visual c project ?
yes; i have only access to vc6 so it might be, that the vc7 project files were not updated.
- i dont have any file of the yuv module, where i can fin it ?
nowhere, there are none (all the yuv-functionality has been incorporated into pix_
mfg.as.rd IOhannes
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
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
chris clepper wrote:
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.
it is also my understanding, that branching off a stable-release PLUS branching each development is a bit contradictory.
as for having main vs. dev branches, it again leads to the discussion, who decides what goes from dev to main.
what i do not want to have, is an organization as on pure-data's CVS, where there are thousands of branches and i do not know what is what.
therefore branches should be short-living, that is: a branch is created, development is done, the branch is merged to the main trunk and vanishes.
but of course, if your CVS setup cannot handle this, all discussion is void (but really, i cannot believe it)
and of course: each branching and merging should be properly announced to this list.
I have some pixel based stuff kicking around for 'tracking' and I want
me too ;-)
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.
what is still very high on my todo-list (and what i have forgotten to mention) is selection-buffers (Ben's mail reminded me of this) ((whoops, no the "other" thing is gone again;-)))
mfg.a.srd IOhannes
On Jun 19, 2004, at 3:17 AM, IOhannes m zmoelnig wrote:
it is also my understanding, that branching off a stable-release PLUS branching each development is a bit contradictory.
as for having main vs. dev branches, it again leads to the discussion, who decides what goes from dev to main.
what i do not want to have, is an organization as on pure-data's CVS, where there are thousands of branches and i do not know what is what.
Ok, this is very reasonable, and the only question is how to decide what deserves a branch. For example, I have some of the very basic vertex_array stuff working with the current 0.90, so would the addition of this to CVS require a branch? It does add a few items to GemState and gemhead, but apart from that it's only a set of additional objects.
therefore branches should be short-living, that is: a branch is created, development is done, the branch is merged to the main trunk and vanishes.
Looking at the branch you already made for 'v0_90', it appears that you have done opposite of what I thought you were talking about. The branch is the stable release, and the main trunk is still for development? So the answer to my question about branching for vertex_arrays would be 'No', it goes in the main trunk. Is this correct?
but of course, if your CVS setup cannot handle this, all discussion is void (but really, i cannot believe it)
I have the usual CVS command line tools at my disposal; however, I use the integrated CVS features in Apple's IDE, which make browsing through versions, comparing and committing changes available in the same window as file editing. I haven't found out how it deals with branches, and it looks like they aren't even noted in the browsing and comparison functions.
If the majority of new adds and commits will still be done in the main trunk and only bugfixes and merges happen to the stable branch, then this won't be a problem at all.
and of course: each branching and merging should be properly announced to this list.
I think you are the only developer who can actually branch and merge in the CVS repository right? So there will have to be discussion before any action if another developer wants to do this.
cgc
Zitiere chris clepper cgc@humboldtblvd.com:
Ok, this is very reasonable, and the only question is how to decide what deserves a branch. For example, I have some of the very basic vertex_array stuff working with the current 0.90, so would the addition of this to CVS require a branch? It does add a few items to GemState and gemhead, but apart from that it's only a set of additional objects.
actually i do think that this is a good example for a branch. i guess that the vertex stuff is almost done (apart from testing), so you would just check in everything to the new branch. some willing people would do some testing on other platforms and after this has been settled it would merge again. so the branch would (most probably) only exist for 1 week (looks a bit oversized...)
therefore branches should be short-living, that is: a branch is created, development is done, the branch is merged to the main trunk
and vanishes.
Looking at the branch you already made for 'v0_90', it appears that you have done opposite of what I thought you were talking about. The branch is the stable release, and the main trunk is still for development? So the answer to my question about branching for vertex_arrays would be 'No', it goes in the main trunk. Is this correct?
no i have to convince that i am not sure of everything too
it is true, that v0_90 is contradictory to whatever i have said. i have branched v0_90 before really considering the dev-branches.
but i believe they could co-exist: this would give us: 1) a main trunk that is "kind of stable" but where actual development is done 2) major-branches that are "really" stable, meaning: releases; they will never be merged into the main trunk again; the only reason i have "branched" instead of just "tagged" is for bugfixes. 3) small development branches that are merged when development stabilizes.
but i am no CVS expert and there are certainly points that are doubled by this system.
but of course, if your CVS setup cannot handle this, all discussion is
void (but really, i cannot believe it)
I have the usual CVS command line tools at my disposal; however, I use
the integrated CVS features in Apple's IDE, which make browsing through
versions, comparing and committing changes available in the same window
as file editing. I haven't found out how it deals with branches, and it looks like they aren't even noted in the browsing and comparison functions.
If the majority of new adds and commits will still be done in the main
trunk and only bugfixes and merges happen to the stable branch, then this won't be a problem at all.
and of course: each branching and merging should be properly announced
to this list.
I think you are the only developer who can actually branch and merge in
the CVS repository right? So there will have to be discussion before any action if another developer wants to do this.
oh, i haven't thought so. i am quite sure that every developer has the possibility to branch; right now almost all branches have been done by me (but guenther has made one too) about merging i have no idea but probably it is the same. if only "managers" have the right to branch/merge i think all of us (all ? only core developers?) should get these rights.
my proposal would be: let's try it out with the vertex-stuff. if it turns out to be completely nonsense and/or too complicated we could drop it again.
mfg.ads.r IOhannes
PS: we are trying to organize some kind of meeting in Graz in late september; nothing is fixed yet, but if we raise enough money i hope we can invite all of you to discuss such (and other) things. more to come in separate mails
On Jun 20, 2004, at 6:49 AM, zmoelnig@iem.at wrote:
no i have to convince that i am not sure of everything too
it is true, that v0_90 is contradictory to whatever i have said. i have branched v0_90 before really considering the dev-branches.
but i believe they could co-exist: this would give us:
- a main trunk that is "kind of stable" but where actual development
is done 2) major-branches that are "really" stable, meaning: releases; they will never be merged into the main trunk again; the only reason i have "branched" instead of just "tagged" is for bugfixes. 3) small development branches that are merged when development stabilizes.
Alright, now I think I understand. Branching at a stable release makes some sense because, as you say, the branch contains a tag and does allow for a bit more flexibility with later commits via merging.
The development branches sound like a good idea for anything that changes the core functionality in a substantial way. Probably something like multiple render targets would fall under this, but the simple addition of new objects that don't affect how other objects work would not.
i am quite sure that every developer has the possibility to branch; right now almost all branches have been done by me (but guenther has made one too) about merging i have no idea but probably it is the same. if only "managers" have the right to branch/merge i think all of us (all ? only core developers?) should get these rights.
I remember trying to tag something in CVS and not having the right permissions. I'm pretty sure I was doing it correctly.
my proposal would be: let's try it out with the vertex-stuff. if it turns out to be completely nonsense and/or too complicated we could drop it again.
Ok, this sounds like a plan. Here's what I think is the proper way to do this:
-cvs tag -b vertex_array <-- this creates the branch
-cvs update -r vertex_array <-- this sets my current local copy to the vertex_array branch
-add the new files locally and commit them
That should work, but I'll wait for some comments before actually doing it.
cgc
chris clepper wrote:
On Jun 20, 2004, at 6:49 AM, zmoelnig@iem.at wrote:
no i have to convince that i am not sure of everything too
it is true, that v0_90 is contradictory to whatever i have said. i have branched v0_90 before really considering the dev-branches.
but i believe they could co-exist: this would give us:
- a main trunk that is "kind of stable" but where actual development
is done 2) major-branches that are "really" stable, meaning: releases; they will never be merged into the main trunk again; the only reason i have "branched" instead of just "tagged" is for bugfixes. 3) small development branches that are merged when development stabilizes.
Alright, now I think I understand. Branching at a stable release makes some sense because, as you say, the branch contains a tag and does allow for a bit more flexibility with later commits via merging.
The development branches sound like a good idea for anything that changes the core functionality in a substantial way. Probably something like multiple render targets would fall under this, but the simple addition of new objects that don't affect how other objects work would not.
right. i have just made some changes because of the newWave-bug that cyrille discovered and now i'm hesitating to check in ;-)
i do think, we could relax the branching to "heavy changes" (e.g: what you call "changing the core functionality" and which could seriously break things, e.g. because the GemState is changed.
as for small objects that are not likely to break anything (especially: compilation!!!) they probably should go into the main dev-trunk immediately.
now i'll wait for some comments too, until i check in (to be honest: i was thinking slowly and have committed it to the v0_90 already; but at l(e)ast i thought...)
Ok, this sounds like a plan. Here's what I think is the proper way to do this:
-cvs tag -b vertex_array <-- this creates the branch
-cvs update -r vertex_array <-- this sets my current local copy to the vertex_array branch
-add the new files locally and commit them
That should work, but I'll wait for some comments before actually doing it.
looks good to me.
mfg.a.sdr IOhannes
hi,
i wonder if somebody can help me where to start to look for a solution:
i m unfortunately sitting here on a winXP and whenever i try to use pix_videoDS or pix_video this machine tells me: pd.exe has encountered a problem and needs to close. We are sorry for the inconvenience.
directX 9 is installed, it does not matter if a camera is attached or not.
thx
erich
rat@telecoma.net wrote:
hi,
i wonder if somebody can help me where to start to look for a solution:
please use the gem-bin-0.90.1.zip (note: 0.90.1 instead of 0.90.0) which can be found at http://gem.iem.at/download.html
mfg.as.dr IOhannes
PS: and do *not* use [pix_videoDS]; use [pix_video] instead
please use the gem-bin-0.90.1.zip (note: 0.90.1 instead of 0.90.0) which can be found at http://gem.iem.at/download.html
merci it works now. the problem was that the bin-doc package which i downloaded contained the broken dll.
cheers
erich
mfg.as.dr IOhannes
PS: and do *not* use [pix_videoDS]; use [pix_video] instead
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
-
B. Bogart -
chris clepper -
IOhannes m zmoelnig -
James Tittle II -
rat＠telecoma.net -
Ronan PUCE MUSE -
zmoelnig＠iem.at