Re: [PyOpenGL-Users] 2d sprite engine performance.

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

Erik Johnson wrote:
...

>>so a sprite's
>>move command would look like:
>>
>>    self.getSpriteVectors()[self.startIndex:self.stopIndex] += delta
>>
>>(where delta would be a simple tuple), allowing the array to handle
>>updates in Numpy code.
>>    
>>
>
>I might need to learn more about Numeric.  I didn't know that you could
>do things like the above and have Numeric take care of it without Python
>doing a bunch of intermediate steps behind the scene.
>  
>
They are fairly serious about allowing efficient number crunching :) . 
We just go along for the ride on the backs of their work :) . 
Particularly, the in-place modifiers are a big part of the Numpy
interface.  By the way, watch out for them too:

    In [6]:a = arange( 20 )

    In [7]:b = a[5:8]

    In [8]:b += 5

    In [9]:a
    Out[9]:
    array([ 0,  1,  2,  3,  4, 10, 11, 12,  8,  9, 10, 11, 12, 13, 14,
    15, 16, 17, 18, 19])

that's the same feature that allows the += delta, but it can bite you if
you don't keep in mind that the sliced array is pointing to the same
memory area as the original array.

>I thought that contiguous() just checked if the array in question could
>be passed to opengl directly as a pointer instead of being copied.  Am I
>missing something?
>  
>
It does the check, and if the array *isn't* contiguous, it copies it
into a contiguous array and returns that.  The effect is accomplished
with a fast Numpy flag-check, so if the array is contiguous (the normal
case), then there's little performance impact.  OpenGLContext, for
instance, has a flag (default on) that just runs contiguous on every
array it's going to pass to PyOpenGL for IndexedFaceSets.

Have fun,
Mike

________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com