Quoting Jason McMullan <[EMAIL PROTECTED]>:
> 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).
Did you have a look at libart? The rendering model is pretty well suited
to implement postscript over. And it provides a lightweight microtile array
structure dedicated to mark regions that needs to be updated. This could be
used to write a scene graph render. The only thing is to glue the different
components of the API together.
> 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.
That's very true. i shot myself!
> 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.
I think it is basicaly the idea behind libbggi3d: abstract a rendering
pipeline, then the renderer try to make use available accelerations to
optimize things.
> No need for each app developer to attempt to reinvent the wheel.
No, but I wonder if rasterman is not the kind of guy who likes to do so.
Regards.
