[Pysdl-devel] pysdl & numpy decision

[Pete S. <pe...@sh...>]

> It's not that bad now that I figured out the
> funky-looking slice notation and found out I don't
> have to know matrix math.  It looks like most of what
> I'd use it for would just require the easier stuff.

yeah, all it comes down to is their flexible slicing and
using the ufuncs. i'm pretty sure the pyopengl module
also uses numpy for arrays of point attributes. i think
this is an incredible mix and do want to try playing
with it.



> I tried your gradient function with just the normal
> slice operator.  It is still fast but takes .160 sec
> just on the one slice command to transfer to the
> surface. So the surf.pixels thing will be great.  Also
> I had to fix a couple things:
> --These should be [2]'s for blue ^ not alpha
> --The first shape parameter is the # of rows, not the

doh, you caught me. i whipped the routine up at work.
and was unable to try the final version of the code,
i only knew the 'meat' of it created the gradient :]



> > so now surface.pixels[20,20] lets you access pixel
> > at 20,20
> Won't this be the same problem with w and h?  I guess
> it depends on which way your conversion goes as far as

ok yes, this is the __BIG__ decision that needs to be
made. which order the pixel array is accessed: X,Y or Y,X


X,Y: this is the most intuitive order for me, that's about
the only argument for it (heh), when printing the array
it is actually transposed from the way it is viewed, kinda
strange, but usually you don't print arrays of images,
that's really slow and only for debugging

Y,X: aside from me finding this a little odd, it does offer
some encouraging benefits. first, it keeps the interface more
consistent with the currently available index operators
(mysurface[50][10] = mysurface.pixels[50,10] = row 50, column 10).
of coarse, if you print the array it's WYSIWYG. the other
potential benefit is a slight speed boost. if we access the
surface with Y,X and it has no odd pitch settings the pixel
data is 'continuous' and numpy has some optimizations here
and there for these continuous blocks of data. (don't get too
excited about this, it's just a couple %'s faster)


so anyways, a decision has to be made. i personally still
like the X,Y notation, it just 'clicks' for my brain. but
i could easily adapt to the other style. it's really
simple to do on the "C" side either way we just need to
make a choice.

i definitely leave this one open for discussion, i might
have missed a good argument for/against either method.

here's my crude examples;

surf.pixels[:,100]  ==  row 100 _or_ column 100
surf.pixels[50,10]  ==  row 50 & col 10 _or_ row 10 & col 50



> would it be possible to keep an extra position in the
> 3rd dimension in addition to the RGBA, to use
> optionally as an additional mask or a terrain
> identifier (ie passable/impassable) for tiles in a
> map, or possibly for bump maps?  Maybe that's overkill
> though. 

yeah, this would be possible, but your right it might be
a little overkill. probably better as a separate array,
but who knows? especially since arrays must contain all
the same data type, so unless your mask/terrain/map data
is the same format as the pixels you really don't want
to mix them.



> Thank you for doing this.  I'm going to try to turn my
> own more convoluted gradient function into array
> functions.  I think in my case the math was the real
> bottleneck so it should help a lot.  I was doing a
> radial blend between two colors with an adjustable
> curve.  It would be nice if it could work in real
> time.

whew, if/when you get this working mind posting it?
it'd probably make a good example of something pretty
complex being done with the arrays.


> Also, are there any plans to support SMPEG?  I've been
> surprised to find that there are almost no Python
> multimedia extensions, but it would be fun to mess
> with that. I'm glad to see SDL_mixer supporting Ogg
> Vorbis. 

yeah, in fact all the new SDL "support" libraries seem
to have gotten neat new features (as david noted in
his mail)




note, just so you can play with this at home.. here are
the quick changes you need to make to use the "pixels"
member

/* this goes near the top (fix path)*/
#include "../Numerical-15.3/Include/arrayobject.h"


/* this goes in initsdl after Py_InitModule3 line*/
    import_array();


/* and here is the main code, this goes in
   sdl_surface_getattr, put this block at the top
   of the function */
 
if(!strcmp(attrname, "pixels"))
 {
     Surface_Object* surface_ref = (Surface_Object*)self;
     SDL_Surface* surf = surface_ref->surf;
     PyObject* array;
     int dim[2],  type;
     switch(surf->format->BytesPerPixel)
     {
  case 1: type = PyArray_UBYTE;  break;
  case 2: type = PyArray_SHORT;  break;
  case 4: type = PyArray_INT; break;
  default:
      PyErr_SetString(PyExc_RuntimeError, "no support for 24bit surfaces yet");
      return NULL;
     }
     dim[0] = surf->w;
     dim[1] = surf->h;
     array = PyArray_FromDimsAndData(2, dim, type, (char*)surf->pixels);

     /*swap x and y, and account for stride*/
     ((PyArrayObject*)array)->strides[0] = surf->format->BytesPerPixel;
     ((PyArrayObject*)array)->strides[1] = surf->pitch;
     ((PyArrayObject*)array)->flags &= ~CONTIGUOUS;
     return array;
 }


/*tada, the formatting is likely destroyed by email
  but its a small piece of code. note, no support for
  24bit surfaces with this. still a little uncertain
  of how to best handle them*/

whew, these pysdl mails are getting longer and longer :]