Excerpts from Adam B's message of Thu Jan 28 05:55:05 +0000 2010:
> Hello all,
>
> I'm starting work on a puzzle/adventure game which will use OpenGL. I
> think Clutter might be able to help me with two things:
>
> 1) I need to build a pleasing 2D GUI to allow players to save/load
> games and configure options etc.
> 2) I need to render video to an OpenGL texture. (It seems that
> Clutter-gst can do this quite well)
>
> My concern is that, Clutter might not like being a 2nd class citizen
> in a larger 3D OpenGL game. For instance:
We do support breaking out into raw OpenGL to some extent, though we
wouldn't really recommend it.
cogl_begin_gl() and cogl_end_gl() can be used to delimit where you are
manually using OpenGL and they will basically try and normalize the
OpenGL state and flush any of Cogl's cached OpenGL state. The important
limitations of this mechanism are:
1) It's your responsibility to save and restore any OpenGL state that
you need to change while rendering your puzzle game.
2) We don't currently provide any guarantees about how we normalize the
state only that it's consistent each time you call cogl_begin_gl () We
can potentially improve this though:
- Currently we just setup a simple CoglMaterial and flush the state to
OpenGL as a way to normalize the state, the problem is that we may
change how CoglMaterial is implemented which will change how the state
is normalized.
- An alternative would be to guarantee that we restore everything back
to OpenGL defaults; this would be quite difficult for us to support
but could potentially be done. The OpenGL state is owned and cached by
different Cogl components, but we could potentially add a
_cogl_<component>_normalize_gl_state () to each component to help
do this in a relatively maintainable way.
Asside from cogl_{begin,end}_gl we don't provide an easy way to
integrate with an existing game engine (probable the best way at the
moment would be to start with a Clutter backend for the game engine),
but if its something simple you are writing from scratch then I would
recommend that you just leave Clutter responsible for creating the GL
context.
If you create a custom Clutter actor and add it to the stage then you
can use the paint function as the point where you break out and render
your game scene.
>
> 1) When the user is playing I need full control of the OpenGL
> pipeline. I need to setup the perspective matrix, rotate/translate
> according to mouse movements , setup textures, draw geometry, etc.
> More bluntly, Clutter needs to stay out of my way.
It might not expose all the feature you want yet, but have you
considered using the Cogl API instead of OpenGL? Cogl gives direct
control over the perspective/modelview matrices, it gives access to
offscreen framebuffers, vertex buffers, blend modes, loading textures,
controlling texture combining and a clipping API.
It sadly doesn't yet have lighting support, and some other fairly basic
things but it may be feasible to add missing features to Cogl depending
on how much you need?
>
> 2) I need to render video onto a rectangle face and be able to place
> that face precisely using 3D coordinates.
ClutterGst can give you a ClutterActor that displays video and you can
position actors in 3D. The difficulty may be if you want this right in
your game scene which has a custom projection matrix? I can think of
some approaches but they all sound quite hairy. Need to think a bit
about this one.
>
> Is this level of control feasible with Clutter?
I think you will come across some difficulties and probably some Clutter
bugs, but its potentially doable. If you could use Cogl instead of
OpenGL that would avoid the awkward state management issues but that may
not be feasible for your game.
kind regards,
- Robert
--
Robert Bragg, Intel Open Source Technology Center
--
To unsubscribe send a mail to [email protected]
