In article <[EMAIL PROTECTED]> you wrote:
> I haven't checked EVAS and know nothing about it, but the problem I see
> is if rasterman defined his own rendering primitives and graph structure,
> how can he be sure that his model will fit well in every hardware or formal
> specification. I'm not only talking about primitives, but more importantly
> how you access and modify elements in the scene.
I've been considering working on EVAS as a rendering engine
for the Display PS section of GNU OpenStep. Although it doesn't handle
all cases (stippled lines, etc), it should be a good speedup compared
to the current DPS model (redraw everything, IIRC).
> Moreover this model is not handy in every situations (a good ol' shoot 'em
> up game). If he needs to add lower level access, the API has a good
> chance to become bloated.
Actually, a 2D shoot-em-up is the perfect example of a good
use of a scene-graph architecture. Just put all the ships, bombs,
enemies, etc. in the scene graph as `hidden' objects, and move them
into position as required. Please see the `evas_test' demo that comes
with the EVAS package. It's a pretty good example of everything you'd
want to do in a shoot-em-up.
> I think this kind of functionnality would rather can be added later to ggi
> via its extension system (see for example the libggi3d project). You could
> implement such a model by maintaining a SVG graph. Now the problem is
> to get hardware acceleration nicely.
The best part of a scene graph is the fact that the renderer
of the scene graph can take care of all the hardware acceleration
presented to it. Using a jump-table override system like GGI, along
with an acceleration hints system (argh. DirectX argh.) the renderer
would be able to self-optimize for the hardware features available.
No need for each app developer to attempt to reinvent the
wheel.
--
Jason McMullan, Senior Linux Consultant
Linuxcare, Inc. 412.422.8077 tel, 412.656.3519 cell
[EMAIL PROTECTED], http://www.linuxcare.com/
Linuxcare. Putting open source to work.
