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 at iem.at
> http://iem.at/cgi-bin/mailman/listinfo/gem-dev
>