• 2005
  • November
  • 06
  • Finally got the GLUT fonts working in OpenGL-ctypes (Stupid indirection operator...)

Finally got the GLUT fonts working in OpenGL-ctypes (Stupid indirection operator...)
Written by on in Snaking.


I decided I really needed to get the OpenGL-ctypes GLUT support finished, so I just sat down and pounded on it for a few hours. The fonts were getting messed up because I was missing the import of a & indirection (resolution, whatever) operator in the definition. Basically there's a void * in the .so, but we want a pointer to that pointer, not the pointer itself.

Also made a few small fixes to the callback machinery to work around bugs that showed up during testing. There's still lots of functions I don't have test-cases for, but the big ones (i.e. the ones I use in OpenGLContext) seem to be working properly.

I'm considering now whether to move to the extension handling, or whether to work on supporting the GLUT-extension packages (FreeGLUT, OpenGLUT).

Comments

  1. Dethe Elza

    Dethe Elza on 11/07/2005 1:55 p.m. #


    Mike,<br />
    <br />
    I've been following your progress on OpenGL-ctypes with interest. I'm peripherally involved with VPython, specifically with getting VPython running on OS X under Aqua. Does your ctypes code work on OS X currently? And how much of a speedup are you seeing? The main reason that VPython doesn't use PyOpenGL, but instead creates its own OpenGL extension is due to the lack of performance in PyOpenGL. I keep hoping that Murphy's Law, maybe combined with a speedup in the PyOpenGL base, will resolve that so we can move VPython to something easier to maintain and tinker with.<br />
    <br />
    Thanks for the updates.

  2. Mike Fletcher

    Mike Fletcher on 11/07/2005 7:10 p.m. #


    At the moment, OpenGL-ctypes is probably slightly slower than PyOpenGL, but not dramatically slower. I can quite comfortably run the demos even on my limping (no hardware accelleration) machine with every operation printing out loads of debug information to terminal.<br />
    <br />
    The idea is that we'll get the whole thing implemented in Python to make programming, maintenance and porting easier, then, (and only then), we'll profile and see what needs C-level optimisation (or just better coding in Python).<br />
    <br />
    I've not tried running under OS-X or Windows yet. I don't have an OS-X box on which to run, and I don't feel like spending precious hacking time getting the Toolkit toolchain installed again to build CVS ctypes on Windows.

Comments are closed.

Pingbacks

Pingbacks are closed.