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

[Lorcan H. <lh-...@lo...>]

Mike,

Thanks for that quick response!  You've certainly given me plenty
to think about... :)

I'm not sure if I'll go ahead with this or not, but I'll certainly
look into it further - maybe writing a simple test program or
two, to test the ideas.  Any progress, or problems I get stuck on,
will be reported back here to the list. 

Thanks again,

Lorcan

Mike C. Fletcher wrote:
> 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/
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
> 
>