Re: [PyOpenGL-Users] Using both PyOpenGL and C to drive OpenGL

[Mike C. F. <mcf...@ro...>]

Lorcan Hamill wrote:

> Hi folks,
>
> (Just discovered this list, so sorry if this is an FAQ - there
> doesn't seem to be a list archive, or I'd have searched it.)
>
> I'm working on a new fork of TuxRacer (based on the last
> GPL'd release, at http://tuxracer.sourceforge.net/), and
> I'm think of replacing the UI code with Python, using PyOpenGL.
> The main game engine, which is written in C, would remain
> intact, as far as possible.  Could that be done?  How? :) 

Every PyOpenGL function is written in C, there is nothing at all to stop 
you from integrating with a C system.  You need to work out which system 
has the responsibility of setting up the context, which one is going to 
handle input/output etc., but there should be no problem with rendering 
as long as you use the same OpenGL context for both sides of the system.

>  A top-level Python script initialises OpenGL, loads
>  the textures using pygame.image, draws the splash screen,
>  menus, etc. using PyOpenGL, handling input with pygame. 

Careful with your mental model here, as a general rule, menus are going 
to be redrawn at least as often as the main screen, they're going to 
acquire a callback from the engine to do the actual drawing on the 
rendering context.

>  The script creates an instance of a new GameEngine class
>  that I would implement in C, and invokes methods on that
>  object to set up the course. 

No problem, standard python extending model.

>  When the game is ready to go, the Python script would
>  invoke GameEngineObject.run().  At that point, the C
>  code in the extension module would take over - using
>  the OpenGL API to refresh the screen, and SDL for
>  keyboard and/or joystick input. 

I'm not an SDL/PyGame expert, but I think this is where you will run 
into trouble.  You will need to be sure that the registered functions 
are actually getting the events from the input.  Most likely the 
GameEngineObject isn't implementing a single-step run, but instead 
implements a mainloop in which large numbers of events are processed.  
You'll likely need to have registered callbacks which defer to the 
python code to make this work.

> Is that approach feasible?  Can both PyOpenGL and
> a custom C extension module share the use of OpenGL
> like that?  

No problems should arise.  As long as both are using the same OpenGL 
context.

> They'd take turns, obviously, so that
> the Python script would not invoke any OpenGL functions
> until after GameEngineObject.run() had returned. 

Not a big problem, really.  It's quite possible to have PyOpenGL 
plug-ins to rendering engines which render just as if they were written 
in C, after all, in the end they are.  PyOpenGL really is just calling 
regular OpenGL functions.  You might need to watch out for the global 
interpreter lock, but unless you are doing a lot of threading, it's 
probably a pretty low issue on the tree of potential problems.

> The screen would be repainted completely (and the OpenGL
> context could be reset) between the two different modes
> of operation, but it shouldn't change resoltion, or flicker,
> or anything like that. 

You might want to look into overlays, rather than distinct contexts.  
There's no real reason to repaint the whole window before running the 
PyOpenGL code.  OpenGL contexts are just OpenGL contexts as far as 
PyOpenGL is concerned.  It doesn't care where it renders, and will quite 
happily interact with your C code.

> Has anyone done anything like this?  A working example
> would be *really* useful... 

I don't have any samples of C extensions in hand, other than PyOpenGL 
itself.  By the way, one significant issue you may run into (I would 
expect it, though you haven't mentioned it) would be that you'll want to 
in some way wrap the internal structures of the game so that they can be 
manipulated by the python code.  There is very little which is 
PyOpenGL-specific, about this, just another exercise in extending 
python.  Depending on how much of the system you want to expose, you may 
want to pick up SWIG to automate the process.

> I'd also have the problem of making the C extension and
> pygame take turns in handling input events, but I guess
> that's off-topic for this list. :)

Probably, but the PyGame folks are fairly friendly :) .

Have fun,
Mike

_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/