Re: [boost] [rfc] Boost Graphic/Game Engine

From: Michael Fawcett (michael.fawcett_at_[hidden])
Date: 2007-07-17 14:05:50

On 7/17/07, Felipe Magno de Almeida <felipe.m.almeida_at_[hidden]> wrote:
> Hi,
>
> There were some little interest for this in another thread here in
> boost. So, who has any experience in game programming, it would be
> interesting to layout some requirements for a new engine and
> complaints from other engines. See if we can find out how a game
> engine should really be.

I have some experience with PC and Playstation 2 games, teaching at
Full Sail (http://www.fullsail.com) and working in industry.  Not
nearly as much as some contributors I imagine.  I'm no longer in the
game industry, but work with "game-related" technology on a daily
basis with more serious end results...

Some complaints I have about other engines are:

- Ease of extending the engine.  For instance, if a new algorithm is
developed for interpolating between animations, it's not usually easy
to integrate without redoing most of (or all of) the animation code.

- Not supporting context changes in an optimal manner (determining
least number of context change commands given a set of "renderables")

- Being tied to custom containers and iteration techniques instead of
having STL style iterators and STD library containers used.

- Not being able to change the underlying containers at compile-time.
e.g. the Scene Graph will always be a tree where children are stored
in custom doubly linked lists, instead of the Scene Graph is templated
on storage types, and you can make it a tree of vectors, or lists
(much like Boost.Graph)

I'm sure others will chime in with their own complaints, but I think a
Boost engine should aim for as much compile-time flexibility as
possible, paired with run-time flexibility, which I sounds like it
would make heavy use of Fusion.

For instance, I may want to specify a renderer at compile-time that
always does 3 passes - depth only with opaque objects, then opaque
objects, then alpha (translucent) objects.  At run-time, if it's
determined that the graphics hardware is too old to have support for
2x speed up in the depth only pass, we could switch to a renderer that
only did 2 passes, opaque then alpha.

Obviously the sorting mechanism for both passes would be different too
(and templated).  Front to back for depth only and opaque, then back
to front for alpha.

There are lots of levels to a game engine.  Perhaps it would be wise
to break it up into separate libraries.  I can envision a single
library just for dealing with the OS + graphics hardware (setting up
the window, changing resolutions, changing bit depth, querying
capabilities, etc), and another for higher level scene management,
much like nVidia has a separate Scene Graph library.  There would also
be some sort of API that is agnostic between OpenGL and Direct3D
backends.

Lots to think about...

--Michael Fawcett

P.S. - Where does the math part fit in?  Another separate math
library?  Needs to be heavily optimized for speed, vectors and
matrices need to be guaranteed contiguous in memory, need support for
row major vs column major...

Create from scratch?
Wait for the Matrix Template Library 4.0 which is "coming soon"? (I
don't know if it does what is needed)
Modify/Extend Boost.uBLAS and Boost.Quaternion?