pyopengl-users — Discussion of all PyOpenGL matters.

Re: [PyOpenGL-Users] Pygame surfaces as PyOpenGL textures?

[Jan E. <ch...@in...>]

On Mon, 12 Nov 2001, Richard Jones wrote:

>On Sun, 11 Nov 2001 23:26, Jan Ekholm wrote:
>> On Sun, 11 Nov 2001, Richard Jones wrote:
>> >There was a really useful article either on gamasutra or gamedev regarding
>> >texturing of landscapes. Number one tip is to blend - use a large texture
>> >that gives a change over a large area and then the smaller texture like
>> > the one you're currently using to give some finer detail. Makes the
>> > repetition of the finer detail texture much less apparent.
>>
>> Hmm, this sounds like a good idea. I'm a total newbie when it comes to
>> issues like this. Unfortunately I think that performance would suffer a
>> great deal from additional blending?
>
>Most 3d cards will do multitexturing with almost no performance hit.

Apparently my code runs ~40fps on a p300 with a vodoo3. Which is basically
good news.

>> Richard, I'll try your code tomorrow when I get back to the machine where
>> I installed pyopengl. Do you happen to have access to a png where the
>> alpha channel definitely works with your code? Could make it easier to
>> debug if I know the file is absolutely ok.
>
>Attached. It's not very good (should be white), but it does have the 
>transparency :)

Hmm, it doesn't look ok either. I get either a white rectangle and
something yellowish with the "flare" in the middle.

-- 
                 "Students?" barked the Archchancellor.
    "Yes, Master. You know? They're the thinner ones with the pale faces?
  Because we're a university? They come with the whole thing, like rats --"
                                         -- Terry Pratchett, Moving Pictures

Re: [PyOpenGL-Users] Pygame surfaces as PyOpenGL textures?

[Richard J. <ric...@op...>]

On Sun, 11 Nov 2001 23:26, Jan Ekholm wrote:
> On Sun, 11 Nov 2001, Richard Jones wrote:
> >There was a really useful article either on gamasutra or gamedev regarding
> >texturing of landscapes. Number one tip is to blend - use a large texture
> >that gives a change over a large area and then the smaller texture like
> > the one you're currently using to give some finer detail. Makes the
> > repetition of the finer detail texture much less apparent.
>
> Hmm, this sounds like a good idea. I'm a total newbie when it comes to
> issues like this. Unfortunately I think that performance would suffer a
> great deal from additional blending?

Most 3d cards will do multitexturing with almost no performance hit.


> Richard, I'll try your code tomorrow when I get back to the machine where
> I installed pyopengl. Do you happen to have access to a png where the
> alpha channel definitely works with your code? Could make it easier to
> debug if I know the file is absolutely ok.

Attached. It's not very good (should be white), but it does have the 
transparency :)


    Richard

Re: [PyOpenGL-Users] Pygame surfaces as PyOpenGL textures?

[Jan E. <ch...@in...>]

On Sun, 11 Nov 2001, Richard Jones wrote:

>On Sat, 10 Nov 2001 22:59, Jan Ekholm wrote:
>> Hi,
>>
>> Well, I got bitten by the OpenGL bug, and did some small tests with
>> pygame and pyopengl. All works just fine, and speed of development is way
>> faster than with C/C++.
>>
>> Did a small terrain rendering that is both slow and ugly, but which seems
>> to do what it should do. See a snapshot at:
>>
>> 	http://www.infa.abo.fi/~chakie/cm/snapshot4.jpg
>
>There was a really useful article either on gamasutra or gamedev regarding 
>texturing of landscapes. Number one tip is to blend - use a large texture 
>that gives a change over a large area and then the smaller texture like the 
>one you're currently using to give some finer detail. Makes the repetition of 
>the finer detail texture much less apparent.

Hmm, this sounds like a good idea. I'm a total newbie when it comes to
issues like this. Unfortunately I think that performance would suffer a
great deal from additional blending?

My ultimate goal with this project is to see if it is feasible to build
something like the terrain in Combat Mission (my favourite game) in pygame
and pyopengl. After a year or so (if all works) I'd change the terrain
rendering in our game from the current 2D to this 3D engine. See a few
shots at:

	http://www.combatmission.com/mods/grass.asp

Richard, I'll try your code tomorrow when I get back to the machine where
I installed pyopengl. Do you happen to have access to a png where the
alpha channel definitely works with your code? Could make it easier to
debug if I know the file is absolutely ok.

-- 
    - "Remember -- that which does not kill us can only make us stronger."
    - "And that which does kill us leaves us dead!"
                                           -- Terry Pratchett, Carpe Jugulum

Re: [PyOpenGL-Users] Pygame surfaces as PyOpenGL textures?

[Richard J. <ric...@op...>]

On Sat, 10 Nov 2001 22:59, Jan Ekholm wrote:
> Has anybody done this before? I looked at NeHe:s tutorials, where the
> above code partially comes from, but he uses "pil" for loading the images,
> and I found no way to set transparency using that. Pil didn't seem to like
> any kinds of images that has an alpha channel in the image, which was the
> reason for trying to it using pygame.

PIL honours the alpha channel in images just fine. Here's the relevant code 
from one of my object's __init__ method (complete class is attached):

        # texture
        self.texture = Image.open('point_64.png')
        ix, iy = self.texture.size
        image = self.texture.tostring("raw", "RGBA", 0, -1)
        self.pointtex = glGenTextures(1)
        glBindTexture(GL_TEXTURE_2D, self.pointtex)
        glPixelStorei(GL_UNPACK_ALIGNMENT,1)
        glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, ix, iy, 0, GL_RGBA,
            GL_UNSIGNED_BYTE, image)

and then in the draw() method:

    def draw(self, world):
        glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR)
        glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST)
        glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE)
        glBlendFunc(GL_SRC_ALPHA, GL_ONE);
        glEnable(GL_BLEND)
        glDisable(GL_DEPTH_TEST)
        glEnable(GL_TEXTURE_2D)
        glBindTexture(GL_TEXTURE_2D, self.pointtex)
        glDisable(GL_LIGHTING)
        glColor(1, 1, 1)
        glBegin(GL_QUADS)
        for life, position, velocity, colour in self.points:
            if colour[3] <= 0: continue
            glColor4f(*colour)
            x, y, z = position
            glTexCoord2f(0, 0)
            glVertex3f(x, y, z)
            glTexCoord2f(1, 0)
            glVertex3f(x+4, y, z)
            glTexCoord2f(1, 1)
            glVertex3f(x+4, y+4, z)
            glTexCoord2f(0, 1)
            glVertex3f(x, y+4, z)
        glEnd()
        glEnable(GL_LIGHTING)
        glEnable(GL_DEPTH_TEST)
        glDisable(GL_BLEND)
        glDisable(GL_TEXTURE_2D)

(sorry about the complete lack of commenting :)

Also, the code attached isn't very optimised. I'm still learning OpenGL, no 
time to make it fast or pretty :)


     Richard

Re: [PyOpenGL-Users] Pygame surfaces as PyOpenGL textures?

[Richard J. <ric...@op...>]

On Sat, 10 Nov 2001 22:59, Jan Ekholm wrote:
> Hi,
>
> Well, I got bitten by the OpenGL bug, and did some small tests with
> pygame and pyopengl. All works just fine, and speed of development is way
> faster than with C/C++.
>
> Did a small terrain rendering that is both slow and ugly, but which seems
> to do what it should do. See a snapshot at:
>
> 	http://www.infa.abo.fi/~chakie/cm/snapshot4.jpg

There was a really useful article either on gamasutra or gamedev regarding 
texturing of landscapes. Number one tip is to blend - use a large texture 
that gives a change over a large area and then the smaller texture like the 
one you're currently using to give some finer detail. Makes the repetition of 
the finer detail texture much less apparent.


   Richard

RE: [PyOpenGL-Users] Newbie problem: undefined symbol: glXBindChannelToWindowSGI

[Tarn W. B. <twb...@us...>]

This really isn't a PyOpenGL problem, but a GLUT problem.  It should be
reproducable by just typing "import OpenGL.GL" at the Python prompt.  It
looks like the functions glutSetupVideoResizing and glutStopVideoResizing
will use the GLX_SGIX_video_resize extension if it is declared by gl.h
header that GLUT is compiled against, but your GLUT lib can't seem to find
the symbol at runtime.  The only thing that I can think to do is recompile
GLUT against your current GLX install.  To get the current version of GLUT
see http://www.opengl.org/developers/documentation/glut.html

If you do this be sure to recompile PyOpenGL with a "python setup.py
build -f"

Tarn

[PyOpenGL-Users] Pygame surfaces as PyOpenGL textures?

[Jan E. <ch...@in...>]

Hi,

Well, I got bitten by the OpenGL bug, and did some small tests with
pygame and pyopengl. All works just fine, and speed of development is way
faster than with C/C++.

Did a small terrain rendering that is both slow and ugly, but which seems
to do what it should do. See a snapshot at:

	http://www.infa.abo.fi/~chakie/cm/snapshot4.jpg

However, no terrain without trees. Simple trees are easiest to do with a
single billboarded texture. It does need to be partially transparent
though. So, the problem is how I can get pyopengl to use a texture that is
partially transparent. Ideally I'd like to use simple colorkey
transparency, i.e. set a color as transparent. That part works nicely
in pygame. I can do this:

    surface = pygame.image.load ( 'tree.bmp' )
    surface.set_colorkey ( (255, 0, 255) )

to set magenta as transparent. Works fine as long as blitted within
pygame. To create a texture I use the folloing black magic:

    # convert to a string
    image = pygame.image.tostring ( surface, "RGBA" )
    ix, iy = surface.get_size ()
 
    # generate a texture id
    tree = glGenTextures(1)
    glBindTexture(GL_TEXTURE_2D, tree )

    # do some Rocket Science(tm)
    glPixelStorei(GL_UNPACK_ALIGNMENT,1)
    glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER,GL_LINEAR)
    glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_NEAREST)
    gluBuild2DMipmaps(GL_TEXTURE_2D, 4, ix, iy, GL_RGBA, GL_UNSIGNED_BYTE, image)

Now, this works quite fine, but no transparency is still visible. Before
rendering the quads for the trees I do the following spells:

    glEnable(GL_BLEND)
    glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)

Depending on how I fiddle with all kinds of parameters I end up with
either trees with magenta borders (no transparency) or then just a few
pixels visible (too much transparency). :)

Has anybody done this before? I looked at NeHe:s tutorials, where the
above code partially comes from, but he uses "pil" for loading the images,
and I found no way to set transparency using that. Pil didn't seem to like
any kinds of images that has an alpha channel in the image, which was the
reason for trying to it using pygame.

I know I do something very wrong here, but it's very easy as OpenGL
texture handling is a deep, deep swamp until you have learnt the rules of
the game.

Apart from this little problem the rendering was way faster than I thought
it would be. Loading data from disk and doing normal calculations is a bit
slow, but that's done only once. By using display lists heavily I have
IMHO quite ok performance when doing software rendering only. I don't
think my old G450 can even do 3D, and at least not on Linux. A feature I
like very much with pyopengl is that it reports errors, i.e. when I try to
do something illegal in, say, a glBegin(GLFOO) I get a stack trace if I do
something that's not allowed. In C/C++ I have to manually check the error
flag after each call to see if something is wrong.

Regards,
    Chakie

-- 

              Many an ancient lord's last words had been:
         "You can't kill me because I've got magic aaargh...."
                                      -- Terry Pratchett, Interesting Times

[PyOpenGL-Users] Newbie problem: undefined symbol: glXBindChannelToWindowSGI

[Craig H . A. <cr...@ho...>]

On a Mandrake 8.1 Linux system

=== Installed Mesa 4.0 from Mandrake cooker
rpm --upgrade \
    Mesa-4.0-1mdk.i586.rpm \
    Mesa-demos-4.0-1mdk.i586.rpm \
    libMesaGL1-4.0-1mdk.i586.rpm \
    libMesaGLU1-4.0-1mdk.i586.rpm \
    libMesaGLU1-devel-4.0-1mdk.i586.rpm \
    libMesaglut3-4.0-1mdk.i586.rpm \
    libMesaglut3-devel-4.0-1mdk.i586.rpm

Mesa demos run.

===  Installed PyOpenGL-2.0.0.44
rpm -ivh PyOpenGL-2.0.0.44.py2-1.src.rpm
rpm -bb /usr/src/RPM/SPECS/PyOpenGL.spec
rpm --upgrade /usr/src/RPM/RPMS/i586/PyOpenGL-2.0.0.44-1.i586.rpm

=== Try a demo
$ /usr/lib/python2.1/site-packages/OpenGL/Demo/simple/GLE.py
Traceback (most recent call last):
  File "./GLE.py", line 10, in ?
    from OpenGL.GLUT import *
ImportError: /usr/X11R6/lib/libglut.so.3: undefined symbol:
glXBindChannelToWindowSGI

-- 
Craig H. Anderson

[PyOpenGL-Users] RE: [PyOpenGL] PyOpenGL 2 final available!

[Tarn W. B. <twb...@us...>]

| Talking of PyOpenGL-2.0.0.44, there is a small mistake in
| 
| 	setup/dist.py
| 
| line 100 should be
| 
| 			self.HAS_NUMERIC = 0
| 
| instead of
| 
| 			self.NUMERIC = 0
| 
| This only happens when Numeric is not installed otherwise your package
| builds (and works) beautifully! Thanks for such a GREAT JOB!
| 

thanks, fixed in CVS.

Tarn

RE: [PyOpenGL-Users] Python 2.0?

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

Hmm, thought I'd fixed the wall.bmp thing.  Guess not.  Not sure why
distutils is splitting the data files out :( .  Guess I'll have to look into
that.  Sometimes I feel like distutils is entirely too sophisticated for its
own good.  Why in my day we'd just dump a tar-ball in the Python directory,
and doggone it, we liked it that way! :o)

Enjoy all,
Mike

-----Original Message-----
From: pyo...@li...
[mailto:pyo...@li...]On Behalf Of Jan
Ekholm
Sent: Friday, November 02, 2001 15:32
To: PyOpenGL-Users
Subject: RE: [PyOpenGL-Users] Python 2.0?
...
* after doing an install I ended up with a directory /usr/OpenGLContext
which contained the dirs "docs" and "test". The former contained a few
html files and a css file, the latter some images (no .py files). I moved
them to /usr/lib/python2.0/site-packages/OpenGLContext along with the rest
of the samples.

* at least one of the samples tries to load a texture which is referenced
to as an uppercase filename, such as WALL.BMP (don't remember the exact
name, but I can check it up). The file on disk was wall.bmp. Loading that
file works on limited systems that aren't able to distinguish between
case, such as Windows, but on samrter systems it fails. This is no problem
at all, as the tests are just that: test programs.
...

RE: [PyOpenGL-Users] Python 2.0?

[Tarn W. B. <twb...@us...>]

See the Mesa notes at
http://sourceforge.net/project/shownotes.php?group_id=5988&release_id=50914

Tarn

Re: [PyOpenGL-Users] Python 2.0?

[Jan E. <ch...@in...>]

On Fri, 2 Nov 2001, Antti Korvenoja wrote:

>Quoting Jan Ekholm <ch...@in...>:
>
>> I'm using Debian woody, and it still has 2.0, and I don't want to
>> manually
>> upgrade to 2.1. Is there any way around this? Why does Python have to be
>Have you considered installing Python 2.1 from unstable release? There is even
>2.2beta1 debian package in unstable.

Yep, I have, and do, I won't. Unstable is unstable is unstable. Python is
very important for my daily stuff, and if it breaks I'm basically screwed.

Anyway, I've given up already. 

-- 

              Many an ancient lord's last words had been:
         "You can't kill me because I've got magic aaargh...."
                                      -- Terry Pratchett, Interesting Times

Re: [PyOpenGL-Users] Python 2.0?

[Antti K. <ant...@he...>]

Quoting Jan Ekholm <ch...@in...>:

> I'm using Debian woody, and it still has 2.0, and I don't want to
> manually
> upgrade to 2.1. Is there any way around this? Why does Python have to be
Have you considered installing Python 2.1 from unstable release? There is even
2.2beta1 debian package in unstable.
-Antti Korvenoja

RE: [PyOpenGL-Users] Python 2.0?

[Jan E. <ch...@in...>]

On Fri, 2 Nov 2001, Tarn Weisner Burton wrote:

>| Won't that fubar my current Python installation?
>
>Nope.

Ok, thanks. Building now recognizes the new distitils and starts
compiling. Actually it compiles a fair deal of files (ok, I had to add a
symlink /usr/X11 -> /usr/X11R6 to proceed), but stumbles on this error
later on:

% python setup.py build
...<lots of output>...


gcc -g -O2 -Wall -Wstrict-prototypes -fPIC -fPIC -DGLX_PLATFORM -DNUMERIC
-I/usr/include -I/usr/local/include -I/usr/X11/include
-I/usr/include/python2.0/Numeric -Isrc/gle/src -I/usr/include/python2.0 -c
src/interface/GLU.__init___.c -o build/temp.linux-i686-2.0/GLU.__init___.o
In file included from src/interface/GLU.__init___.c:9:
src/interface/GLU.__init___.0102.inc: In function `SWIG_ConvertPtr':
src/interface/GLU.__init___.0102.inc:361: warning: suggest explicit braces
  to avoid ambiguous `else'
src/interface/GLU.__init___.0102.inc:364: warning: suggest explicit braces
  to avoid ambiguous `else'
src/interface/GLU.__init___.0102.inc:380: warning: suggest explicit braces
  to avoid ambiguous `else'
src/interface/GLU.__init___.0102.inc: At top level:
src/interface/GLU.__init___.0102.inc:676: warning: function declaration
  isn't a prototype
src/interface/GLU.__init___.0102.inc:722: warning: function declaration
  isn't a prototype
src/interface/GLU.__init___.0102.inc:770: warning: function declaration
  isn't a prototype
src/interface/GLU.__init___.0102.inc:1007: parse error before `GLUquadric'


On that position in the file there's this definition:

1004 typedef struct
1005 {
1006     PyObject_HEAD
1007     GLUquadric *obj;
1008     PyObject *begin, *beginData, *edgeFlag, *edgeFlagData,*vertex, *vertexData;
1009     PyObject *end, *endData, *combine, *combineData;
1010 } PyGLUquadric;

So apparently GLUquadric can't be found. The file was apparently generated
by swig. I have this verison of swig:

% swig -version
 
SWIG Version 1.1 (Build 883)
Copyright (c) 1995-98
University of Utah and the Regents of the University of California
 
Compiled with c++


Here my detective skills come to an end. Seems like PyObject_HEAD isn't
defined or is wrong. The symbol is defined in my
/usr/include/python2.0/object.h, and looks ok to me.

Well, I don't think it's worth my time at this point to try to get
PyOpenGL to work. Apparently this Debian box just isn't "right in the
head" wrt to Python development. :)

Thanks for all the help, I look forward to the day when I can just do a
"apt-get install pyopengl".

-- 

 He says gods like to see an atheist around. Gives them something to aim at.
                                            -- Terry Pratchett, Small Gods

RE: [PyOpenGL-Users] Python 2.0?

[Tarn W. B. <twb...@us...>]

| Won't that fubar my current Python installation?

Nope.


Tarn

RE: [PyOpenGL-Users] Python 2.0?

[Jan E. <ch...@in...>]

On Fri, 2 Nov 2001, Tarn Weisner Burton wrote:

>| I wanted to try pyopengl and fiddle with some OpenGL again. I did not get
>| the newest version installed, as it seems to require Python 2.1. Or more
>| specifically it requires distutils >= 1.02, which Python 2.0 does not
>| have. 
>
>Just get the newest distutils and install that.
>
>http://www.pythonlabs.com/sigs/distutils-sig/

Won't that fubar my current Python installation?

-- 

 He says gods like to see an atheist around. Gives them something to aim at.
                                            -- Terry Pratchett, Small Gods

RE: [PyOpenGL-Users] Python 2.0?

[Tarn W. B. <twb...@us...>]

| I wanted to try pyopengl and fiddle with some OpenGL again. I did not get
| the newest version installed, as it seems to require Python 2.1. Or more
| specifically it requires distutils >= 1.02, which Python 2.0 does not
| have. 

Just get the newest distutils and install that.

http://www.pythonlabs.com/sigs/distutils-sig/


Tarn

[PyOpenGL-Users] Python 2.0?

[Jan E. <ch...@in...>]

Hi all,

I wanted to try pyopengl and fiddle with some OpenGL again. I did not get
the newest version installed, as it seems to require Python 2.1. Or more
specifically it requires distutils >= 1.02, which Python 2.0 does not
have. 

I'm using Debian woody, and it still has 2.0, and I don't want to manually
upgrade to 2.1. Is there any way around this? Why does Python have to be
so crappy wrt installing additional 3rd party modules, especially compared
to Perl. :(

Anyway, it seems like pyopengl is a really nice package, and I look
forward to trying it with pygame. If the only possibility is doing an
upgrade then I assume I'll have to wait a few months/years or so. :)

Regards,
    Chakie

-- 

 He says gods like to see an atheist around. Gives them something to aim at.
                                            -- Terry Pratchett, Small Gods

RE: [PyOpenGL-Users] PyOpenGL on Mac OS9

[Tarn W. B. <twb...@us...>]

PyOpenGL2 hasn't been ported to the Mac yet, although this is mostly a
distutils issue.  Several distutils.config methods need to be written in
order for the setup script to work.

Tarn

[PyOpenGL-Users] PyOpenGL on Mac OS9

[Chris S. <ka...@ma...>]

I'm a bit confused, should this work on OS9, or not? If it should, I'm
having problems with installation and could use some help. If it shouldn't,
I'll leave everyone alone and sit waiting patiently for it to be ready.
Thanks.
- Chris

RE: [PyOpenGL-Users] Import errors

[Tarn W. B. <twb...@us...>]

| I'm new to this list, but didn't find anything in the archives on this
| topic. I have python 2.1 (win98; ugh) and downloaded
| PyOpenGL-2.0.0.44.win32.py2.1.exe.  But when using this version, I'm
| getting an "ImportError: Module use of python20.dll conflicts with this
| version of Python." message when using GLU or GLUT. Am I missing something
| here? Or was there perhaps an inadvertent link error of some sort?

This is most likely an installation problem.  Have you installed previous
versions of PyOpenGL?  Aside from that the next most likely thing is a
munged up Python install.  The last time I heard about a problem like this
was on Win2K in which the admin had a different version Python than the
user.  Obviously not the problem on Win98, but I something similar might be
happening, i.e. check the Python registry keys.

Tarn

[PyOpenGL-Users] Import errors

[Gary S. <st...@nm...>]

Hi all,

I'm new to this list, but didn't find anything in the archives on this
topic. I have python 2.1 (win98; ugh) and downloaded
PyOpenGL-2.0.0.44.win32.py2.1.exe.  But when using this version, I'm
getting an "ImportError: Module use of python20.dll conflicts with this
version of Python." message when using GLU or GLUT. Am I missing something
here? Or was there perhaps an inadvertent link error of some sort?

Gary
st...@nm...

RE: [PyOpenGL-Users] Where are the Histogram functions?

[Tarn W. B. <twb...@us...>]

| Is there a llist somewhere showing what has been implemented and
| what has not?
| I was happy to see glHistogram mentioned in the documentation. But unhappy
| to hear it didnt exist!

Try using pydoc.  OpenGL 1.0 and 1.1 is fully supported.  No OpenGL 1.2
support yet.


Tarn

Re: [PyOpenGL-Users] Where are the Histogram functions?

[Mathew Y. <ma...@fu...>]

Is there a llist somewhere showing what has been implemented and what has not?
I was happy to see glHistogram mentioned in the documentation. But unhappy
to hear it didnt exist!

Mathew

> Histogram functions are not supported yet.  The code that you see in the
> interface file is in fact commented out.
> 
> Tarn
> 
> 
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users

[PyOpenGL-Users] Very slow DrawPixels

[Mathew Y. <ma...@fu...>]

The current implementation of DrawPixels (using Numeric) is very slow when 
arbitrary
sub rectangles from a large array are to be displayed. Instead  of this,
I first make sure that may array is contigous and then
in DrawPixelsus I use 

glPixelStorei(GL_UNPACK_SKIP_ROWS,starty);
        glPixelStorei(GL_UNPACK_SKIP_PIXELS,startx);
        glPixelStorei(GL_UNPACK_ROW_LENGTH,cols);

and just pass a pointer to my arrays data.
MUCH faster.

Mathew