Re: [pygame] PyOpenGL and pygame.display.flip

[sylvain.boussekey]

Oops I hate when I search hours to find an answer and find it right 
when posting to a forum or mailing list !


I was just calling pygame.init() in another module than 
pygame.display.flip() and was doing a pygame.display.set_mode() 
elsewhere too without using DOUBLEBUFF flag.


I'm not sure to quite understand what've done here but it surely comes 
from the fact my pygame.display thing are not at the same place as my 
first import pygame.



Le 2014-11-25 11:10, sylvain.boussekey a écrit :

Hi everyone,

I'm running into difficulties when using an opengl window in pygame.
For reasons I don't catch, sometimes, when I draw quads with 
pyopengl,

I have to call pygame.display.flip to actually display anything, and
sometimes, I don't, resulting in a blinking horrific mess when I draw
multiple quads overlapping themselves.

I really don't know when it happen but it does in one project, not in
one another. Can't tell the difference...

I'm using flags OPENGL | DOUBLEBUF | HWSURFACE for my pygame window

Here's what I execute at the beginning of my drawing state :

def clear():
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT)

And here's my function to draw quads :

def drawtexturedquad(imgid, pos, proj=True, siz=(1, 1), r=1.0, g=1.0,
b=1.0, alpha=1.0):
if proj:
glMatrixMode(GL_MODELVIEW)
else:
glMatrixMode(GL_PROJECTION)

glLoadIdentity()
glPushMatrix()
glEnable(GL_TEXTURE_2D)
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)

glTranslated(-1, -1, 0)
glTranslated(pos[0], pos[1], 0)
glScalef(siz[0], siz[1], 1)

glColor4f(r, g, b, alpha)

glBindTexture(GL_TEXTURE_2D, imgid)

glBegin(GL_QUADS)

glTexCoord2f(0.0, 1.0)
glVertex2f(-1.0, 1.0)

glTexCoord2f(1.0, 1.0)
glVertex2f(1.0, 1.0)

glTexCoord2f(1.0, 0.0)
glVertex2f(1.0, -1.0)

glTexCoord2f(0.0, 0.0)
glVertex2f(-1.0, -1.0)

glEnd()
glPopMatrix()
glFlush()

[pygame] PyOpenGL and pygame.display.flip

[sylvain.boussekey]

Hi everyone,

I'm running into difficulties when using an opengl window in pygame. 
For reasons I don't catch, sometimes, when I draw quads with pyopengl, I 
have to call pygame.display.flip to actually display anything, and 
sometimes, I don't, resulting in a blinking horrific mess when I draw 
multiple quads overlapping themselves.


I really don't know when it happen but it does in one project, not in 
one another. Can't tell the difference...


I'm using flags OPENGL | DOUBLEBUF | HWSURFACE for my pygame window

Here's what I execute at the beginning of my drawing state :

def clear():
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT)

And here's my function to draw quads :

def drawtexturedquad(imgid, pos, proj=True, siz=(1, 1), r=1.0, g=1.0, 
b=1.0, alpha=1.0):

if proj:
glMatrixMode(GL_MODELVIEW)
else:
glMatrixMode(GL_PROJECTION)

glLoadIdentity()
glPushMatrix()
glEnable(GL_TEXTURE_2D)
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)

glTranslated(-1, -1, 0)
glTranslated(pos[0], pos[1], 0)
glScalef(siz[0], siz[1], 1)

glColor4f(r, g, b, alpha)

glBindTexture(GL_TEXTURE_2D, imgid)

glBegin(GL_QUADS)

glTexCoord2f(0.0, 1.0)
glVertex2f(-1.0, 1.0)

glTexCoord2f(1.0, 1.0)
glVertex2f(1.0, 1.0)

glTexCoord2f(1.0, 0.0)
glVertex2f(1.0, -1.0)

glTexCoord2f(0.0, 0.0)
glVertex2f(-1.0, -1.0)

glEnd()
glPopMatrix()
glFlush()

[pygame] the pygame/pyopengl sprint has started

[René Dudfield]

Hey,

it's in spaghetti, and on irc.  There's a hat/sign on the table in
spaghetti.

Re: [pygame] Blog posts on a pygame+pyopengl project

[Jake b]

Cool! I missed this email. I like the images, and diagrams.

Are you planning on ability to edit or create a new world?



Have you thought of doing a Terarria map viewer? (It's similar in a lot of
ways, but from the side view its 2d only.)

I found a few python interfaces to the map file:

   -
   
http://www.terrariaonline.com/threads/programmerss-resource-python-interface-for-world-files.33032/
   - Details on map file format:
   
http://www.terrariaonline.com/threads/map-format-documentation.16553/#post-232921
   - python map generator:
   https://bitbucket.org/cryzed/terraria-map-generator/src
   - output image of viewer world:
   
http://www.terrariaonline.com/threads/python-world-viewer-windows-mac-linux.33725/
   - pixel-ly panning viewer:
   http://www.terrariaonline.com/threads/terraria-map-viewer.4226/

-- 
Jake

[pygame] Blog posts on a pygame+pyopengl project

[Weeble]

This was already retweeted by @pygame_org, but at the time none of the
actual articles were up. I'm writing a series of blog posts on a
Minecraft map viewer that I've been writing using Pygame, PyOpenGL and
numpy. I thought it might be of interest to others dabbling in
PyOpenGL with Pygame.

http://clockworkcodex.blogspot.com/2011/05/minecraft-mapping-with-python-pygame.html

Re: [pygame] (pyopengl) GLSL fragment shader with arrays uniform cause sporadic screen blinking

[Devon Scott-Tunkin]

My laptop also has a 945gm so I can't test this until I get to my desktop
(although glsl shaders will work on os x with a 945gm, intel only supports
arb shaders in windows opengl).

The http://bpaste.net/show/13617/ is not the same because the glsl compiler
will usually compile out (make inactive) all of your uniforms since you
aren't referencing them in the shader. I often find this very annoying for
testing.  I've often had problems with arrays in glsl, and never got them to
work correctly in os x. You could try using a 1D texture lookup if the
arrays are the problem.

I don't really understand what you are trying to do in your pixel shader,
you could get rid of all of the else's and just put gl_FragColor at the end
of main and it would have the same effect. Your loop just changes the final
uv, so in effect you don't even need a for loop because your code will
always just make the end color by using imax-1. Everything else gets
overwritten.

Devon

On Fri, Feb 11, 2011 at 12:37 PM, amdlintuxo  wrote:

> Hi all.
>
> Strange sporadic screen blinking when using array uniform variables in
> fragment shader.
> Unfortunately i have only one HW config to test this(maybe the problem
> is in my HW)
>
> The strange is:
> The problem occurs with shader
> http://bpaste.net/show/13616/
> even if i pass empty arrays into it (imax = 0), so actually shader
> should do any distortion work.
>
> And the problem DOES NOT occur with shader
> http://bpaste.net/show/13617/
>
> So it has to be something in my shader, but i was thought that code
> http://bpaste.net/show/13617/ is the same as (http://bpaste.net/show/
> 13616/ + if imax = 0)
> But why screen blinking occurs? Actually without uniform arrays, by
> passing only simple uniform shader works great.
>
> Full code is here:
> http://bpaste.net/show/13615/
>
> Could some one test the full code or provide the idea what can cause
> sporadic screen blinking.
> Looking forwards for you support, i have nothing left to try to
> resolve this problem, struggling third day, no luck. Maybe this
> blinking is my HW config problem.
>

Re: [pygame] (pyopengl) GLSL fragment shader with arrays uniform cause sporadic screen blinking

[claudio canepa]

On Fri, Feb 11, 2011 at 5:01 PM, claudio canepa  wrote:

>
>
> On Fri, Feb 11, 2011 at 3:37 PM, amdlintuxo  wrote:
>
>>
>>
>> Full code is here:
>> http://bpaste.net/show/13615/
>>
>> Could some one test the full code or provide the idea what can cause
>> sporadic screen blinking.
>> Looking forwards for you support, i have nothing left to try to
>> resolve this problem, struggling third day, no luck. Maybe this
>> blinking is my HW config problem.
>>
>
> Whit the full code I got
>
> Traceback (most recent call last):
>   File "E:\incomplete copia sempron sancle 2010 04
> 30\scode\shader_test\shader.py", line 32, in glLibTestErrors
> function()
>   File "E:\incomplete copia sempron sancle 2010 04
> 30\scode\shader_test\shader.py", line 181, in main
> tex0, (_w,_h) = upload_texture('data/screenshot.png', True)
>   File "E:\incomplete copia sempron sancle 2010 04
> 30\scode\shader_test\shader.py", line 72, in upload_texture
> data )
> File "C:\Python26\lib\site-packages\OpenGL\latebind.py", line 45, in
> __call__
> return self._finalCall( *args, **named )
>   File "C:\Python26\lib\site-packages\OpenGL\wrapper.py", line 791, in
> wrapperCall
>   raise errGLError: GLError(
> err = 1281,
> description = 'valor no v\xe1lido',
> baseOperation = glTexImage2D,
> pyArgs = (
> GL_TEXTURE_2D,
> 0,
> 4,
> 640,
> 576,
> 0,
> GL_RGBA,
> GL_UNSIGNED_BYTE,
> '\x8d\x8e\xbc\xff\x8d\x8e\xbc\xff\x8d...,
> ),
> cArgs = (
> GL_TEXTURE_2D,
> 0,
> 4,
> 640,
> 576,
> 0,
> GL_RGBA,
> GL_UNSIGNED_BYTE,
> '\x8d\x8e\xbc\xff\x8d\x8e\xbc\xff\x8d...,
> ),
> cArguments = (
> GL_TEXTURE_2D,
> 0,
> 4,
> 640,
> 576,
> 0,
> GL_RGBA,
> GL_UNSIGNED_BYTE,
> '\x8d\x8e\xbc\xff\x8d\x8e\xbc\xff\x8d...,
> )
> )
>
>
> windows xp, python 2.6.5,
> I provided a 640 x  576 data\screenshot.png
>
> >>> OpenGL.version.__version__
> '3.0.1'
> >>>
>
> --
> claudio
>
>
>
after resampling to power of two (512 x 512) it passes that point, but seems
that this test machine (vga = intel 945g ) don't supports the funcionality:
I got
Traceback (most recent call last):
  File "E:\incomplete copia sempron sancle 2010 04
30\scode\shader_test\shader.py", line 32, in glLibTestErrors
function()
  File "E:\incomplete copia sempron sancle 2010 04
30\scode\shader_test\shader.py", line 239, in main
''')
  File "E:\incomplete copia sempron sancle 2010 04
30\scode\shader_test\shader.py", line 101, in compile_program
program = glCreateProgram()
File "C:\Python26\lib\site-packages\OpenGL\platform\baseplatform.py", line
340
, in __call__
self.__name__, self.__name__,
NullFunctionError: Attempt to call an undefined function
glCreateProgramObjectARB, check for bool(glCreateProgramObjectARB) before
calling

--
claudio

Re: [pygame] (pyopengl) GLSL fragment shader with arrays uniform cause sporadic screen blinking

[claudio canepa]

On Fri, Feb 11, 2011 at 3:37 PM, amdlintuxo  wrote:

>
>
> Full code is here:
> http://bpaste.net/show/13615/
>
> Could some one test the full code or provide the idea what can cause
> sporadic screen blinking.
> Looking forwards for you support, i have nothing left to try to
> resolve this problem, struggling third day, no luck. Maybe this
> blinking is my HW config problem.
>

Whit the full code I got

Traceback (most recent call last):
  File "E:\incomplete copia sempron sancle 2010 04
30\scode\shader_test\shader.py", line 32, in glLibTestErrors
function()
  File "E:\incomplete copia sempron sancle 2010 04
30\scode\shader_test\shader.py", line 181, in main
tex0, (_w,_h) = upload_texture('data/screenshot.png', True)
  File "E:\incomplete copia sempron sancle 2010 04
30\scode\shader_test\shader.py", line 72, in upload_texture
data )
File "C:\Python26\lib\site-packages\OpenGL\latebind.py", line 45, in
__call__
return self._finalCall( *args, **named )
  File "C:\Python26\lib\site-packages\OpenGL\wrapper.py", line 791, in
wrapperCall
  raise errGLError: GLError(
err = 1281,
description = 'valor no v\xe1lido',
baseOperation = glTexImage2D,
pyArgs = (
GL_TEXTURE_2D,
0,
4,
640,
576,
0,
GL_RGBA,
GL_UNSIGNED_BYTE,
'\x8d\x8e\xbc\xff\x8d\x8e\xbc\xff\x8d...,
),
cArgs = (
GL_TEXTURE_2D,
0,
4,
640,
576,
0,
GL_RGBA,
GL_UNSIGNED_BYTE,
'\x8d\x8e\xbc\xff\x8d\x8e\xbc\xff\x8d...,
),
cArguments = (
GL_TEXTURE_2D,
0,
4,
640,
576,
0,
GL_RGBA,
GL_UNSIGNED_BYTE,
'\x8d\x8e\xbc\xff\x8d\x8e\xbc\xff\x8d...,
)
)


windows xp, python 2.6.5,
I provided a 640 x  576 data\screenshot.png

>>> OpenGL.version.__version__
'3.0.1'
>>>

--
claudio

[pygame] (pyopengl) GLSL fragment shader with arrays uniform cause sporadic screen blinking

[amdlintuxo]

Hi all.

Strange sporadic screen blinking when using array uniform variables in
fragment shader.
Unfortunately i have only one HW config to test this(maybe the problem
is in my HW)

The strange is:
The problem occurs with shader
http://bpaste.net/show/13616/
even if i pass empty arrays into it (imax = 0), so actually shader
should do any distortion work.

And the problem DOES NOT occur with shader
http://bpaste.net/show/13617/

So it has to be something in my shader, but i was thought that code
http://bpaste.net/show/13617/ is the same as (http://bpaste.net/show/
13616/ + if imax = 0)
But why screen blinking occurs? Actually without uniform arrays, by
passing only simple uniform shader works great.

Full code is here:
http://bpaste.net/show/13615/

Could some one test the full code or provide the idea what can cause
sporadic screen blinking.
Looking forwards for you support, i have nothing left to try to
resolve this problem, struggling third day, no luck. Maybe this
blinking is my HW config problem.

[pygame] [pyopengl] glActiveTexture(GL_TEXTURE1) cause failure in my code, can't get the reason why

[amdlintuxo]

Hi all.

I was trying to play with GLSL multi-texturing and as usual the
problems don't want stay far away from me.
Now i get problem with Texture units.

glActiveTexture(GL_TEXTURE1) cause failure, i can't get the reason
why.
If i use only glActiveTexture(GL_TEXTURE0) then it's is OK, but in
this case i am able to transfer only one texture to fragment shader
with is not enough for multi-texturing.

glGetIntegerv(GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS_ARB) returns me 32,
also i checked this in
Also i found that all these works good on 
http://www.pygame.org/project-glLib+Reloaded-1326-.html
glLibShader.py, glLibTexturing.py, parallaxmapping.py[Tutorial]

I tried to compare and identify the difference in
glActiveTexture(GL_TEXTURE1 call and functions surround it , no luck,
probably the difference exist in some stage of init, but it is hard to
identify what exactly i missed.

Also code for quick look can be found here:
http://bpaste.net/show/13480/

The log of fault
[code]
Fragment shader(s) linked, vertex shader(s) linked.

1 -1
32
Traceback (most recent call last):
  File "GLSL_uniform_multitexturing_TMP.py", line 18, in
glLibTestErrors
function()
  File "GLSL_uniform_multitexturing_TMP.py", line 201, in main
glPopMatrix()
  File "/usr/lib/pymodules/python2.6/OpenGL/error.py", line 208, in
glCheckError
baseOperation = baseOperation,
GLError: GLError(
err = 1282,
description = 'invalid operation',
baseOperation = glPopMatrix,
cArguments = ()
)
[/code]

Thank for support in advance!

Re: [pygame] Pygame, PyOpenGl, and py2exe, OH MY!

[Casey Duncan]

What you are lacking is actually part of Python itself (or the stdlib):

Python 2.6.4 (r264:75821M, Oct 27 2009, 19:48:32) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes
>>> ctypes.pythonapi.PyString_AsString
<_FuncPtr object at 0x3697b0>

It might be that py2exe is unable to DWIM that you are using the 
ctypes.pythonapi subpackage.

Perhaps you need to add an 'import ctypes.pythonapi' to one of your modules 
(like the main one) or otherwise explicitly tell py2exe to include it?

-Casey

On Apr 22, 2010, at 8:08 PM, Keith Nemitz wrote:

> 
> I spent the day in py2exe hell. After grinding through six separate problems, 
> now I'm stuck. Has anyone got this combo to work? I'm using Python 2.6 and 
> Pygame 1.9.x and pyOpenGl 3.0.x and the latest py2exe. When I run the 
> resulting exe, I get the following runtime error:
> 
> Traceback (most recent call last):
>  File "main.py", line 29, in 
>  File "zipextimporter.pyo", line 82, in load_module
>  File "pygl2d\__init__.pyo", line 5, in 
>  File "zipextimporter.pyo", line 82, in load_module
>  File "pygl2d\window.pyo", line 3, in 
>  File ".\OpenGL\GL\__init__.py", line 2, in 
>from OpenGL.raw.GL import *
>  File ".\OpenGL\raw\GL\__init__.py", line 6, in 
>from OpenGL.raw.GL.constants import *
>  File ".\OpenGL\raw\GL\constants.py", line 7, in 
>from OpenGL import platform, arrays
>  File ".\OpenGL\arrays\__init__.py", line 22, in 
>formathandler.FormatHandler.loadAll()
>  File ".\OpenGL\arrays\formathandler.py", line 37, in loadAll
>cls.loadPlugin( entrypoint )
>  File ".\OpenGL\arrays\formathandler.py", line 44, in loadPlugin
>plugin_class = entrypoint.load()
>  File ".\OpenGL\plugins.py", line 14, in load
>return importByName( self.import_path )
>  File ".\OpenGL\plugins.py", line 28, in importByName
>module = __import__( ".".join(moduleName), {}, {}, moduleName)
>  File ".\OpenGL\arrays\strings.py", line 8, in 
>psas = ctypes.pythonapi.PyString_AsString
>  File "ctypes\__init__.pyo", line 366, in __getattr__
>  File "ctypes\__init__.pyo", line 371, in __getitem__
> AttributeError: function 'PyString_AsString' not found
> 
> 
> 
> 
> Here is the script I'm currently using, based on the pygame wiki script:
> 
> 
> # This will create a dist directory containing the executable file, all the 
> data
> # directories. All Libraries will be bundled in executable file.
> #
> # Run the build process by entering 'pygame2exe.py' or
> # 'python pygame2exe.py' in a console prompt.
> #
> # To build exe, python, pygame, and py2exe have to be installed. After
> # building exe none of this libraries are needed.
> 
> try:
>from distutils.core import setup
>import py2exe, pygame
>from modulefinder import Module
>import glob, fnmatch
>import sys, os, shutil
>import operator
> except ImportError, message:
>raise SystemExit,  "Unable to load module. %s" % message
> 
> #---HACK
> origIsSystemDLL = py2exe.build_exe.isSystemDLL
> def isSystemDLL(pathname):
>   if os.path.basename(pathname).lower() in 
> ["sdl_ttf.dll","sdl_mixer.dll","libogg-0.dll"]:
>   return 0
>   return origIsSystemDLL(pathname)
> py2exe.build_exe.isSystemDLL = isSystemDLL
> #---ENDHACK
> 
> 
> class pygame2exe(py2exe.build_exe.py2exe): #This hack make sure that pygame 
> default font is copied: no need to modify code for specifying default font
>def copy_extensions(self, extensions):
>#Get pygame default font
>pygamedir = os.path.split(pygame.base.__file__)[0]
>pygame_default_font = os.path.join(pygamedir, 
> pygame.font.get_default_font())
> 
>#Add font to list of extension to be copied
>extensions.append(Module("pygame.font", pygame_default_font))
>py2exe.build_exe.py2exe.copy_extensions(self, extensions)
> 
> class BuildExe:
>def __init__(self):
>#Name of starting .py
>self.script = "main.py"
> 
>#Name of program
>self.project_name = "Around"
> 
>#Project url
>self.project_url = "about:none"
> 
>#Version of program
>self.project_version = "0.0.0.1"
> 
>#License of the program
>self.license = "MyApps License"
> 
>#Auhor of program
>self.author_name = "Keith Nemitz"
>self.author_email = "musenik atya hoo doh com"
>self.copyright = "Copyright (c) 2010 Keith Nemitz. All rights 
> reserved."
> 
>#Description
>self.project_description = "..."
> 
>#Icon file (None will use pygame default icon)
>self.icon_file = None
> 
>#Extra files/dirs copied to game
>self.extra_datas = 
> ["data","OpenGL","extras/Microsoft.VC90.CRT.manifest",
>
> "extras/msvcm90.dll","extras/msvcp90.dll","extras/msvcr90.dll"]
> 
>#Extra/excludes python modules
>self.extra_modules = []
>self.exclude_m

Re: [pygame] Pygame, PyOpenGl, and py2exe, OH MY!

[James Paige]

pyopengl 3.0 is notoriously difficult to py2exe.

However, I was able to find this page, which suggests a possible 
solution:

http://blog.vrplumber.com/index.php?/archives/325-Got-py2exe-+-PyOpenGL-limping-across-the-line...-Need-to-add-the-.egg-files-to-the-path.html

---
James Paige

On Thu, Apr 22, 2010 at 07:08:43PM -0700, Keith Nemitz wrote:
> 
> I spent the day in py2exe hell. After grinding through six separate problems, 
> now I'm stuck. Has anyone got this combo to work? I'm using Python 2.6 and 
> Pygame 1.9.x and pyOpenGl 3.0.x and the latest py2exe. When I run the 
> resulting exe, I get the following runtime error:
> 
> Traceback (most recent call last):
>   File "main.py", line 29, in 
>   File "zipextimporter.pyo", line 82, in load_module
>   File "pygl2d\__init__.pyo", line 5, in 
>   File "zipextimporter.pyo", line 82, in load_module
>   File "pygl2d\window.pyo", line 3, in 
>   File ".\OpenGL\GL\__init__.py", line 2, in 
> from OpenGL.raw.GL import *
>   File ".\OpenGL\raw\GL\__init__.py", line 6, in 
> from OpenGL.raw.GL.constants import *
>   File ".\OpenGL\raw\GL\constants.py", line 7, in 
> from OpenGL import platform, arrays
>   File ".\OpenGL\arrays\__init__.py", line 22, in 
> formathandler.FormatHandler.loadAll()
>   File ".\OpenGL\arrays\formathandler.py", line 37, in loadAll
> cls.loadPlugin( entrypoint )
>   File ".\OpenGL\arrays\formathandler.py", line 44, in loadPlugin
> plugin_class = entrypoint.load()
>   File ".\OpenGL\plugins.py", line 14, in load
> return importByName( self.import_path )
>   File ".\OpenGL\plugins.py", line 28, in importByName
> module = __import__( ".".join(moduleName), {}, {}, moduleName)
>   File ".\OpenGL\arrays\strings.py", line 8, in 
> psas = ctypes.pythonapi.PyString_AsString
>   File "ctypes\__init__.pyo", line 366, in __getattr__
>   File "ctypes\__init__.pyo", line 371, in __getitem__
> AttributeError: function 'PyString_AsString' not found
> 
> 
> 
> 
> Here is the script I'm currently using, based on the pygame wiki script:
> 
> 
> # This will create a dist directory containing the executable file, all the 
> data
> # directories. All Libraries will be bundled in executable file.
> #
> # Run the build process by entering 'pygame2exe.py' or
> # 'python pygame2exe.py' in a console prompt.
> #
> # To build exe, python, pygame, and py2exe have to be installed. After
> # building exe none of this libraries are needed.
>  
> try:
> from distutils.core import setup
> import py2exe, pygame
> from modulefinder import Module
> import glob, fnmatch
> import sys, os, shutil
> import operator
> except ImportError, message:
> raise SystemExit,  "Unable to load module. %s" % message
> 
> #---HACK
> origIsSystemDLL = py2exe.build_exe.isSystemDLL
> def isSystemDLL(pathname):
>if os.path.basename(pathname).lower() in 
> ["sdl_ttf.dll","sdl_mixer.dll","libogg-0.dll"]:
>return 0
>return origIsSystemDLL(pathname)
> py2exe.build_exe.isSystemDLL = isSystemDLL
> #---ENDHACK
> 
> 
> class pygame2exe(py2exe.build_exe.py2exe): #This hack make sure that pygame 
> default font is copied: no need to modify code for specifying default font
> def copy_extensions(self, extensions):
> #Get pygame default font
> pygamedir = os.path.split(pygame.base.__file__)[0]
> pygame_default_font = os.path.join(pygamedir, 
> pygame.font.get_default_font())
>  
> #Add font to list of extension to be copied
> extensions.append(Module("pygame.font", pygame_default_font))
> py2exe.build_exe.py2exe.copy_extensions(self, extensions)
>  
> class BuildExe:
> def __init__(self):
> #Name of starting .py
> self.script = "main.py"
>  
> #Name of program
> self.project_name = "Around"
>  
> #Project url
> self.project_url = "about:none"
>  
> #Version of program
> self.project_version = "0.0.0.1"
>  
> #License of the program
> self.license = "MyApps License"
>  
> #Auhor of program
> self.author_name = "Keith Nemitz"
> self.author_email = "musenik atya hoo doh com"
> self.copyright = "Copyright (c) 2010 Keith Nemitz. All rights 
> reserved."
>  
> #Description
> self.project_description = "..."
>  
> #Icon file (None will use pygame default icon)
> self.icon_file = None
>  
> #Extra files/dirs copied to game
> self.extra_datas = 
> ["data","OpenGL","extras/Microsoft.VC90.CRT.manifest",
> 
> "extras/msvcm90.dll","extras/msvcp90.dll","extras/msvcr90.dll"]
>  
> #Extra/excludes python modules
> self.extra_modules = []
> self.exclude_modules = ["OpenGL"]
> 
> #DLL Excludes
> self.exclude_dll = ['']
>  
> #Zip file name (None will bundle files in exe instead of zip file)
> self.zipfile_name = Non

[pygame] Pygame, PyOpenGl, and py2exe, OH MY!

[Keith Nemitz]

I spent the day in py2exe hell. After grinding through six separate problems, 
now I'm stuck. Has anyone got this combo to work? I'm using Python 2.6 and 
Pygame 1.9.x and pyOpenGl 3.0.x and the latest py2exe. When I run the resulting 
exe, I get the following runtime error:

Traceback (most recent call last):
  File "main.py", line 29, in 
  File "zipextimporter.pyo", line 82, in load_module
  File "pygl2d\__init__.pyo", line 5, in 
  File "zipextimporter.pyo", line 82, in load_module
  File "pygl2d\window.pyo", line 3, in 
  File ".\OpenGL\GL\__init__.py", line 2, in 
from OpenGL.raw.GL import *
  File ".\OpenGL\raw\GL\__init__.py", line 6, in 
from OpenGL.raw.GL.constants import *
  File ".\OpenGL\raw\GL\constants.py", line 7, in 
from OpenGL import platform, arrays
  File ".\OpenGL\arrays\__init__.py", line 22, in 
formathandler.FormatHandler.loadAll()
  File ".\OpenGL\arrays\formathandler.py", line 37, in loadAll
cls.loadPlugin( entrypoint )
  File ".\OpenGL\arrays\formathandler.py", line 44, in loadPlugin
plugin_class = entrypoint.load()
  File ".\OpenGL\plugins.py", line 14, in load
return importByName( self.import_path )
  File ".\OpenGL\plugins.py", line 28, in importByName
module = __import__( ".".join(moduleName), {}, {}, moduleName)
  File ".\OpenGL\arrays\strings.py", line 8, in 
psas = ctypes.pythonapi.PyString_AsString
  File "ctypes\__init__.pyo", line 366, in __getattr__
  File "ctypes\__init__.pyo", line 371, in __getitem__
AttributeError: function 'PyString_AsString' not found




Here is the script I'm currently using, based on the pygame wiki script:


# This will create a dist directory containing the executable file, all the data
# directories. All Libraries will be bundled in executable file.
#
# Run the build process by entering 'pygame2exe.py' or
# 'python pygame2exe.py' in a console prompt.
#
# To build exe, python, pygame, and py2exe have to be installed. After
# building exe none of this libraries are needed.
 
try:
from distutils.core import setup
import py2exe, pygame
from modulefinder import Module
import glob, fnmatch
import sys, os, shutil
import operator
except ImportError, message:
raise SystemExit,  "Unable to load module. %s" % message

#---HACK
origIsSystemDLL = py2exe.build_exe.isSystemDLL
def isSystemDLL(pathname):
   if os.path.basename(pathname).lower() in 
["sdl_ttf.dll","sdl_mixer.dll","libogg-0.dll"]:
   return 0
   return origIsSystemDLL(pathname)
py2exe.build_exe.isSystemDLL = isSystemDLL
#---ENDHACK


class pygame2exe(py2exe.build_exe.py2exe): #This hack make sure that pygame 
default font is copied: no need to modify code for specifying default font
def copy_extensions(self, extensions):
#Get pygame default font
pygamedir = os.path.split(pygame.base.__file__)[0]
pygame_default_font = os.path.join(pygamedir, 
pygame.font.get_default_font())
 
#Add font to list of extension to be copied
extensions.append(Module("pygame.font", pygame_default_font))
py2exe.build_exe.py2exe.copy_extensions(self, extensions)
 
class BuildExe:
def __init__(self):
#Name of starting .py
self.script = "main.py"
 
#Name of program
self.project_name = "Around"
 
#Project url
self.project_url = "about:none"
 
#Version of program
self.project_version = "0.0.0.1"
 
#License of the program
self.license = "MyApps License"
 
#Auhor of program
self.author_name = "Keith Nemitz"
self.author_email = "musenik atya hoo doh com"
self.copyright = "Copyright (c) 2010 Keith Nemitz. All rights reserved."
 
#Description
self.project_description = "..."
 
#Icon file (None will use pygame default icon)
self.icon_file = None
 
#Extra files/dirs copied to game
self.extra_datas = 
["data","OpenGL","extras/Microsoft.VC90.CRT.manifest",

"extras/msvcm90.dll","extras/msvcp90.dll","extras/msvcr90.dll"]
 
#Extra/excludes python modules
self.extra_modules = []
self.exclude_modules = ["OpenGL"]

#DLL Excludes
self.exclude_dll = ['']
 
#Zip file name (None will bundle files in exe instead of zip file)
self.zipfile_name = None
 
#Dist directory
self.dist_dir ='dist'
 
## Code from DistUtils tutorial at 
http://wiki.python.org/moin/Distutils/Tutorial
## Originally borrowed from wxPython's setup and config files
def opj(self, *args):
path = os.path.join(*args)
return os.path.normpath(path)
 
def find_data_files(self, srcdir, *wildcards, **kw):
# get a list of all files under the srcdir matching wildcards,
# returned in a format to be used for install_data
def walk_helper(arg, dirname, files):
if '.svn' in dirname:
return
  

Re: [pygame] PyOpenGL Release 3.0.0 (final)

[René Dudfield]

On Fri, Apr 3, 2009 at 2:20 AM, Mike C. Fletcher wrote:

> Peter Gebauer wrote:
>
>> Hi Mike!
>>
>> Will PyOpenGL 3.x be rewritten in the future to use SWIG, Pyrex or
>> Python extensions written in C to improve performance? Is there a
>> possibility
>> of mixing ctypes with Python extensions in C for the more critical parts?
>>
>>
> The OpenGL_accelerate module is written in Cython (~= Pyrex) to improve
> performance.  Yes, you can fairly freely mix C/Cython/Pyrex coded
> OpenGL-using extensions with PyOpenGL code.  The current GL context is used
> by all PyOpenGL calls (well, the ones that don't explicitly specify
> contexts, such as those in GLUT or GLX).
>
> As for rewriting the core library, I doubt *I* will do another rewrite. But
> the fact is that someone could easily generate a new Cython/Pyrex wrapper
> without breaking a sweat.  They would just then need to do all the project
> management and maintenance on the code-base, and I quit working on the SWIG
> code-base because of the maintenance headaches, so it's not really something
> I want to go back to.
>
> The use of ctypes means that we should eventually be able to run on all of
> Jython, PyPy, IronPython, Unladen Swallow and CPython with the core
> Python+ctypes-only implementation.  Interpreters that actually *use* the
> ctypes annotations (PyPy) may eventually be able to use the fact of using
> ctypes to generate almost-C-level performance from the code.
>


A funny side note is that ironpython can more easily run CPython compiled
extensions than ctypes code at the moment.  This is done by emulating the
CPython API.


cu,

Re: [pygame] PyOpenGL Release 3.0.0 (final)

[Mike C. Fletcher]

Peter Gebauer wrote:

Hi Mike!

Will PyOpenGL 3.x be rewritten in the future to use SWIG, Pyrex or
Python extensions written in C to improve performance? Is there a possibility
of mixing ctypes with Python extensions in C for the more critical parts?
  
The OpenGL_accelerate module is written in Cython (~= Pyrex) to improve 
performance.  Yes, you can fairly freely mix C/Cython/Pyrex coded 
OpenGL-using extensions with PyOpenGL code.  The current GL context is 
used by all PyOpenGL calls (well, the ones that don't explicitly specify 
contexts, such as those in GLUT or GLX).


As for rewriting the core library, I doubt *I* will do another rewrite. 
But the fact is that someone could easily generate a new Cython/Pyrex 
wrapper without breaking a sweat.  They would just then need to do all 
the project management and maintenance on the code-base, and I quit 
working on the SWIG code-base because of the maintenance headaches, so 
it's not really something I want to go back to.


The use of ctypes means that we should eventually be able to run on all 
of Jython, PyPy, IronPython, Unladen Swallow and CPython with the core 
Python+ctypes-only implementation.  Interpreters that actually *use* the 
ctypes annotations (PyPy) may eventually be able to use the fact of 
using ctypes to generate almost-C-level performance from the code.


HTH,
Mike

--

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

Re: [pygame] PyOpenGL Release 3.0.0 (final)

[Peter Gebauer]

Hi Mike!

Will PyOpenGL 3.x be rewritten in the future to use SWIG, Pyrex or
Python extensions written in C to improve performance? Is there a possibility
of mixing ctypes with Python extensions in C for the more critical parts?

/Peter

On 2009-04-01 (Wed) 17:48, Mike C. Fletcher wrote:
> PyOpenGL is the traditional OpenGL binding for the Python language  
> (Python 2.x series).  This release is the first major release of the  
> package in more than 4 years.  PyOpenGL 3.x is a complete rewrite of the  
> PyOpenGL project which attempts to retain compatibility with the  
> original PyOpenGL 2.x API while providing support for many more  
> data-formats and extensions than were wrapped by the previous code-base.  
> It attempts to retain the "easy" approachable API of the original 
> PyOpenGL bindings, focusing more on ease of development (both for client 
> code and the library itself) than speed.
>
> Build and installation has been dramatically simplified.  It is possible  
> to work directly from a PyOpenGL bzr branch or to merely unpack the  
> package into your PYTHONPATH.  To install from source and/or participate  
> in development:
>
>bzr branch lp:pyopengl
>bzr branch lp:pyopengl-demo
>
> then add the pyopengl/OpenGL directory to your PYTHONPATH.  You can also  
> download the source distributions from:
>
>http://pyopengl.sourceforge.net
>
> and use standard distutils commands to install.  PyOpenGL 3.x is already  
> supported by the PyInstaller "exe" packaging utility, and can be made to  
> work with Py2exe with inclusion statements.
>
> PyOpenGL may be installed using the easy_install script if desired.   
> There are no setuptools/package-resources dependencies in PyOpenGL 3.0.0  
> final.  You can install PyOpenGL on supported platforms (currently  
> Linux, Win32 and OSX) with the following if you have setuptools, PIL and  
> Numpy installed:
>
>easy_install PyOpenGL
>easy_install PyOpenGL-Demo
>
> You can then run the scripts in the PyOpenGL-Demo package.
>
> PyOpenGL 3.x introduces package-level configuration flags which allow  
> you to modify the behavior of the entire PyOpenGL package, e.g. by  
> introducing extremely verbose logging, or turning off all error-checking  
> to improve performance.  Of particular note is a flag which allows you  
> to disable APIs which have been deprecated by the ARB in OpenGL 3.0.   
> Other flags allow you to control the trade-off between ease-of-use and  
> performance during the development and release process.
>
> PyOpenGL 3.x provides access to the entire OpenGL 3.0 API, as well as  
> most extensions which have been entered in the OpenGL extension  
> registry.  Commonly used extensions can have "Pythonic" wrappers written  
> easily, and many of the commonly used extensions already have simplified  
> APIs provided.  It also provides wrappers for the GLUT, GLE and GLX  
> libraries.  The AGL and WGL modules are not provided with PyOpenGL 3.x,  
> as most devs are using window-manager-based GL operations.
>
> PyOpenGL 3.x provides a simple plug-in API that allows you to write  
> data-format or platform plugins.  These can be used to easily add  
> "native" support for your array-friendly data-formats (vector classes  
> and the like).  There is a sample data-format plug-in which wraps the  
> "Vertex Buffer Objects" extensions (in the OpenGL/arrays/vbo.py module).
>
> PyOpenGL 3.x's documentation has been regenerated and the build process  
> for the documentation has been updated so that it can be easily  
> regenerated to include pointers to other Open Source PyOpenGL project's  
> online code viewers.  If you would like to add your project to the list  
> of referenced projects, please contact the author with details of your  
> code viewer's url, code license and project name.
>
> Notes in the reference documentation indicates the deprecated entry  
> points for OpenGL 3.0.  If you have a PyOpenGL code-base you should be  
> looking at reworking the code in order to eliminate the use of "legacy"  
> APIs before OpenGL 3.1 drivers become mainstream.  At minimum you should  
> be converting away from per-vertex operations and the use of display  
> lists toward using array-based geometry.
>
> You should expect a performance decline with the use of PyOpenGL 3.x  
> versus PyOpenGL 2.x!  PyOpenGL 3.x will have an accelerator module  
> released in time to provide better performance, but the development  
> method (ctypes) is inherently slower than the C (SWIG) method previously  
> used.  If your code is performance critical you should likely use the  
> accelerator module when it becomes available.  Also consider using the  
> package-level configuration flags to remove "support" functionality as  
> you near release, use of these flags can provide more than 2x speedup in  
> most cases.
>
> The 3.0.0 final release has a few bugs fixed from the previous 3.0.0c1  
> release.  Users of the release candidate should upgrade.  PyO

[pygame] PyOpenGL Release 3.0.0 (final)

[Mike C. Fletcher]

PyOpenGL is the traditional OpenGL binding for the Python language 
(Python 2.x series).  This release is the first major release of the 
package in more than 4 years.  PyOpenGL 3.x is a complete rewrite of the 
PyOpenGL project which attempts to retain compatibility with the 
original PyOpenGL 2.x API while providing support for many more 
data-formats and extensions than were wrapped by the previous 
code-base.  It attempts to retain the "easy" approachable API of the 
original PyOpenGL bindings, focusing more on ease of development (both 
for client code and the library itself) than speed.


Build and installation has been dramatically simplified.  It is possible 
to work directly from a PyOpenGL bzr branch or to merely unpack the 
package into your PYTHONPATH.  To install from source and/or participate 
in development:


   bzr branch lp:pyopengl
   bzr branch lp:pyopengl-demo

then add the pyopengl/OpenGL directory to your PYTHONPATH.  You can also 
download the source distributions from:


   http://pyopengl.sourceforge.net

and use standard distutils commands to install.  PyOpenGL 3.x is already 
supported by the PyInstaller "exe" packaging utility, and can be made to 
work with Py2exe with inclusion statements.


PyOpenGL may be installed using the easy_install script if desired.  
There are no setuptools/package-resources dependencies in PyOpenGL 3.0.0 
final.  You can install PyOpenGL on supported platforms (currently 
Linux, Win32 and OSX) with the following if you have setuptools, PIL and 
Numpy installed:


   easy_install PyOpenGL
   easy_install PyOpenGL-Demo

You can then run the scripts in the PyOpenGL-Demo package.

PyOpenGL 3.x introduces package-level configuration flags which allow 
you to modify the behavior of the entire PyOpenGL package, e.g. by 
introducing extremely verbose logging, or turning off all error-checking 
to improve performance.  Of particular note is a flag which allows you 
to disable APIs which have been deprecated by the ARB in OpenGL 3.0.  
Other flags allow you to control the trade-off between ease-of-use and 
performance during the development and release process.


PyOpenGL 3.x provides access to the entire OpenGL 3.0 API, as well as 
most extensions which have been entered in the OpenGL extension 
registry.  Commonly used extensions can have "Pythonic" wrappers written 
easily, and many of the commonly used extensions already have simplified 
APIs provided.  It also provides wrappers for the GLUT, GLE and GLX 
libraries.  The AGL and WGL modules are not provided with PyOpenGL 3.x, 
as most devs are using window-manager-based GL operations.


PyOpenGL 3.x provides a simple plug-in API that allows you to write 
data-format or platform plugins.  These can be used to easily add 
"native" support for your array-friendly data-formats (vector classes 
and the like).  There is a sample data-format plug-in which wraps the 
"Vertex Buffer Objects" extensions (in the OpenGL/arrays/vbo.py module).


PyOpenGL 3.x's documentation has been regenerated and the build process 
for the documentation has been updated so that it can be easily 
regenerated to include pointers to other Open Source PyOpenGL project's 
online code viewers.  If you would like to add your project to the list 
of referenced projects, please contact the author with details of your 
code viewer's url, code license and project name.


Notes in the reference documentation indicates the deprecated entry 
points for OpenGL 3.0.  If you have a PyOpenGL code-base you should be 
looking at reworking the code in order to eliminate the use of "legacy" 
APIs before OpenGL 3.1 drivers become mainstream.  At minimum you should 
be converting away from per-vertex operations and the use of display 
lists toward using array-based geometry.


You should expect a performance decline with the use of PyOpenGL 3.x 
versus PyOpenGL 2.x!  PyOpenGL 3.x will have an accelerator module 
released in time to provide better performance, but the development 
method (ctypes) is inherently slower than the C (SWIG) method previously 
used.  If your code is performance critical you should likely use the 
accelerator module when it becomes available.  Also consider using the 
package-level configuration flags to remove "support" functionality as 
you near release, use of these flags can provide more than 2x speedup in 
most cases.


The 3.0.0 final release has a few bugs fixed from the previous 3.0.0c1 
release.  Users of the release candidate should upgrade.  PyOpenGL 3.0.0 
is intended for use with the Python 2.x series, porting to Python 3.x is 
not currently on the roadmap.  There will likely be a PyOpenGL 3.0.1 
release in the near future which will introduce a few more optimizations 
and likely will be synchronized with the first public release of the 
accelerator modules.


Since the release of PyOpenGL 2.x another common OpenGL binding for 
Python has become popular and may be an appropriate choice for your 
projects.  The Pyglet p

Re: [pygame] Python - Pygame - PyOpenGL performance

[Casey Duncan]

It does: http://www.pyglet.org/doc/api/pyglet.image.Animation-class.html

Though I am not sure of the exact implementation. However that is  
easily found 8^)


-Casey

On Mar 22, 2009, at 2:52 AM, Peter Gebauer wrote:


Hi!

Iirc, Pyglet doesn't do animations for textures? That is,
changing the texture based on a preset time scale.

/Peter

On 2009-03-19 (Thu) 08:36, Casey Duncan wrote:

You should check out how pyglet uses VBOs (and vertex arrays as a
fallback) for its batched sprite engine. It also has some pretty keen
texture atlas support to reduce texture state changes.

-Casey

On Mar 19, 2009, at 8:03 AM, Peter Gebauer wrote:


Hi casey!

Yeh, unfortunately, I haven't found any smart ways to use retained
mode
for 2D graphics engines. Even if you do use VBO's in stream mode you
have
to update the data every frame, i.e a Python call that makes C  
calls,

all
those array structs have to be converted from Python types to C  
types

eventually as well. Also, changing textures requires immediate mode
calls.
From what little I know about it, my guess is that a C extension is
way faster than ctypes and SWIG generated code.

SWIG makes sense for an entire scenegraph written in C, the  
scenegraph
is retained in itself and will accept your data, including  
animations,

and continously executing it for you.

What most people want is a fast and simple scenegraph, that is
avoiding
shaders and the intricate details of opengl.
If you have solution for multiple textures in one VBO that does not
use shaders and
works in retained mode, please do share. I've been looking for ages.
With multiple textures I mean the ability to glBindTexture in  
retained

mode, not the use of multi textures.

/Peter


On 2009-03-17 (Tue) 21:43, Casey Duncan wrote:

With the emphasis these days on batch operations (VBOs, etc) and
doing
more and more of the work on the video card itself via shaders, I
seriously doubt that the bottleneck of a well-written, modern
PyOpenGL
application will be the ctypes overhead. The only time I could see
that
could be would be for immediate mode usage, which is deprecated
anyhow,
for the simple reason that per-vertex operations no longer mesh  
well

with
a modern graphics architecture.

If you are not writing a modern OpenGL app, then by all means, use
the
old version. It's going to be a while I think before cards drop
support
OpenGL 2 and earlier features. It will happen eventually though.

There are significant maintenance advantages to ctypes over C-
wrappers,
generated by SWIG or otherwise. It is difficult to make the latter
work
well across platforms and python versions. If you've ever looked at
the
build system for PyOpenGL 2.x, you'd understand what I mean. And
this is
coming from somebody who enjoys writing C extensions, but for
wrapping
existing APIs, ctypes is the state of the art. Like Python itself  
it

trades execution speed for development efficiency and better
portability.

PyOpenGL is more or less a one man project afaik, and let me tell
you,
development efficiency rules when you're trying to move mountains
yourself.

-Casey

On Mar 17, 2009, at 7:37 PM, Richie Ward wrote:


why did they not make 3.0 with swig?

On Tue, Mar 17, 2009 at 12:26 PM, RB[0]  wrote:

http://groups.google.com/group/pyglet-users/msg/832b15389fccd28d?
pli=1

Hmm, this is a bit outdated, but I found a few other references
that
say
SWIG will generally be faster to run, though would have more
overhead - so I
dunno.

HTH

On Tue, Mar 17, 2009 at 7:17 AM, RB[0]  wrote:


I saw saw tests for performance between the old C PyOpenGL and  
the

new
ctypes one...
The older one was significantly faster from what I saw - but  
that

is how
it will always be - direct usage of a C lib is just like  
calling C

functions
and such - whereas ctypes you have to call a python function
(which may call
others) which will execute the C lib code...

I'll see if I can't find the page somewhere...

On Mon, Mar 16, 2009 at 3:44 PM, Brian Fisher

wrote:


That's what PyOpenGL 2.0 was - a C extension instead of ctypes.
(made
with SWIG)

I actually still use PyOpenGL 2.0 for reasons other than
performance
(py2exe packaging) - I had to build it myself on windows for
Python 2.5, you
can get at an installer for it here:
http://thorbrian.com/pyopengl/builds.php

I've never performance tested the difference between it and 3.0
though -
is somebody else could do that, I'd love to see the results

On Mon, Mar 16, 2009 at 10:49 AM, Zack Schilling
 wrote:


If someone did this and I could drop it in to my code, that
would be
very nice. But for right now, PyOpenGL is serving my needs  
just

fine. I can
use about 600 independently textured and animated sprites
onscreen, scaled
and rotated, without stressing a low-end system more than 40%.

On Mar 16, 2009, at 1:00 PM, Forrest Voight wrote:


Would writing a replacement for PyOpenGL in C instead of in
Python
with ctypes help? I think it really would ... PyOpenGL is
internally
pretty complex, sometimes 

Re: [pygame] Python - Pygame - PyOpenGL performance

[Peter Gebauer]

Hi!

Iirc, Pyglet doesn't do animations for textures? That is,
changing the texture based on a preset time scale.

/Peter

On 2009-03-19 (Thu) 08:36, Casey Duncan wrote:
> You should check out how pyglet uses VBOs (and vertex arrays as a  
> fallback) for its batched sprite engine. It also has some pretty keen  
> texture atlas support to reduce texture state changes.
>
> -Casey
>
> On Mar 19, 2009, at 8:03 AM, Peter Gebauer wrote:
>
>> Hi casey!
>>
>> Yeh, unfortunately, I haven't found any smart ways to use retained  
>> mode
>> for 2D graphics engines. Even if you do use VBO's in stream mode you  
>> have
>> to update the data every frame, i.e a Python call that makes C calls, 
>> all
>> those array structs have to be converted from Python types to C types
>> eventually as well. Also, changing textures requires immediate mode  
>> calls.
>> From what little I know about it, my guess is that a C extension is
>> way faster than ctypes and SWIG generated code.
>>
>> SWIG makes sense for an entire scenegraph written in C, the scenegraph
>> is retained in itself and will accept your data, including animations,
>> and continously executing it for you.
>>
>> What most people want is a fast and simple scenegraph, that is  
>> avoiding
>> shaders and the intricate details of opengl.
>> If you have solution for multiple textures in one VBO that does not  
>> use shaders and
>> works in retained mode, please do share. I've been looking for ages.
>> With multiple textures I mean the ability to glBindTexture in retained
>> mode, not the use of multi textures.
>>
>> /Peter
>>
>>
>> On 2009-03-17 (Tue) 21:43, Casey Duncan wrote:
>>> With the emphasis these days on batch operations (VBOs, etc) and  
>>> doing
>>> more and more of the work on the video card itself via shaders, I
>>> seriously doubt that the bottleneck of a well-written, modern  
>>> PyOpenGL
>>> application will be the ctypes overhead. The only time I could see  
>>> that
>>> could be would be for immediate mode usage, which is deprecated  
>>> anyhow,
>>> for the simple reason that per-vertex operations no longer mesh well 
>>> with
>>> a modern graphics architecture.
>>>
>>> If you are not writing a modern OpenGL app, then by all means, use  
>>> the
>>> old version. It's going to be a while I think before cards drop  
>>> support
>>> OpenGL 2 and earlier features. It will happen eventually though.
>>>
>>> There are significant maintenance advantages to ctypes over C- 
>>> wrappers,
>>> generated by SWIG or otherwise. It is difficult to make the latter  
>>> work
>>> well across platforms and python versions. If you've ever looked at  
>>> the
>>> build system for PyOpenGL 2.x, you'd understand what I mean. And  
>>> this is
>>> coming from somebody who enjoys writing C extensions, but for  
>>> wrapping
>>> existing APIs, ctypes is the state of the art. Like Python itself it
>>> trades execution speed for development efficiency and better  
>>> portability.
>>>
>>> PyOpenGL is more or less a one man project afaik, and let me tell  
>>> you,
>>> development efficiency rules when you're trying to move mountains
>>> yourself.
>>>
>>> -Casey
>>>
>>> On Mar 17, 2009, at 7:37 PM, Richie Ward wrote:
>>>
 why did they not make 3.0 with swig?

 On Tue, Mar 17, 2009 at 12:26 PM, RB[0]  wrote:
> http://groups.google.com/group/pyglet-users/msg/832b15389fccd28d?
> pli=1
>
> Hmm, this is a bit outdated, but I found a few other references  
> that
> say
> SWIG will generally be faster to run, though would have more
> overhead - so I
> dunno.
>
> HTH
>
> On Tue, Mar 17, 2009 at 7:17 AM, RB[0]  wrote:
>>
>> I saw saw tests for performance between the old C PyOpenGL and the
>> new
>> ctypes one...
>> The older one was significantly faster from what I saw - but that
>> is how
>> it will always be - direct usage of a C lib is just like calling C
>> functions
>> and such - whereas ctypes you have to call a python function
>> (which may call
>> others) which will execute the C lib code...
>>
>> I'll see if I can't find the page somewhere...
>>
>> On Mon, Mar 16, 2009 at 3:44 PM, Brian Fisher
>> 
>> wrote:
>>>
>>> That's what PyOpenGL 2.0 was - a C extension instead of ctypes.
>>> (made
>>> with SWIG)
>>>
>>> I actually still use PyOpenGL 2.0 for reasons other than
>>> performance
>>> (py2exe packaging) - I had to build it myself on windows for
>>> Python 2.5, you
>>> can get at an installer for it here:
>>> http://thorbrian.com/pyopengl/builds.php
>>>
>>> I've never performance tested the difference between it and 3.0
>>> though -
>>> is somebody else could do that, I'd love to see the results
>>>
>>> On Mon, Mar 16, 2009 at 10:49 AM, Zack Schilling
>>>  wrote:

 If someone did this and I could drop it in to my code, that
 would be
 very ni

Re: [pygame] Python - Pygame - PyOpenGL performance

[Casey Duncan]

You should check out how pyglet uses VBOs (and vertex arrays as a  
fallback) for its batched sprite engine. It also has some pretty keen  
texture atlas support to reduce texture state changes.


-Casey

On Mar 19, 2009, at 8:03 AM, Peter Gebauer wrote:


Hi casey!

Yeh, unfortunately, I haven't found any smart ways to use retained  
mode
for 2D graphics engines. Even if you do use VBO's in stream mode you  
have
to update the data every frame, i.e a Python call that makes C  
calls, all

those array structs have to be converted from Python types to C types
eventually as well. Also, changing textures requires immediate mode  
calls.

From what little I know about it, my guess is that a C extension is
way faster than ctypes and SWIG generated code.

SWIG makes sense for an entire scenegraph written in C, the scenegraph
is retained in itself and will accept your data, including animations,
and continously executing it for you.

What most people want is a fast and simple scenegraph, that is  
avoiding

shaders and the intricate details of opengl.
If you have solution for multiple textures in one VBO that does not  
use shaders and

works in retained mode, please do share. I've been looking for ages.
With multiple textures I mean the ability to glBindTexture in retained
mode, not the use of multi textures.

/Peter


On 2009-03-17 (Tue) 21:43, Casey Duncan wrote:
With the emphasis these days on batch operations (VBOs, etc) and  
doing

more and more of the work on the video card itself via shaders, I
seriously doubt that the bottleneck of a well-written, modern  
PyOpenGL
application will be the ctypes overhead. The only time I could see  
that
could be would be for immediate mode usage, which is deprecated  
anyhow,
for the simple reason that per-vertex operations no longer mesh  
well with

a modern graphics architecture.

If you are not writing a modern OpenGL app, then by all means, use  
the
old version. It's going to be a while I think before cards drop  
support

OpenGL 2 and earlier features. It will happen eventually though.

There are significant maintenance advantages to ctypes over C- 
wrappers,
generated by SWIG or otherwise. It is difficult to make the latter  
work
well across platforms and python versions. If you've ever looked at  
the
build system for PyOpenGL 2.x, you'd understand what I mean. And  
this is
coming from somebody who enjoys writing C extensions, but for  
wrapping

existing APIs, ctypes is the state of the art. Like Python itself it
trades execution speed for development efficiency and better  
portability.


PyOpenGL is more or less a one man project afaik, and let me tell  
you,

development efficiency rules when you're trying to move mountains
yourself.

-Casey

On Mar 17, 2009, at 7:37 PM, Richie Ward wrote:


why did they not make 3.0 with swig?

On Tue, Mar 17, 2009 at 12:26 PM, RB[0]  wrote:

http://groups.google.com/group/pyglet-users/msg/832b15389fccd28d?
pli=1

Hmm, this is a bit outdated, but I found a few other references  
that

say
SWIG will generally be faster to run, though would have more
overhead - so I
dunno.

HTH

On Tue, Mar 17, 2009 at 7:17 AM, RB[0]  wrote:


I saw saw tests for performance between the old C PyOpenGL and the
new
ctypes one...
The older one was significantly faster from what I saw - but that
is how
it will always be - direct usage of a C lib is just like calling C
functions
and such - whereas ctypes you have to call a python function
(which may call
others) which will execute the C lib code...

I'll see if I can't find the page somewhere...

On Mon, Mar 16, 2009 at 3:44 PM, Brian Fisher

wrote:


That's what PyOpenGL 2.0 was - a C extension instead of ctypes.
(made
with SWIG)

I actually still use PyOpenGL 2.0 for reasons other than
performance
(py2exe packaging) - I had to build it myself on windows for
Python 2.5, you
can get at an installer for it here:
http://thorbrian.com/pyopengl/builds.php

I've never performance tested the difference between it and 3.0
though -
is somebody else could do that, I'd love to see the results

On Mon, Mar 16, 2009 at 10:49 AM, Zack Schilling
 wrote:


If someone did this and I could drop it in to my code, that
would be
very nice. But for right now, PyOpenGL is serving my needs just
fine. I can
use about 600 independently textured and animated sprites
onscreen, scaled
and rotated, without stressing a low-end system more than 40%.

On Mar 16, 2009, at 1:00 PM, Forrest Voight wrote:


Would writing a replacement for PyOpenGL in C instead of in
Python
with ctypes help? I think it really would ... PyOpenGL is
internally
pretty complex, sometimes when I get tracebacks the error is
5 or 6
levels into PyOpenGL. Even a C library that only implemented  
the

common functions and relied on PyOpenGL for the constants and
functions that do complex things like handling strings would
probably
help a lot.



Another way to increase speed is to write an opengl
rendering engine
in C and call and make it available as a Py

Re: [pygame] Python - Pygame - PyOpenGL performance

[Peter Gebauer]

I'm not sure ctypes is sufficient for everything you can do
with OpenGL, but I don't know.

/Peter

On 2009-03-16 (Mon) 13:00, Forrest Voight wrote:
> Would writing a replacement for PyOpenGL in C instead of in Python
> with ctypes help? I think it really would ... PyOpenGL is internally
> pretty complex, sometimes when I get tracebacks the error is 5 or 6
> levels into PyOpenGL. Even a C library that only implemented the
> common functions and relied on PyOpenGL for the constants and
> functions that do complex things like handling strings would probably
> help a lot.
> 
> On Fri, Feb 27, 2009 at 11:19 AM, Peter Gebauer
>  wrote:
> > Hi!
> >
> > I've done a few sprite thingies in OpenGL here are some pointers:
> >
> > Afaik display lists and VBO's can't bind different textures (?)
> > per list/array. You can't animate lists by changing texcoords
> > independently per element, so no go. VBO's have texture coords,
> > but only one texture. Again, I'm no expert, might be wrong.
> >
> > With the quad aproach you should try
> > to make the number of calls as few as possible. If you get
> > rid of the push and translate for each sprite you'll get some
> > extra speed. Try positioning each quads directly. The downside
> > with sharing matrix over all sprites is the obvious lack of
> > using OpenGL transformations, but some vector math aplied to
> > the quads has been faster for me than having one transformed
> > matrix per quad.
> >
> > Since I haven't been able to animate a list/vbo with independent
> > textures and texture coords for each element/buffer object I've only
> > used it for backdrops. The speed increase is tremendous.
> > I also partition the elements so only one list/vbo is displayed per
> > visible section, if you're screen display is smaller than the
> > entire scene, this helps even more.
> >
> > If you put all your sprites and their animation frames into one
> > big texture you could use VBO's, but I've never had the tenacity
> > to try that aproach.
> >
> > Another way to increase speed is to write an opengl rendering engine
> > in C and call and make it available as a Python extension. This is
> > a major speed boost, in particular for a large number of iterations.
> > Iirc PyOpenGL bindings are generated, many times this is suboptimal
> > code for what you're trying to do, writing the Python extension in C
> > manually have been faster for me many times. This is indeed true
> > if you put your iterations inside a C loop instead of calling the
> > C function from Python many times.
> >
> > In any case, still waiting for that OO 2D game engine with tons of
> > OpenGL features and effects, including simple things like frame animation,
> > LERP-like features and a simple 2D scenegraph. No luck yet, all attempts
> > I've tried so far lack at least one "must have" feature. :)
> >
> > /Peter
> >
> > On 2009-02-26 (Thu) 11:29, Casey Duncan wrote:
> >> Immediate mode calls (glVertex et al) are the very slowest way to use
> >> OpenGL. In fact they are deprecated in OpenGL 3.0 and will eventually be
> >> removed.
> >>
> >> The display list is better as you discovered, but you still are making a
> >> few OpenGL state changes per sprite, which is likely slowing you down.
> >> Also there is some overhead for the display list call, which makes them
> >> sub-optimal for just drawing a single quad.
> >>
> >>>        glPushMatrix()
> >>>        glTranslate(self.positionx,self.positiony,0)
> >>>        glCallList(self.displist)
> >>>        glPopMatrix()
> >>
> >> You really need to batch the quads up into a few vertex arrays or vbos
> >> to stream them to the card in one go. pyglet has a high-level python
> >> sprite api that automates this for you fwiw.
> >>
> >> -Casey
> >>
> >> On Feb 26, 2009, at 11:04 AM, Zack Schilling wrote:
> >>
> >>> I know the PyOpenGL mailing list might be a better place to ask this
> >>> question, but I've had a lot of luck talking to the experienced people
> >>> here so I figured I'd try it first.
> >>>
> >>> I'm trying to migrate a game I created from using the Pygame / SDL
> >>> software rendering to OpenGL. Before attempting the massive and
> >>> complex conversion involved with moving the whole game, I decided to
> >>> make a little test program while I learned OpenGL.
> >>>
> >>> In this test, I set up OpenGL to work in 2D and began loading images
> >>> into texture objects and drawing textured quads as sprites. I created a
> >>> little glSprite class to handle the drawing and translation. At first
> >>> its draw routine looked like this:
> >>>
> >>>        glPushMatrix()
> >>>        glTranslate(self.positionx,self.positiony,0)
> >>>        glBindTexture(GL_TEXTURE_2D, self.texture)
> >>>        glBegin(GL_QUADS)
> >>>        glTexCoord2f(0, 1)
> >>>        glVertex2f(0, 0)
> >>>        glTexCoord2f(1, 1)
> >>>        glVertex2f(w, 0)
> >>>        glTexCoord2f(1, 0)
> >>>        glVertex2f(w, h)
> >>>        glTexCoord2f(0, 0)
> >>>        glVertex2f(0, h)
> >>>        glE

Re: [pygame] Python - Pygame - PyOpenGL performance

[Peter Gebauer]

Hi casey!

Yeh, unfortunately, I haven't found any smart ways to use retained mode
for 2D graphics engines. Even if you do use VBO's in stream mode you have
to update the data every frame, i.e a Python call that makes C calls, all
those array structs have to be converted from Python types to C types
eventually as well. Also, changing textures requires immediate mode calls.
>From what little I know about it, my guess is that a C extension is
way faster than ctypes and SWIG generated code.

SWIG makes sense for an entire scenegraph written in C, the scenegraph
is retained in itself and will accept your data, including animations,
and continously executing it for you.

What most people want is a fast and simple scenegraph, that is avoiding
shaders and the intricate details of opengl.
If you have solution for multiple textures in one VBO that does not use shaders 
and
works in retained mode, please do share. I've been looking for ages.
With multiple textures I mean the ability to glBindTexture in retained
mode, not the use of multi textures.

/Peter


On 2009-03-17 (Tue) 21:43, Casey Duncan wrote:
> With the emphasis these days on batch operations (VBOs, etc) and doing  
> more and more of the work on the video card itself via shaders, I  
> seriously doubt that the bottleneck of a well-written, modern PyOpenGL  
> application will be the ctypes overhead. The only time I could see that 
> could be would be for immediate mode usage, which is deprecated anyhow, 
> for the simple reason that per-vertex operations no longer mesh well with 
> a modern graphics architecture.
>
> If you are not writing a modern OpenGL app, then by all means, use the  
> old version. It's going to be a while I think before cards drop support 
> OpenGL 2 and earlier features. It will happen eventually though.
>
> There are significant maintenance advantages to ctypes over C-wrappers, 
> generated by SWIG or otherwise. It is difficult to make the latter work 
> well across platforms and python versions. If you've ever looked at the 
> build system for PyOpenGL 2.x, you'd understand what I mean. And this is 
> coming from somebody who enjoys writing C extensions, but for wrapping 
> existing APIs, ctypes is the state of the art. Like Python itself it 
> trades execution speed for development efficiency and better portability.
>
> PyOpenGL is more or less a one man project afaik, and let me tell you,  
> development efficiency rules when you're trying to move mountains  
> yourself.
>
> -Casey
>
> On Mar 17, 2009, at 7:37 PM, Richie Ward wrote:
>
>> why did they not make 3.0 with swig?
>>
>> On Tue, Mar 17, 2009 at 12:26 PM, RB[0]  wrote:
>>> http://groups.google.com/group/pyglet-users/msg/832b15389fccd28d? 
>>> pli=1
>>>
>>> Hmm, this is a bit outdated, but I found a few other references that 
>>> say
>>> SWIG will generally be faster to run, though would have more  
>>> overhead - so I
>>> dunno.
>>>
>>> HTH
>>>
>>> On Tue, Mar 17, 2009 at 7:17 AM, RB[0]  wrote:

 I saw saw tests for performance between the old C PyOpenGL and the  
 new
 ctypes one...
 The older one was significantly faster from what I saw - but that  
 is how
 it will always be - direct usage of a C lib is just like calling C  
 functions
 and such - whereas ctypes you have to call a python function  
 (which may call
 others) which will execute the C lib code...

 I'll see if I can't find the page somewhere...

 On Mon, Mar 16, 2009 at 3:44 PM, Brian Fisher 
 
 wrote:
>
> That's what PyOpenGL 2.0 was - a C extension instead of ctypes.  
> (made
> with SWIG)
>
> I actually still use PyOpenGL 2.0 for reasons other than  
> performance
> (py2exe packaging) - I had to build it myself on windows for  
> Python 2.5, you
> can get at an installer for it here:
> http://thorbrian.com/pyopengl/builds.php
>
> I've never performance tested the difference between it and 3.0  
> though -
> is somebody else could do that, I'd love to see the results
>
> On Mon, Mar 16, 2009 at 10:49 AM, Zack Schilling
>  wrote:
>>
>> If someone did this and I could drop it in to my code, that  
>> would be
>> very nice. But for right now, PyOpenGL is serving my needs just 
>> fine. I can
>> use about 600 independently textured and animated sprites  
>> onscreen, scaled
>> and rotated, without stressing a low-end system more than 40%.
>>
>> On Mar 16, 2009, at 1:00 PM, Forrest Voight wrote:
>>
>>> Would writing a replacement for PyOpenGL in C instead of in  
>>> Python
>>> with ctypes help? I think it really would ... PyOpenGL is  
>>> internally
>>> pretty complex, sometimes when I get tracebacks the error is 
>>> 5 or 6
>>> levels into PyOpenGL. Even a C library that only implemented the
>>> common functions and relied on PyOpenGL for the constants and
>>> functions that do complex 

Re: [pygame] Python - Pygame - PyOpenGL performance

[René Dudfield]

Hi,

I would like to argue that ctypes style extension development is worse
compared to C extension development for portability, and maintenance.

There's hardly anyone who knows all the quirks of ctypes, and you still need
to test on different platforms.  ctypes doesn't check types for you, so you
just get weird errors when your arguments are wrong.  Note, that pyopengl
ctypes doesn't magically work on all the different platforms... and still
doesn't, it had to be made to work on the various platforms -- and that
effort took way longer than the pyopengl C extension.  Also ctypes can not
use all C features, so for some APIs it's impossible to write an interface
using ctypes.

There are way more people who know how to use C development environments on
the order of 1,000,000x as many people compared to the number who know how
to use ctypes.  That's the main reason why ctypes projects don't have as
many contributors as C extension projects.  A project with one main
developer is really poor for maintenance.

Debugging using ctypes is practically impossible - unless you use a debugger
from a C development environment.

Ctypes is *not* available on every platform that python is available on.  eg
win64, various arm ones, etc etc.  It automatically has worse portability -
since it runs on less platforms.


Therefore ctypes has worse portability, and is harder to maintain.






However, I think ctypes is still better compared to swig - just not compared
to C extensions.  Since swig is just as bad as ctypes for all the reasons I
mentioned above - and has extra badness.  Swig changes over versions, so
it's likely your extension will not compile with different versions of
swig.  This caused many problems with pyopengl, and took lots of effort to
get it working when new versions of swig came out.




On Wed, Mar 18, 2009 at 2:43 PM, Casey Duncan  wrote:

> With the emphasis these days on batch operations (VBOs, etc) and doing more
> and more of the work on the video card itself via shaders, I seriously doubt
> that the bottleneck of a well-written, modern PyOpenGL application will be
> the ctypes overhead. The only time I could see that could be would be for
> immediate mode usage, which is deprecated anyhow, for the simple reason that
> per-vertex operations no longer mesh well with a modern graphics
> architecture.
>
> If you are not writing a modern OpenGL app, then by all means, use the old
> version. It's going to be a while I think before cards drop support OpenGL 2
> and earlier features. It will happen eventually though.
>
> There are significant maintenance advantages to ctypes over C-wrappers,
> generated by SWIG or otherwise. It is difficult to make the latter work well
> across platforms and python versions. If you've ever looked at the build
> system for PyOpenGL 2.x, you'd understand what I mean. And this is coming
> from somebody who enjoys writing C extensions, but for wrapping existing
> APIs, ctypes is the state of the art. Like Python itself it trades execution
> speed for development efficiency and better portability.
>
> PyOpenGL is more or less a one man project afaik, and let me tell you,
> development efficiency rules when you're trying to move mountains yourself.
>
> -Casey
>
>
> On Mar 17, 2009, at 7:37 PM, Richie Ward wrote:
>
>  why did they not make 3.0 with swig?
>>
>> On Tue, Mar 17, 2009 at 12:26 PM, RB[0]  wrote:
>>
>>> http://groups.google.com/group/pyglet-users/msg/832b15389fccd28d?pli=1
>>>
>>> Hmm, this is a bit outdated, but I found a few other references that say
>>> SWIG will generally be faster to run, though would have more overhead -
>>> so I
>>> dunno.
>>>
>>> HTH
>>>
>>> On Tue, Mar 17, 2009 at 7:17 AM, RB[0]  wrote:
>>>

 I saw saw tests for performance between the old C PyOpenGL and the new
 ctypes one...
 The older one was significantly faster from what I saw - but that is how
 it will always be - direct usage of a C lib is just like calling C
 functions
 and such - whereas ctypes you have to call a python function (which may
 call
 others) which will execute the C lib code...

 I'll see if I can't find the page somewhere...

 On Mon, Mar 16, 2009 at 3:44 PM, Brian Fisher <
 br...@hamsterrepublic.com>
 wrote:

>
> That's what PyOpenGL 2.0 was - a C extension instead of ctypes. (made
> with SWIG)
>
> I actually still use PyOpenGL 2.0 for reasons other than performance
> (py2exe packaging) - I had to build it myself on windows for Python
> 2.5, you
> can get at an installer for it here:
> http://thorbrian.com/pyopengl/builds.php
>
> I've never performance tested the difference between it and 3.0 though
> -
> is somebody else could do that, I'd love to see the results
>
> On Mon, Mar 16, 2009 at 10:49 AM, Zack Schilling
>  wrote:
>
>>
>> If someone did this and I could drop it in to my code, that would be
>> very nice. But for right

Re: [pygame] Python - Pygame - PyOpenGL performance

[RB[0]]

Yes, from what I have seen the differences are negligible (the links I found
stated that) a few fps or something.
And the new opengl has support for more features, the old version only goes
to like opengl 1.2 compatibility or something when I last checked.

I would recommend you use the ctypes one over the old one even if doing
immediate mode ;)

On Tue, Mar 17, 2009 at 10:43 PM, Casey Duncan  wrote:

> With the emphasis these days on batch operations (VBOs, etc) and doing more
> and more of the work on the video card itself via shaders, I seriously doubt
> that the bottleneck of a well-written, modern PyOpenGL application will be
> the ctypes overhead. The only time I could see that could be would be for
> immediate mode usage, which is deprecated anyhow, for the simple reason that
> per-vertex operations no longer mesh well with a modern graphics
> architecture.
>
> If you are not writing a modern OpenGL app, then by all means, use the old
> version. It's going to be a while I think before cards drop support OpenGL 2
> and earlier features. It will happen eventually though.
>
> There are significant maintenance advantages to ctypes over C-wrappers,
> generated by SWIG or otherwise. It is difficult to make the latter work well
> across platforms and python versions. If you've ever looked at the build
> system for PyOpenGL 2.x, you'd understand what I mean. And this is coming
> from somebody who enjoys writing C extensions, but for wrapping existing
> APIs, ctypes is the state of the art. Like Python itself it trades execution
> speed for development efficiency and better portability.
>
> PyOpenGL is more or less a one man project afaik, and let me tell you,
> development efficiency rules when you're trying to move mountains yourself.
>
> -Casey
>
>
> On Mar 17, 2009, at 7:37 PM, Richie Ward wrote:
>
>  why did they not make 3.0 with swig?
>>
>> On Tue, Mar 17, 2009 at 12:26 PM, RB[0]  wrote:
>>
>>> http://groups.google.com/group/pyglet-users/msg/832b15389fccd28d?pli=1
>>>
>>> Hmm, this is a bit outdated, but I found a few other references that say
>>> SWIG will generally be faster to run, though would have more overhead -
>>> so I
>>> dunno.
>>>
>>> HTH
>>>
>>> On Tue, Mar 17, 2009 at 7:17 AM, RB[0]  wrote:
>>>

 I saw saw tests for performance between the old C PyOpenGL and the new
 ctypes one...
 The older one was significantly faster from what I saw - but that is how
 it will always be - direct usage of a C lib is just like calling C
 functions
 and such - whereas ctypes you have to call a python function (which may
 call
 others) which will execute the C lib code...

 I'll see if I can't find the page somewhere...

 On Mon, Mar 16, 2009 at 3:44 PM, Brian Fisher <
 br...@hamsterrepublic.com>
 wrote:

>
> That's what PyOpenGL 2.0 was - a C extension instead of ctypes. (made
> with SWIG)
>
> I actually still use PyOpenGL 2.0 for reasons other than performance
> (py2exe packaging) - I had to build it myself on windows for Python
> 2.5, you
> can get at an installer for it here:
> http://thorbrian.com/pyopengl/builds.php
>
> I've never performance tested the difference between it and 3.0 though
> -
> is somebody else could do that, I'd love to see the results
>
> On Mon, Mar 16, 2009 at 10:49 AM, Zack Schilling
>  wrote:
>
>>
>> If someone did this and I could drop it in to my code, that would be
>> very nice. But for right now, PyOpenGL is serving my needs just fine.
>> I can
>> use about 600 independently textured and animated sprites onscreen,
>> scaled
>> and rotated, without stressing a low-end system more than 40%.
>>
>> On Mar 16, 2009, at 1:00 PM, Forrest Voight wrote:
>>
>>  Would writing a replacement for PyOpenGL in C instead of in Python
>>> with ctypes help? I think it really would ... PyOpenGL is internally
>>> pretty complex, sometimes when I get tracebacks the error is 5 or 6
>>> levels into PyOpenGL. Even a C library that only implemented the
>>> common functions and relied on PyOpenGL for the constants and
>>> functions that do complex things like handling strings would probably
>>> help a lot.
>>>
>>>
 Another way to increase speed is to write an opengl rendering engine
 in C and call and make it available as a Python extension. This is
 a major speed boost, in particular for a large number of iterations.
 Iirc PyOpenGL bindings are generated, many times this is suboptimal
 code for what you're trying to do, writing the Python extension in C
 manually have been faster for me many times. This is indeed true
 if you put your iterations inside a C loop instead of calling the
 C function from Python many times.


>

>>>
>>>
>>
>>
>> --
>> Thanks, Richie Ward
>>
>
>

Re: [pygame] Python - Pygame - PyOpenGL performance

[Casey Duncan]

With the emphasis these days on batch operations (VBOs, etc) and doing  
more and more of the work on the video card itself via shaders, I  
seriously doubt that the bottleneck of a well-written, modern PyOpenGL  
application will be the ctypes overhead. The only time I could see  
that could be would be for immediate mode usage, which is deprecated  
anyhow, for the simple reason that per-vertex operations no longer  
mesh well with a modern graphics architecture.


If you are not writing a modern OpenGL app, then by all means, use the  
old version. It's going to be a while I think before cards drop  
support OpenGL 2 and earlier features. It will happen eventually though.


There are significant maintenance advantages to ctypes over C- 
wrappers, generated by SWIG or otherwise. It is difficult to make the  
latter work well across platforms and python versions. If you've ever  
looked at the build system for PyOpenGL 2.x, you'd understand what I  
mean. And this is coming from somebody who enjoys writing C  
extensions, but for wrapping existing APIs, ctypes is the state of the  
art. Like Python itself it trades execution speed for development  
efficiency and better portability.


PyOpenGL is more or less a one man project afaik, and let me tell you,  
development efficiency rules when you're trying to move mountains  
yourself.


-Casey

On Mar 17, 2009, at 7:37 PM, Richie Ward wrote:


why did they not make 3.0 with swig?

On Tue, Mar 17, 2009 at 12:26 PM, RB[0]  wrote:
http://groups.google.com/group/pyglet-users/msg/832b15389fccd28d? 
pli=1


Hmm, this is a bit outdated, but I found a few other references  
that say
SWIG will generally be faster to run, though would have more  
overhead - so I

dunno.

HTH

On Tue, Mar 17, 2009 at 7:17 AM, RB[0]  wrote:


I saw saw tests for performance between the old C PyOpenGL and the  
new

ctypes one...
The older one was significantly faster from what I saw - but that  
is how
it will always be - direct usage of a C lib is just like calling C  
functions
and such - whereas ctypes you have to call a python function  
(which may call

others) which will execute the C lib code...

I'll see if I can't find the page somewhere...

On Mon, Mar 16, 2009 at 3:44 PM, Brian Fisher >

wrote:


That's what PyOpenGL 2.0 was - a C extension instead of ctypes.  
(made

with SWIG)

I actually still use PyOpenGL 2.0 for reasons other than  
performance
(py2exe packaging) - I had to build it myself on windows for  
Python 2.5, you

can get at an installer for it here:
http://thorbrian.com/pyopengl/builds.php

I've never performance tested the difference between it and 3.0  
though -

is somebody else could do that, I'd love to see the results

On Mon, Mar 16, 2009 at 10:49 AM, Zack Schilling
 wrote:


If someone did this and I could drop it in to my code, that  
would be
very nice. But for right now, PyOpenGL is serving my needs just  
fine. I can
use about 600 independently textured and animated sprites  
onscreen, scaled

and rotated, without stressing a low-end system more than 40%.

On Mar 16, 2009, at 1:00 PM, Forrest Voight wrote:

Would writing a replacement for PyOpenGL in C instead of in  
Python
with ctypes help? I think it really would ... PyOpenGL is  
internally
pretty complex, sometimes when I get tracebacks the error is 5  
or 6

levels into PyOpenGL. Even a C library that only implemented the
common functions and relied on PyOpenGL for the constants and
functions that do complex things like handling strings would  
probably

help a lot.



Another way to increase speed is to write an opengl rendering  
engine
in C and call and make it available as a Python extension.  
This is
a major speed boost, in particular for a large number of  
iterations.
Iirc PyOpenGL bindings are generated, many times this is  
suboptimal
code for what you're trying to do, writing the Python  
extension in C

manually have been faster for me many times. This is indeed true
if you put your iterations inside a C loop instead of calling  
the

C function from Python many times.












--
Thanks, Richie Ward

Re: [pygame] Python - Pygame - PyOpenGL performance

[Richie Ward]

why did they not make 3.0 with swig?

On Tue, Mar 17, 2009 at 12:26 PM, RB[0]  wrote:
> http://groups.google.com/group/pyglet-users/msg/832b15389fccd28d?pli=1
>
> Hmm, this is a bit outdated, but I found a few other references that say
> SWIG will generally be faster to run, though would have more overhead - so I
> dunno.
>
> HTH
>
> On Tue, Mar 17, 2009 at 7:17 AM, RB[0]  wrote:
>>
>> I saw saw tests for performance between the old C PyOpenGL and the new
>> ctypes one...
>> The older one was significantly faster from what I saw - but that is how
>> it will always be - direct usage of a C lib is just like calling C functions
>> and such - whereas ctypes you have to call a python function (which may call
>> others) which will execute the C lib code...
>>
>> I'll see if I can't find the page somewhere...
>>
>> On Mon, Mar 16, 2009 at 3:44 PM, Brian Fisher 
>> wrote:
>>>
>>> That's what PyOpenGL 2.0 was - a C extension instead of ctypes. (made
>>> with SWIG)
>>>
>>> I actually still use PyOpenGL 2.0 for reasons other than performance
>>> (py2exe packaging) - I had to build it myself on windows for Python 2.5, you
>>> can get at an installer for it here:
>>> http://thorbrian.com/pyopengl/builds.php
>>>
>>> I've never performance tested the difference between it and 3.0 though -
>>> is somebody else could do that, I'd love to see the results
>>>
>>> On Mon, Mar 16, 2009 at 10:49 AM, Zack Schilling
>>>  wrote:

 If someone did this and I could drop it in to my code, that would be
 very nice. But for right now, PyOpenGL is serving my needs just fine. I can
 use about 600 independently textured and animated sprites onscreen, scaled
 and rotated, without stressing a low-end system more than 40%.

 On Mar 16, 2009, at 1:00 PM, Forrest Voight wrote:

> Would writing a replacement for PyOpenGL in C instead of in Python
> with ctypes help? I think it really would ... PyOpenGL is internally
> pretty complex, sometimes when I get tracebacks the error is 5 or 6
> levels into PyOpenGL. Even a C library that only implemented the
> common functions and relied on PyOpenGL for the constants and
> functions that do complex things like handling strings would probably
> help a lot.
>
>>
>> Another way to increase speed is to write an opengl rendering engine
>> in C and call and make it available as a Python extension. This is
>> a major speed boost, in particular for a large number of iterations.
>> Iirc PyOpenGL bindings are generated, many times this is suboptimal
>> code for what you're trying to do, writing the Python extension in C
>> manually have been faster for me many times. This is indeed true
>> if you put your iterations inside a C loop instead of calling the
>> C function from Python many times.
>>
>>>
>>
>
>



-- 
Thanks, Richie Ward

Re: [pygame] Python - Pygame - PyOpenGL performance

[RB[0]]

http://groups.google.com/group/pyglet-users/msg/832b15389fccd28d?pli=1

Hmm, this is a bit outdated, but I found a few other references that say
SWIG will generally be faster to run, though would have more overhead - so I
dunno.

HTH

On Tue, Mar 17, 2009 at 7:17 AM, RB[0]  wrote:

> I saw saw tests for performance between the old C PyOpenGL and the new
> ctypes one...
> The older one was significantly faster from what I saw - but that is how it
> will always be - direct usage of a C lib is just like calling C functions
> and such - whereas ctypes you have to call a python function (which may call
> others) which will execute the C lib code...
>
> I'll see if I can't find the page somewhere...
>
>
> On Mon, Mar 16, 2009 at 3:44 PM, Brian Fisher 
> wrote:
>
>> That's what PyOpenGL 2.0 was - a C extension instead of ctypes. (made with
>> SWIG)
>>
>> I actually still use PyOpenGL 2.0 for reasons other than performance
>> (py2exe packaging) - I had to build it myself on windows for Python 2.5, you
>> can get at an installer for it here:
>> http://thorbrian.com/pyopengl/builds.php
>>
>> I've never performance tested the difference between it and 3.0 though -
>> is somebody else could do that, I'd love to see the results
>>
>> On Mon, Mar 16, 2009 at 10:49 AM, Zack Schilling <
>> zack.schill...@gmail.com> wrote:
>>
>>> If someone did this and I could drop it in to my code, that would be very
>>> nice. But for right now, PyOpenGL is serving my needs just fine. I can use
>>> about 600 independently textured and animated sprites onscreen, scaled and
>>> rotated, without stressing a low-end system more than 40%.
>>>
>>> On Mar 16, 2009, at 1:00 PM, Forrest Voight wrote:
>>>
>>>  Would writing a replacement for PyOpenGL in C instead of in Python
 with ctypes help? I think it really would ... PyOpenGL is internally
 pretty complex, sometimes when I get tracebacks the error is 5 or 6
 levels into PyOpenGL. Even a C library that only implemented the
 common functions and relied on PyOpenGL for the constants and
 functions that do complex things like handling strings would probably
 help a lot.


> Another way to increase speed is to write an opengl rendering engine
> in C and call and make it available as a Python extension. This is
> a major speed boost, in particular for a large number of iterations.
> Iirc PyOpenGL bindings are generated, many times this is suboptimal
> code for what you're trying to do, writing the Python extension in C
> manually have been faster for me many times. This is indeed true
> if you put your iterations inside a C loop instead of calling the
> C function from Python many times.
>
>
>>
>

Re: [pygame] Python - Pygame - PyOpenGL performance

[RB[0]]

I saw saw tests for performance between the old C PyOpenGL and the new
ctypes one...
The older one was significantly faster from what I saw - but that is how it
will always be - direct usage of a C lib is just like calling C functions
and such - whereas ctypes you have to call a python function (which may call
others) which will execute the C lib code...

I'll see if I can't find the page somewhere...

On Mon, Mar 16, 2009 at 3:44 PM, Brian Fisher wrote:

> That's what PyOpenGL 2.0 was - a C extension instead of ctypes. (made with
> SWIG)
>
> I actually still use PyOpenGL 2.0 for reasons other than performance
> (py2exe packaging) - I had to build it myself on windows for Python 2.5, you
> can get at an installer for it here:
> http://thorbrian.com/pyopengl/builds.php
>
> I've never performance tested the difference between it and 3.0 though - is
> somebody else could do that, I'd love to see the results
>
> On Mon, Mar 16, 2009 at 10:49 AM, Zack Schilling  > wrote:
>
>> If someone did this and I could drop it in to my code, that would be very
>> nice. But for right now, PyOpenGL is serving my needs just fine. I can use
>> about 600 independently textured and animated sprites onscreen, scaled and
>> rotated, without stressing a low-end system more than 40%.
>>
>> On Mar 16, 2009, at 1:00 PM, Forrest Voight wrote:
>>
>>  Would writing a replacement for PyOpenGL in C instead of in Python
>>> with ctypes help? I think it really would ... PyOpenGL is internally
>>> pretty complex, sometimes when I get tracebacks the error is 5 or 6
>>> levels into PyOpenGL. Even a C library that only implemented the
>>> common functions and relied on PyOpenGL for the constants and
>>> functions that do complex things like handling strings would probably
>>> help a lot.
>>>
>>>
 Another way to increase speed is to write an opengl rendering engine
 in C and call and make it available as a Python extension. This is
 a major speed boost, in particular for a large number of iterations.
 Iirc PyOpenGL bindings are generated, many times this is suboptimal
 code for what you're trying to do, writing the Python extension in C
 manually have been faster for me many times. This is indeed true
 if you put your iterations inside a C loop instead of calling the
 C function from Python many times.


>

Re: [pygame] Python - Pygame - PyOpenGL performance

[Brian Fisher]

That's what PyOpenGL 2.0 was - a C extension instead of ctypes. (made with
SWIG)

I actually still use PyOpenGL 2.0 for reasons other than performance (py2exe
packaging) - I had to build it myself on windows for Python 2.5, you can get
at an installer for it here:
http://thorbrian.com/pyopengl/builds.php

I've never performance tested the difference between it and 3.0 though - is
somebody else could do that, I'd love to see the results

On Mon, Mar 16, 2009 at 10:49 AM, Zack Schilling
wrote:

> If someone did this and I could drop it in to my code, that would be very
> nice. But for right now, PyOpenGL is serving my needs just fine. I can use
> about 600 independently textured and animated sprites onscreen, scaled and
> rotated, without stressing a low-end system more than 40%.
>
> On Mar 16, 2009, at 1:00 PM, Forrest Voight wrote:
>
>  Would writing a replacement for PyOpenGL in C instead of in Python
>> with ctypes help? I think it really would ... PyOpenGL is internally
>> pretty complex, sometimes when I get tracebacks the error is 5 or 6
>> levels into PyOpenGL. Even a C library that only implemented the
>> common functions and relied on PyOpenGL for the constants and
>> functions that do complex things like handling strings would probably
>> help a lot.
>>
>>
>>> Another way to increase speed is to write an opengl rendering engine
>>> in C and call and make it available as a Python extension. This is
>>> a major speed boost, in particular for a large number of iterations.
>>> Iirc PyOpenGL bindings are generated, many times this is suboptimal
>>> code for what you're trying to do, writing the Python extension in C
>>> manually have been faster for me many times. This is indeed true
>>> if you put your iterations inside a C loop instead of calling the
>>> C function from Python many times.
>>>
>>>

Re: [pygame] Python - Pygame - PyOpenGL performance

[Forrest Voight]

That's called a texture atlas, but be careful with the mipmaps. They
usually have to be generated specially I think.

http://http.download.nvidia.com/developer/NVTextureSuite/Atlas_Tools/Texture_Atlas_Whitepaper.pdf

On Mon, Mar 16, 2009 at 1:49 PM, Zack Schilling
 wrote:
> If someone did this and I could drop it in to my code, that would be very
> nice. But for right now, PyOpenGL is serving my needs just fine. I can use
> about 600 independently textured and animated sprites onscreen, scaled and
> rotated, without stressing a low-end system more than 40%.
>
> 40% is a significant amount of overhead, but Peter is wrong of a few points.
> You certainly can animate a sprite in OpenGL using texture coords. Just load
> all your animation frames, convert to strings, stick them all together, and
> pass to OpenGL as one very tall texture. This works perfectly fine. That
> means VBOs are definitely suitable. You can also push a VBO up piecemeal,
> changing the active texture between parts (and achieving the expected
> effect).
>
> Everything you see here is done with pygame and PyOpenGL:
> http://www.youtube.com/watch?v=cBFoXqKrBa8
>
> Positioning the quads directly doesn't seem to be too much of an issue,
> since in my game, they move each frame anyway. The cost of adding
> coordinates in Python and pushing them into a numpy array is much less than
> an OpenGL push, translate/rotate, pop call for each and every sprite. It
> makes a lot of sense to me that this would be the case in other languages as
> well.
>
> -Zack
>
> On Mar 16, 2009, at 1:00 PM, Forrest Voight wrote:
>
>> Would writing a replacement for PyOpenGL in C instead of in Python
>> with ctypes help? I think it really would ... PyOpenGL is internally
>> pretty complex, sometimes when I get tracebacks the error is 5 or 6
>> levels into PyOpenGL. Even a C library that only implemented the
>> common functions and relied on PyOpenGL for the constants and
>> functions that do complex things like handling strings would probably
>> help a lot.
>>
>> On Fri, Feb 27, 2009 at 11:19 AM, Peter Gebauer
>>  wrote:
>>>
>>> Hi!
>>>
>>> I've done a few sprite thingies in OpenGL here are some pointers:
>>>
>>> Afaik display lists and VBO's can't bind different textures (?)
>>> per list/array. You can't animate lists by changing texcoords
>>> independently per element, so no go. VBO's have texture coords,
>>> but only one texture. Again, I'm no expert, might be wrong.
>>>
>>> With the quad aproach you should try
>>> to make the number of calls as few as possible. If you get
>>> rid of the push and translate for each sprite you'll get some
>>> extra speed. Try positioning each quads directly. The downside
>>> with sharing matrix over all sprites is the obvious lack of
>>> using OpenGL transformations, but some vector math aplied to
>>> the quads has been faster for me than having one transformed
>>> matrix per quad.
>>>
>>> Since I haven't been able to animate a list/vbo with independent
>>> textures and texture coords for each element/buffer object I've only
>>> used it for backdrops. The speed increase is tremendous.
>>> I also partition the elements so only one list/vbo is displayed per
>>> visible section, if you're screen display is smaller than the
>>> entire scene, this helps even more.
>>>
>>> If you put all your sprites and their animation frames into one
>>> big texture you could use VBO's, but I've never had the tenacity
>>> to try that aproach.
>>>
>>> Another way to increase speed is to write an opengl rendering engine
>>> in C and call and make it available as a Python extension. This is
>>> a major speed boost, in particular for a large number of iterations.
>>> Iirc PyOpenGL bindings are generated, many times this is suboptimal
>>> code for what you're trying to do, writing the Python extension in C
>>> manually have been faster for me many times. This is indeed true
>>> if you put your iterations inside a C loop instead of calling the
>>> C function from Python many times.
>>>
>>> In any case, still waiting for that OO 2D game engine with tons of
>>> OpenGL features and effects, including simple things like frame
>>> animation,
>>> LERP-like features and a simple 2D scenegraph. No luck yet, all attempts
>>> I've tried so far lack at least one "must have" feature. :)
>>>
>>> /Peter
>>>
>>> On 2009-02-26 (Thu) 11:29, Casey Duncan wrote:

 Immediate mode calls (glVertex et al) are the very slowest way to use
 OpenGL. In fact they are deprecated in OpenGL 3.0 and will eventually be
 removed.

 The display list is better as you discovered, but you still are making a
 few OpenGL state changes per sprite, which is likely slowing you down.
 Also there is some overhead for the display list call, which makes them
 sub-optimal for just drawing a single quad.

>       glPushMatrix()
>       glTranslate(self.positionx,self.positiony,0)
>       glCallList(self.displist)
>       glPopMatrix()

 You really

Re: [pygame] Python - Pygame - PyOpenGL performance

[Zack Schilling]

If someone did this and I could drop it in to my code, that would be  
very nice. But for right now, PyOpenGL is serving my needs just fine.  
I can use about 600 independently textured and animated sprites  
onscreen, scaled and rotated, without stressing a low-end system more  
than 40%.


40% is a significant amount of overhead, but Peter is wrong of a few  
points. You certainly can animate a sprite in OpenGL using texture  
coords. Just load all your animation frames, convert to strings, stick  
them all together, and pass to OpenGL as one very tall texture. This  
works perfectly fine. That means VBOs are definitely suitable. You can  
also push a VBO up piecemeal, changing the active texture between  
parts (and achieving the expected effect).


Everything you see here is done with pygame and PyOpenGL: 
http://www.youtube.com/watch?v=cBFoXqKrBa8

Positioning the quads directly doesn't seem to be too much of an  
issue, since in my game, they move each frame anyway. The cost of  
adding coordinates in Python and pushing them into a numpy array is  
much less than an OpenGL push, translate/rotate, pop call for each and  
every sprite. It makes a lot of sense to me that this would be the  
case in other languages as well.


-Zack

On Mar 16, 2009, at 1:00 PM, Forrest Voight wrote:


Would writing a replacement for PyOpenGL in C instead of in Python
with ctypes help? I think it really would ... PyOpenGL is internally
pretty complex, sometimes when I get tracebacks the error is 5 or 6
levels into PyOpenGL. Even a C library that only implemented the
common functions and relied on PyOpenGL for the constants and
functions that do complex things like handling strings would probably
help a lot.

On Fri, Feb 27, 2009 at 11:19 AM, Peter Gebauer
 wrote:

Hi!

I've done a few sprite thingies in OpenGL here are some pointers:

Afaik display lists and VBO's can't bind different textures (?)
per list/array. You can't animate lists by changing texcoords
independently per element, so no go. VBO's have texture coords,
but only one texture. Again, I'm no expert, might be wrong.

With the quad aproach you should try
to make the number of calls as few as possible. If you get
rid of the push and translate for each sprite you'll get some
extra speed. Try positioning each quads directly. The downside
with sharing matrix over all sprites is the obvious lack of
using OpenGL transformations, but some vector math aplied to
the quads has been faster for me than having one transformed
matrix per quad.

Since I haven't been able to animate a list/vbo with independent
textures and texture coords for each element/buffer object I've only
used it for backdrops. The speed increase is tremendous.
I also partition the elements so only one list/vbo is displayed per
visible section, if you're screen display is smaller than the
entire scene, this helps even more.

If you put all your sprites and their animation frames into one
big texture you could use VBO's, but I've never had the tenacity
to try that aproach.

Another way to increase speed is to write an opengl rendering engine
in C and call and make it available as a Python extension. This is
a major speed boost, in particular for a large number of iterations.
Iirc PyOpenGL bindings are generated, many times this is suboptimal
code for what you're trying to do, writing the Python extension in C
manually have been faster for me many times. This is indeed true
if you put your iterations inside a C loop instead of calling the
C function from Python many times.

In any case, still waiting for that OO 2D game engine with tons of
OpenGL features and effects, including simple things like frame  
animation,
LERP-like features and a simple 2D scenegraph. No luck yet, all  
attempts

I've tried so far lack at least one "must have" feature. :)

/Peter

On 2009-02-26 (Thu) 11:29, Casey Duncan wrote:
Immediate mode calls (glVertex et al) are the very slowest way to  
use
OpenGL. In fact they are deprecated in OpenGL 3.0 and will  
eventually be

removed.

The display list is better as you discovered, but you still are  
making a
few OpenGL state changes per sprite, which is likely slowing you  
down.
Also there is some overhead for the display list call, which makes  
them

sub-optimal for just drawing a single quad.


   glPushMatrix()
   glTranslate(self.positionx,self.positiony,0)
   glCallList(self.displist)
   glPopMatrix()


You really need to batch the quads up into a few vertex arrays or  
vbos

to stream them to the card in one go. pyglet has a high-level python
sprite api that automates this for you fwiw.

-Casey

On Feb 26, 2009, at 11:04 AM, Zack Schilling wrote:

I know the PyOpenGL mailing list might be a better place to ask  
this
question, but I've had a lot of luck talking to the experienced  
people

here so I figured I'd try it first.

I'm trying to migrate a game I created from using the Pygame / SDL
software rendering to OpenGL. Before attempting the massive and
co

Re: [pygame] Python - Pygame - PyOpenGL performance

[Forrest Voight]

Would writing a replacement for PyOpenGL in C instead of in Python
with ctypes help? I think it really would ... PyOpenGL is internally
pretty complex, sometimes when I get tracebacks the error is 5 or 6
levels into PyOpenGL. Even a C library that only implemented the
common functions and relied on PyOpenGL for the constants and
functions that do complex things like handling strings would probably
help a lot.

On Fri, Feb 27, 2009 at 11:19 AM, Peter Gebauer
 wrote:
> Hi!
>
> I've done a few sprite thingies in OpenGL here are some pointers:
>
> Afaik display lists and VBO's can't bind different textures (?)
> per list/array. You can't animate lists by changing texcoords
> independently per element, so no go. VBO's have texture coords,
> but only one texture. Again, I'm no expert, might be wrong.
>
> With the quad aproach you should try
> to make the number of calls as few as possible. If you get
> rid of the push and translate for each sprite you'll get some
> extra speed. Try positioning each quads directly. The downside
> with sharing matrix over all sprites is the obvious lack of
> using OpenGL transformations, but some vector math aplied to
> the quads has been faster for me than having one transformed
> matrix per quad.
>
> Since I haven't been able to animate a list/vbo with independent
> textures and texture coords for each element/buffer object I've only
> used it for backdrops. The speed increase is tremendous.
> I also partition the elements so only one list/vbo is displayed per
> visible section, if you're screen display is smaller than the
> entire scene, this helps even more.
>
> If you put all your sprites and their animation frames into one
> big texture you could use VBO's, but I've never had the tenacity
> to try that aproach.
>
> Another way to increase speed is to write an opengl rendering engine
> in C and call and make it available as a Python extension. This is
> a major speed boost, in particular for a large number of iterations.
> Iirc PyOpenGL bindings are generated, many times this is suboptimal
> code for what you're trying to do, writing the Python extension in C
> manually have been faster for me many times. This is indeed true
> if you put your iterations inside a C loop instead of calling the
> C function from Python many times.
>
> In any case, still waiting for that OO 2D game engine with tons of
> OpenGL features and effects, including simple things like frame animation,
> LERP-like features and a simple 2D scenegraph. No luck yet, all attempts
> I've tried so far lack at least one "must have" feature. :)
>
> /Peter
>
> On 2009-02-26 (Thu) 11:29, Casey Duncan wrote:
>> Immediate mode calls (glVertex et al) are the very slowest way to use
>> OpenGL. In fact they are deprecated in OpenGL 3.0 and will eventually be
>> removed.
>>
>> The display list is better as you discovered, but you still are making a
>> few OpenGL state changes per sprite, which is likely slowing you down.
>> Also there is some overhead for the display list call, which makes them
>> sub-optimal for just drawing a single quad.
>>
>>>        glPushMatrix()
>>>        glTranslate(self.positionx,self.positiony,0)
>>>        glCallList(self.displist)
>>>        glPopMatrix()
>>
>> You really need to batch the quads up into a few vertex arrays or vbos
>> to stream them to the card in one go. pyglet has a high-level python
>> sprite api that automates this for you fwiw.
>>
>> -Casey
>>
>> On Feb 26, 2009, at 11:04 AM, Zack Schilling wrote:
>>
>>> I know the PyOpenGL mailing list might be a better place to ask this
>>> question, but I've had a lot of luck talking to the experienced people
>>> here so I figured I'd try it first.
>>>
>>> I'm trying to migrate a game I created from using the Pygame / SDL
>>> software rendering to OpenGL. Before attempting the massive and
>>> complex conversion involved with moving the whole game, I decided to
>>> make a little test program while I learned OpenGL.
>>>
>>> In this test, I set up OpenGL to work in 2D and began loading images
>>> into texture objects and drawing textured quads as sprites. I created a
>>> little glSprite class to handle the drawing and translation. At first
>>> its draw routine looked like this:
>>>
>>>        glPushMatrix()
>>>        glTranslate(self.positionx,self.positiony,0)
>>>        glBindTexture(GL_TEXTURE_2D, self.texture)
>>>        glBegin(GL_QUADS)
>>>        glTexCoord2f(0, 1)
>>>        glVertex2f(0, 0)
>>>        glTexCoord2f(1, 1)
>>>        glVertex2f(w, 0)
>>>        glTexCoord2f(1, 0)
>>>        glVertex2f(w, h)
>>>        glTexCoord2f(0, 0)
>>>        glVertex2f(0, h)
>>>        glEnd()
>>>        glPopMatrix()
>>>
>>> Note: self.texture is a texture ID of a loaded OpenGL texture object.
>>> My sprite class keeps a dictionary cache and only loads the sprite's
>>> image into a texture if it needs to.
>>>
>>> I'd get maybe 200 identical sprites (same texture) onscreen and my CPU
>>> would hit 100% load from Python execution. I looked in

Re: [pygame] Python - Pygame - PyOpenGL performance

[Peter Gebauer]

Hi!

I've done a few sprite thingies in OpenGL here are some pointers:

Afaik display lists and VBO's can't bind different textures (?)
per list/array. You can't animate lists by changing texcoords
independently per element, so no go. VBO's have texture coords,
but only one texture. Again, I'm no expert, might be wrong.

With the quad aproach you should try
to make the number of calls as few as possible. If you get
rid of the push and translate for each sprite you'll get some
extra speed. Try positioning each quads directly. The downside
with sharing matrix over all sprites is the obvious lack of
using OpenGL transformations, but some vector math aplied to
the quads has been faster for me than having one transformed
matrix per quad.

Since I haven't been able to animate a list/vbo with independent
textures and texture coords for each element/buffer object I've only
used it for backdrops. The speed increase is tremendous.
I also partition the elements so only one list/vbo is displayed per
visible section, if you're screen display is smaller than the
entire scene, this helps even more.

If you put all your sprites and their animation frames into one
big texture you could use VBO's, but I've never had the tenacity
to try that aproach.

Another way to increase speed is to write an opengl rendering engine
in C and call and make it available as a Python extension. This is
a major speed boost, in particular for a large number of iterations.
Iirc PyOpenGL bindings are generated, many times this is suboptimal
code for what you're trying to do, writing the Python extension in C
manually have been faster for me many times. This is indeed true
if you put your iterations inside a C loop instead of calling the
C function from Python many times.

In any case, still waiting for that OO 2D game engine with tons of
OpenGL features and effects, including simple things like frame animation,
LERP-like features and a simple 2D scenegraph. No luck yet, all attempts
I've tried so far lack at least one "must have" feature. :)

/Peter

On 2009-02-26 (Thu) 11:29, Casey Duncan wrote:
> Immediate mode calls (glVertex et al) are the very slowest way to use  
> OpenGL. In fact they are deprecated in OpenGL 3.0 and will eventually be 
> removed.
>
> The display list is better as you discovered, but you still are making a 
> few OpenGL state changes per sprite, which is likely slowing you down. 
> Also there is some overhead for the display list call, which makes them 
> sub-optimal for just drawing a single quad.
>
>>glPushMatrix()
>>glTranslate(self.positionx,self.positiony,0)
>>glCallList(self.displist)
>>glPopMatrix()
>
> You really need to batch the quads up into a few vertex arrays or vbos  
> to stream them to the card in one go. pyglet has a high-level python  
> sprite api that automates this for you fwiw.
>
> -Casey
>
> On Feb 26, 2009, at 11:04 AM, Zack Schilling wrote:
>
>> I know the PyOpenGL mailing list might be a better place to ask this  
>> question, but I've had a lot of luck talking to the experienced people 
>> here so I figured I'd try it first.
>>
>> I'm trying to migrate a game I created from using the Pygame / SDL  
>> software rendering to OpenGL. Before attempting the massive and  
>> complex conversion involved with moving the whole game, I decided to  
>> make a little test program while I learned OpenGL.
>>
>> In this test, I set up OpenGL to work in 2D and began loading images  
>> into texture objects and drawing textured quads as sprites. I created a 
>> little glSprite class to handle the drawing and translation. At first 
>> its draw routine looked like this:
>>
>>glPushMatrix()
>>glTranslate(self.positionx,self.positiony,0)
>>glBindTexture(GL_TEXTURE_2D, self.texture)
>>glBegin(GL_QUADS)
>>glTexCoord2f(0, 1)
>>glVertex2f(0, 0)
>>glTexCoord2f(1, 1)
>>glVertex2f(w, 0)
>>glTexCoord2f(1, 0)
>>glVertex2f(w, h)
>>glTexCoord2f(0, 0)
>>glVertex2f(0, h)
>>glEnd()
>>glPopMatrix()
>>
>> Note: self.texture is a texture ID of a loaded OpenGL texture object. 
>> My sprite class keeps a dictionary cache and only loads the sprite's 
>> image into a texture if it needs to.
>>
>> I'd get maybe 200 identical sprites (same texture) onscreen and my CPU 
>> would hit 100% load from Python execution. I looked into what could be 
>> causing this and found out that it's probably function call overhead. 
>> That's 14 external library function calls per sprite draw.
>>
>> The next thing I tried was to create a display list at each sprite's  
>> initialization. Then my code looked like this:
>>glPushMatrix()
>>glTranslate(self.positionx,self.positiony,0)
>>glCallList(self.displist)
>>glPopMatrix()
>>
>> Well, that's nice, down to 4 calls per draw. I was able to push ~500  
>> sprites per frame using this method before the CPU tapped out. I need 
>> more spee

Re: [pygame] Python - Pygame - PyOpenGL performance

[Zack Schilling]

I spent a good portion of this evening updating my glSprite class to  
use VBOs to render. I was able to push 1800 individually animated,  
arbitrarily sized sprites at 60FPS before my CPU tapped out. That's  
more than 3 times faster than the display lists.


I've done some performance analysis on my code and found that the  
largest bottleneck by far is iterating through my game objects and  
populating the NumPy array that gets streamed off to the GPU (I've  
already made sure that I never duplicate, copy or type convert the  
array at any time.). The actual streaming and draw calls are  
negligible by comparison.  I tried hard-coding the arrays to see just  
how much CPU the streaming and drawing took, but I was never able to  
get it past 20%, no matter how many quads I told it to draw.


So I guess I'll continue looking for ways to keep pushing that array  
population faster. It looks like I've gotten the OpenGL side of things  
running as quickly as technically possible. Thanks everyone for the  
nudges in the right direction.


-Zack


On Feb 26, 2009, at 3:06 PM, Ian Mallett wrote:


There are certain easy ways to optimize certain techniques.

For example, I wanted an OpenGL program with many many particles.
They had only to be one color, and should be pretty small.  The
solution was to use shaders to draw points.  I got over one million
(1024**2) particles at 50fps using this technique.  Still, the
solutution ended up being pretty complicated.

I'm guessing that for better results, you'll likewise want something
more complex.  There's not really a way around it.  Display lists are
the easiest method I've seen for drastically improving performance.
If you want faster, you'll need more code.

Ian

Re: [pygame] Python - Pygame - PyOpenGL performance

[Ian Mallett]

There are certain easy ways to optimize certain techniques.

For example, I wanted an OpenGL program with many many particles.
They had only to be one color, and should be pretty small.  The
solution was to use shaders to draw points.  I got over one million
(1024**2) particles at 50fps using this technique.  Still, the
solutution ended up being pretty complicated.

I'm guessing that for better results, you'll likewise want something
more complex.  There's not really a way around it.  Display lists are
the easiest method I've seen for drastically improving performance.
If you want faster, you'll need more code.

Ian

Re: [pygame] Python - Pygame - PyOpenGL performance

[Zack Schilling]

I'm on a Macbook Pro with a GeForce 8600M GT. Textures are loaded with  
GL_LINEAR. Here's the texture loading code:


# Create an OpenGL texture with it and place it in the system
glEnable(GL_TEXTURE_2D)
rgbadata = pygame.image.tostring(image, "RGBA", True)
texture = glGenTextures(1)
glBindTexture(GL_TEXTURE_2D, texture)
glTexImage2D(GL_TEXTURE_2D, 0, 4, w, h, 0, GL_RGBA,  
GL_UNSIGNED_BYTE, rgbadata)

glTexParameter(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR)
glTexParameter(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR)

Casey Duncan has pretty much confirmed my suspicions. I guess I'll end  
up creating a sprite class that uses vertex arrays or vertex buffer  
objects and presses all the animation frames I need into one texture  
at loading time. Then I'll use a texture map array to move the texture  
around so that each sprite can animate independently.


Thanks for your help. If anyone else has any design patterns I might  
find useful, let me know. I'm very new to OpenGL and most tutorials  
teach you how to get things done, but never the proper way.


-Zack


On Feb 26, 2009, at 2:23 PM, RB[0] wrote:

Hmm, how are you loading your textures - GL_NEAREST or are you using  
LINEAR or Mip mapped filtering?
Otherwise, only thing I can think of is you might have a cruddy card  
that is dumping some odd functionality to your cpu instead of gpu?


On Thu, Feb 26, 2009 at 1:17 PM, Zack Schilling > wrote:
That was the first thing I tried. Using a dummy draw function that  
crunched a few numbers instead of doing the OpenGL calls. That  
worked fine and let me create thousands and thousands of sprites  
before the CPU tapped out.


No I'm not using psyco or any other performance enhancer.

-Zack



On Feb 26, 2009, at 2:08 PM, RB[0] wrote:

Well, most likely your main speed down is looping through all those  
sprites as it is - trying just looping through them and calling a  
dummy function instead of the opengl one - and see what happens -  
otherwise, that seems quite odd to me, I haven't run into that  
before (are you using psyco, perhaps?)


On Thu, Feb 26, 2009 at 1:04 PM, Zack Schilling > wrote:
I know the PyOpenGL mailing list might be a better place to ask this  
question, but I've had a lot of luck talking to the experienced  
people here so I figured I'd try it first.


I'm trying to migrate a game I created from using the Pygame / SDL  
software rendering to OpenGL. Before attempting the massive and  
complex conversion involved with moving the whole game, I decided to  
make a little test program while I learned OpenGL.


In this test, I set up OpenGL to work in 2D and began loading images  
into texture objects and drawing textured quads as sprites. I  
created a little glSprite class to handle the drawing and  
translation. At first its draw routine looked like this:


  glPushMatrix()
  glTranslate(self.positionx,self.positiony,0)
  glBindTexture(GL_TEXTURE_2D, self.texture)
  glBegin(GL_QUADS)
  glTexCoord2f(0, 1)
  glVertex2f(0, 0)
  glTexCoord2f(1, 1)
  glVertex2f(w, 0)
  glTexCoord2f(1, 0)
  glVertex2f(w, h)
  glTexCoord2f(0, 0)
  glVertex2f(0, h)
  glEnd()
  glPopMatrix()

Note: self.texture is a texture ID of a loaded OpenGL texture  
object. My sprite class keeps a dictionary cache and only loads the  
sprite's image into a texture if it needs to.


I'd get maybe 200 identical sprites (same texture) onscreen and my  
CPU would hit 100% load from Python execution. I looked into what  
could be causing this and found out that it's probably function call  
overhead. That's 14 external library function calls per sprite draw.


The next thing I tried was to create a display list at each sprite's  
initialization. Then my code looked like this:

  glPushMatrix()
  glTranslate(self.positionx,self.positiony,0)
  glCallList(self.displist)
  glPopMatrix()

Well, that's nice, down to 4 calls per draw. I was able to push ~500  
sprites per frame using this method before the CPU tapped out. I  
need more speed than this. My game logic uses 30-40% of the CPU  
alone and I'd like to push at least 1000 sprites. What can I do?  
I've looked into passing sprites as a matrix with vertex arrays, but  
forming a proper vertex array with numpy can sometimes be more  
trouble than it's worth. Plus, I can't swap out textures easily mid- 
draw, so it makes things much more complex than the simple way I'm  
doing things now.


Is there any design pattern I could follow that will get me more  
speed without sending me off the deep end with complexity.


Thanks,

Zack

Re: [pygame] Python - Pygame - PyOpenGL performance

[Casey Duncan]

Immediate mode calls (glVertex et al) are the very slowest way to use  
OpenGL. In fact they are deprecated in OpenGL 3.0 and will eventually  
be removed.


The display list is better as you discovered, but you still are making  
a few OpenGL state changes per sprite, which is likely slowing you  
down. Also there is some overhead for the display list call, which  
makes them sub-optimal for just drawing a single quad.



   glPushMatrix()
   glTranslate(self.positionx,self.positiony,0)
   glCallList(self.displist)
   glPopMatrix()


You really need to batch the quads up into a few vertex arrays or vbos  
to stream them to the card in one go. pyglet has a high-level python  
sprite api that automates this for you fwiw.


-Casey

On Feb 26, 2009, at 11:04 AM, Zack Schilling wrote:

I know the PyOpenGL mailing list might be a better place to ask this  
question, but I've had a lot of luck talking to the experienced  
people here so I figured I'd try it first.


I'm trying to migrate a game I created from using the Pygame / SDL  
software rendering to OpenGL. Before attempting the massive and  
complex conversion involved with moving the whole game, I decided to  
make a little test program while I learned OpenGL.


In this test, I set up OpenGL to work in 2D and began loading images  
into texture objects and drawing textured quads as sprites. I  
created a little glSprite class to handle the drawing and  
translation. At first its draw routine looked like this:


   glPushMatrix()
   glTranslate(self.positionx,self.positiony,0)
   glBindTexture(GL_TEXTURE_2D, self.texture)
   glBegin(GL_QUADS)
   glTexCoord2f(0, 1)
   glVertex2f(0, 0)
   glTexCoord2f(1, 1)
   glVertex2f(w, 0)
   glTexCoord2f(1, 0)
   glVertex2f(w, h)
   glTexCoord2f(0, 0)
   glVertex2f(0, h)
   glEnd()
   glPopMatrix()

Note: self.texture is a texture ID of a loaded OpenGL texture  
object. My sprite class keeps a dictionary cache and only loads the  
sprite's image into a texture if it needs to.


I'd get maybe 200 identical sprites (same texture) onscreen and my  
CPU would hit 100% load from Python execution. I looked into what  
could be causing this and found out that it's probably function call  
overhead. That's 14 external library function calls per sprite draw.


The next thing I tried was to create a display list at each sprite's  
initialization. Then my code looked like this:

   glPushMatrix()
   glTranslate(self.positionx,self.positiony,0)
   glCallList(self.displist)
   glPopMatrix()

Well, that's nice, down to 4 calls per draw. I was able to push ~500  
sprites per frame using this method before the CPU tapped out. I  
need more speed than this. My game logic uses 30-40% of the CPU  
alone and I'd like to push at least 1000 sprites. What can I do?  
I've looked into passing sprites as a matrix with vertex arrays, but  
forming a proper vertex array with numpy can sometimes be more  
trouble than it's worth. Plus, I can't swap out textures easily mid- 
draw, so it makes things much more complex than the simple way I'm  
doing things now.


Is there any design pattern I could follow that will get me more  
speed without sending me off the deep end with complexity.


Thanks,

Zack

Re: [pygame] Python - Pygame - PyOpenGL performance

[RB[0]]

Hmm, how are you loading your textures - GL_NEAREST or are you using LINEAR
or Mip mapped filtering?
Otherwise, only thing I can think of is you might have a cruddy card that is
dumping some odd functionality to your cpu instead of gpu?

On Thu, Feb 26, 2009 at 1:17 PM, Zack Schilling wrote:

> That was the first thing I tried. Using a dummy draw function that crunched
> a few numbers instead of doing the OpenGL calls. That worked fine and let me
> create thousands and thousands of sprites before the CPU tapped out.
>
> No I'm not using psyco or any other performance enhancer.
>
> -Zack
>
>
>
> On Feb 26, 2009, at 2:08 PM, RB[0] wrote:
>
>  Well, most likely your main speed down is looping through all those
>> sprites as it is - trying just looping through them and calling a dummy
>> function instead of the opengl one - and see what happens - otherwise, that
>> seems quite odd to me, I haven't run into that before (are you using psyco,
>> perhaps?)
>>
>> On Thu, Feb 26, 2009 at 1:04 PM, Zack Schilling 
>> wrote:
>> I know the PyOpenGL mailing list might be a better place to ask this
>> question, but I've had a lot of luck talking to the experienced people here
>> so I figured I'd try it first.
>>
>> I'm trying to migrate a game I created from using the Pygame / SDL
>> software rendering to OpenGL. Before attempting the massive and complex
>> conversion involved with moving the whole game, I decided to make a little
>> test program while I learned OpenGL.
>>
>> In this test, I set up OpenGL to work in 2D and began loading images into
>> texture objects and drawing textured quads as sprites. I created a little
>> glSprite class to handle the drawing and translation. At first its draw
>> routine looked like this:
>>
>>   glPushMatrix()
>>   glTranslate(self.positionx,self.positiony,0)
>>   glBindTexture(GL_TEXTURE_2D, self.texture)
>>   glBegin(GL_QUADS)
>>   glTexCoord2f(0, 1)
>>   glVertex2f(0, 0)
>>   glTexCoord2f(1, 1)
>>   glVertex2f(w, 0)
>>   glTexCoord2f(1, 0)
>>   glVertex2f(w, h)
>>   glTexCoord2f(0, 0)
>>   glVertex2f(0, h)
>>   glEnd()
>>   glPopMatrix()
>>
>> Note: self.texture is a texture ID of a loaded OpenGL texture object. My
>> sprite class keeps a dictionary cache and only loads the sprite's image into
>> a texture if it needs to.
>>
>> I'd get maybe 200 identical sprites (same texture) onscreen and my CPU
>> would hit 100% load from Python execution. I looked into what could be
>> causing this and found out that it's probably function call overhead. That's
>> 14 external library function calls per sprite draw.
>>
>> The next thing I tried was to create a display list at each sprite's
>> initialization. Then my code looked like this:
>>   glPushMatrix()
>>   glTranslate(self.positionx,self.positiony,0)
>>   glCallList(self.displist)
>>   glPopMatrix()
>>
>> Well, that's nice, down to 4 calls per draw. I was able to push ~500
>> sprites per frame using this method before the CPU tapped out. I need more
>> speed than this. My game logic uses 30-40% of the CPU alone and I'd like to
>> push at least 1000 sprites. What can I do? I've looked into passing sprites
>> as a matrix with vertex arrays, but forming a proper vertex array with numpy
>> can sometimes be more trouble than it's worth. Plus, I can't swap out
>> textures easily mid-draw, so it makes things much more complex than the
>> simple way I'm doing things now.
>>
>> Is there any design pattern I could follow that will get me more speed
>> without sending me off the deep end with complexity.
>>
>> Thanks,
>>
>> Zack
>>
>>
>

Re: [pygame] Python - Pygame - PyOpenGL performance

[Zack Schilling]

That was the first thing I tried. Using a dummy draw function that  
crunched a few numbers instead of doing the OpenGL calls. That worked  
fine and let me create thousands and thousands of sprites before the  
CPU tapped out.


No I'm not using psyco or any other performance enhancer.

-Zack


On Feb 26, 2009, at 2:08 PM, RB[0] wrote:

Well, most likely your main speed down is looping through all those  
sprites as it is - trying just looping through them and calling a  
dummy function instead of the opengl one - and see what happens -  
otherwise, that seems quite odd to me, I haven't run into that  
before (are you using psyco, perhaps?)


On Thu, Feb 26, 2009 at 1:04 PM, Zack Schilling > wrote:
I know the PyOpenGL mailing list might be a better place to ask this  
question, but I've had a lot of luck talking to the experienced  
people here so I figured I'd try it first.


I'm trying to migrate a game I created from using the Pygame / SDL  
software rendering to OpenGL. Before attempting the massive and  
complex conversion involved with moving the whole game, I decided to  
make a little test program while I learned OpenGL.


In this test, I set up OpenGL to work in 2D and began loading images  
into texture objects and drawing textured quads as sprites. I  
created a little glSprite class to handle the drawing and  
translation. At first its draw routine looked like this:


   glPushMatrix()
   glTranslate(self.positionx,self.positiony,0)
   glBindTexture(GL_TEXTURE_2D, self.texture)
   glBegin(GL_QUADS)
   glTexCoord2f(0, 1)
   glVertex2f(0, 0)
   glTexCoord2f(1, 1)
   glVertex2f(w, 0)
   glTexCoord2f(1, 0)
   glVertex2f(w, h)
   glTexCoord2f(0, 0)
   glVertex2f(0, h)
   glEnd()
   glPopMatrix()

Note: self.texture is a texture ID of a loaded OpenGL texture  
object. My sprite class keeps a dictionary cache and only loads the  
sprite's image into a texture if it needs to.


I'd get maybe 200 identical sprites (same texture) onscreen and my  
CPU would hit 100% load from Python execution. I looked into what  
could be causing this and found out that it's probably function call  
overhead. That's 14 external library function calls per sprite draw.


The next thing I tried was to create a display list at each sprite's  
initialization. Then my code looked like this:

   glPushMatrix()
   glTranslate(self.positionx,self.positiony,0)
   glCallList(self.displist)
   glPopMatrix()

Well, that's nice, down to 4 calls per draw. I was able to push ~500  
sprites per frame using this method before the CPU tapped out. I  
need more speed than this. My game logic uses 30-40% of the CPU  
alone and I'd like to push at least 1000 sprites. What can I do?  
I've looked into passing sprites as a matrix with vertex arrays, but  
forming a proper vertex array with numpy can sometimes be more  
trouble than it's worth. Plus, I can't swap out textures easily mid- 
draw, so it makes things much more complex than the simple way I'm  
doing things now.


Is there any design pattern I could follow that will get me more  
speed without sending me off the deep end with complexity.


Thanks,

Zack

Re: [pygame] Python - Pygame - PyOpenGL performance

[RB[0]]

Well, most likely your main speed down is looping through all those sprites
as it is - trying just looping through them and calling a dummy function
instead of the opengl one - and see what happens - otherwise, that seems
quite odd to me, I haven't run into that before (are you using psyco,
perhaps?)

On Thu, Feb 26, 2009 at 1:04 PM, Zack Schilling wrote:

> I know the PyOpenGL mailing list might be a better place to ask this
> question, but I've had a lot of luck talking to the experienced people here
> so I figured I'd try it first.
>
> I'm trying to migrate a game I created from using the Pygame / SDL software
> rendering to OpenGL. Before attempting the massive and complex conversion
> involved with moving the whole game, I decided to make a little test program
> while I learned OpenGL.
>
> In this test, I set up OpenGL to work in 2D and began loading images into
> texture objects and drawing textured quads as sprites. I created a little
> glSprite class to handle the drawing and translation. At first its draw
> routine looked like this:
>
>glPushMatrix()
>glTranslate(self.positionx,self.positiony,0)
>glBindTexture(GL_TEXTURE_2D, self.texture)
>glBegin(GL_QUADS)
>glTexCoord2f(0, 1)
>glVertex2f(0, 0)
>glTexCoord2f(1, 1)
>glVertex2f(w, 0)
>glTexCoord2f(1, 0)
>glVertex2f(w, h)
>glTexCoord2f(0, 0)
>glVertex2f(0, h)
>glEnd()
>glPopMatrix()
>
> Note: self.texture is a texture ID of a loaded OpenGL texture object. My
> sprite class keeps a dictionary cache and only loads the sprite's image into
> a texture if it needs to.
>
> I'd get maybe 200 identical sprites (same texture) onscreen and my CPU
> would hit 100% load from Python execution. I looked into what could be
> causing this and found out that it's probably function call overhead. That's
> 14 external library function calls per sprite draw.
>
> The next thing I tried was to create a display list at each sprite's
> initialization. Then my code looked like this:
>glPushMatrix()
>glTranslate(self.positionx,self.positiony,0)
>glCallList(self.displist)
>glPopMatrix()
>
> Well, that's nice, down to 4 calls per draw. I was able to push ~500
> sprites per frame using this method before the CPU tapped out. I need more
> speed than this. My game logic uses 30-40% of the CPU alone and I'd like to
> push at least 1000 sprites. What can I do? I've looked into passing sprites
> as a matrix with vertex arrays, but forming a proper vertex array with numpy
> can sometimes be more trouble than it's worth. Plus, I can't swap out
> textures easily mid-draw, so it makes things much more complex than the
> simple way I'm doing things now.
>
> Is there any design pattern I could follow that will get me more speed
> without sending me off the deep end with complexity.
>
> Thanks,
>
> Zack
>

[pygame] Python - Pygame - PyOpenGL performance

[Zack Schilling]

I know the PyOpenGL mailing list might be a better place to ask this  
question, but I've had a lot of luck talking to the experienced people  
here so I figured I'd try it first.


I'm trying to migrate a game I created from using the Pygame / SDL  
software rendering to OpenGL. Before attempting the massive and  
complex conversion involved with moving the whole game, I decided to  
make a little test program while I learned OpenGL.


In this test, I set up OpenGL to work in 2D and began loading images  
into texture objects and drawing textured quads as sprites. I created  
a little glSprite class to handle the drawing and translation. At  
first its draw routine looked like this:


glPushMatrix()
glTranslate(self.positionx,self.positiony,0)
glBindTexture(GL_TEXTURE_2D, self.texture)
glBegin(GL_QUADS)
glTexCoord2f(0, 1)
glVertex2f(0, 0)
glTexCoord2f(1, 1)
glVertex2f(w, 0)
glTexCoord2f(1, 0)
glVertex2f(w, h)
glTexCoord2f(0, 0)
glVertex2f(0, h)
glEnd()
glPopMatrix()

Note: self.texture is a texture ID of a loaded OpenGL texture object.  
My sprite class keeps a dictionary cache and only loads the sprite's  
image into a texture if it needs to.


I'd get maybe 200 identical sprites (same texture) onscreen and my CPU  
would hit 100% load from Python execution. I looked into what could be  
causing this and found out that it's probably function call overhead.  
That's 14 external library function calls per sprite draw.


The next thing I tried was to create a display list at each sprite's  
initialization. Then my code looked like this:

glPushMatrix()
glTranslate(self.positionx,self.positiony,0)
glCallList(self.displist)
glPopMatrix()

Well, that's nice, down to 4 calls per draw. I was able to push ~500  
sprites per frame using this method before the CPU tapped out. I need  
more speed than this. My game logic uses 30-40% of the CPU alone and  
I'd like to push at least 1000 sprites. What can I do? I've looked  
into passing sprites as a matrix with vertex arrays, but forming a  
proper vertex array with numpy can sometimes be more trouble than it's  
worth. Plus, I can't swap out textures easily mid-draw, so it makes  
things much more complex than the simple way I'm doing things now.


Is there any design pattern I could follow that will get me more speed  
without sending me off the deep end with complexity.


Thanks,

Zack

Re: [pygame] gui with pygame + pyopengl

[Astan Chee]

Hi,
Thanks for the suggestion and Im trying it out with pgu. Now Im having 
problems with the pgu interface. Can anyone help me?
I've attached my test code. Its basically a button or event that brings 
up a text entry dialog. So far its fine, as soon as the dialog is 
closed, it wont close. Any ideas?

Cheers
Stan

René Dudfield wrote:

hi,

Lamina allows you to use any pygame 2d gui with opengl.
http://pitchersduel.python-hosting.com/browser/branches/Lamina/

It's fairly easy to use, and comes with demos for ocempgui and pgu.

cheers,



On Wed, Jun 18, 2008 at 2:58 PM, Astan Chee <[EMAIL PROTECTED]> wrote:
  

Hi,
I was wondering if there is a way to get a simple text entry dialog on a
pygame+opengl surface. I've tried several and all of them seem to dislike
doing a .blit on a opengl surface and crash badly whenever I do anything on
it. Are there simple alternatives?
Thanks
Astan

--
"Formulations of number theory: Complete, Consistent, Non-trivial. Choose
two."


Animal Logic
http://www.animallogic.com

Please think of the environment before printing this email.

This email and any attachments may be confidential and/or privileged. If you
are not the intended recipient of this email, you must not disclose or use
the information contained in it. Please notify the sender immediately and
delete this document if you have received it in error. We do not guarantee
this email is error or virus free.







  


--
"Formulations of number theory: Complete, Consistent, Non-trivial. Choose two."



Animal Logic
http://www.animallogic.com

Please think of the environment before printing this email.

This email and any attachments may be confidential and/or privileged. If you 
are not the intended recipient of this email, you must not disclose or use the 
information contained in it. Please notify the sender immediately and delete 
this document if you have received it in error. We do not guarantee this email 
is error or virus free.

#!/usr/bin/env python
# demo of laminar.PanelOverlaySurface, by
#  David Keeney 2006
# based on version of Nehe's OpenGL lesson04
#  by Paul Furber 2001 - [EMAIL PROTECTED]

# you need pgu to be installed, and you need a copy of the default theme directory
#   as 'test_theme', and you need the accompanying config.txt in that test_theme dir.

import sys
sys.path.insert( 0, '..' )

from OpenGL.GL import *
from OpenGL.GLU import *
import pygame
from pygame.locals import *

# import gui stuff
try:
from pgu import gui as pgui
except ImportError:
print "PGU GUI must be installed in order to run this demo. "
print "PGU can be obtained from: "
print " https://sourceforge.net/project/showfiles.php?group_id=145281";
sys.exit()

import lamina

rtri = rquad = 0.0

triOn = quadOn = True
zoomAngle = 45
open_d = None

class OpenDialog(pgui.Dialog):
def __init__(self,**params):
title = pgui.Label("Input Position")

t = pgui.Table()

self.value = pgui.Form()

t.tr()
t.td(pgui.Label("Position: "))
t.td(pgui.Input(name="pos"),colspan=3)

t.tr()
e = pgui.Button("Ok")
e.connect(pgui.CLICK,self.send,pgui.CHANGE)
t.td(e,colspan=2)

e = pgui.Button("Cancel")
e.connect(pgui.CLICK,self.close,None)
t.td(e,colspan=2)

pgui.Dialog.__init__(self,title,t)

def resize((width, height)):
if height==0:
height=1
glViewport(0, 0, width, height)
glMatrixMode(GL_PROJECTION)
glLoadIdentity()
gluPerspective(zoomAngle, 1.0*width/height, 0.1, 100.0)
glMatrixMode(GL_MODELVIEW)
glLoadIdentity()

def init():
glShadeModel(GL_SMOOTH)
glClearColor(0.0, 0.5, 0.0, 0.0)
glClearDepth(1.0)
glEnable(GL_DEPTH_TEST)
glDepthFunc(GL_LEQUAL)
glHint(GL_PERSPECTIVE_CORRECTION_HINT, GL_NICEST)

def draw():

glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT)
glLoadIdentity()
glTranslatef(-1.5, 0.0, -6.0)

# draw triangle
global rtri
glRotatef(rtri, 0.0, 1.0, 0.0)

glBegin(GL_TRIANGLES)
glColor3f(1.0, 0.0, 0.0)
glVertex3f(0.0, 1.0, 0.0)
glColor3f(0.0, 1.0, 0.0)
glVertex3f(-1.0, -1.0, 0)
glColor3f(0.0, 0.0, 1.0)
glVertex3f(1.0, -1.0, 0)
glEnd()

# draw quad
glLoadIdentity()
glTranslatef(1.5, 0.0, -6.0)
global rquad
glRotatef(rquad, 1.0, 0.0, 0.0)

glColor3f(0.5, 0.5, 1.0)
glBegin(GL_QUADS)
glVertex3f(-1.0, 1.0, 0)
glVertex3f(1.0, 1.0, 0)
glVertex3f(1.0, -1.0, 0)
glVertex3f(-1.0, -1.0, 0)
glEnd()

# draw gui
glLoadIdentity()
global gui_screen
gui_screen.display()


def main():

global rtri, rquad, gui_screen, open_d
video_flags = OPENGL|DOUBLEBUF

pygame.init()
pygame.display.set_mode((640,480), video_flags)
font = pygame.font.SysFont("default", 18)
fontBig = pygame.font.SysFont("default", 24)
fontSub = pygame.font.SysFont("default", 20)
theme = pgui.

Re: [pygame] gui with pygame + pyopengl

[René Dudfield]

hi,

Lamina allows you to use any pygame 2d gui with opengl.
http://pitchersduel.python-hosting.com/browser/branches/Lamina/

It's fairly easy to use, and comes with demos for ocempgui and pgu.

cheers,



On Wed, Jun 18, 2008 at 2:58 PM, Astan Chee <[EMAIL PROTECTED]> wrote:
> Hi,
> I was wondering if there is a way to get a simple text entry dialog on a
> pygame+opengl surface. I've tried several and all of them seem to dislike
> doing a .blit on a opengl surface and crash badly whenever I do anything on
> it. Are there simple alternatives?
> Thanks
> Astan
>
> --
> "Formulations of number theory: Complete, Consistent, Non-trivial. Choose
> two."
>
>
> Animal Logic
> http://www.animallogic.com
>
> Please think of the environment before printing this email.
>
> This email and any attachments may be confidential and/or privileged. If you
> are not the intended recipient of this email, you must not disclose or use
> the information contained in it. Please notify the sender immediately and
> delete this document if you have received it in error. We do not guarantee
> this email is error or virus free.
>
>
>
>

[pygame] gui with pygame + pyopengl

[Astan Chee]

Hi,
I was wondering if there is a way to get a simple text entry dialog on a 
pygame+opengl surface. I've tried several and all of them seem to 
dislike doing a .blit on a opengl surface and crash badly whenever I do 
anything on it. Are there simple alternatives?

Thanks
Astan

--
"Formulations of number theory: Complete, Consistent, Non-trivial. Choose two."


Animal Logic
http://www.animallogic.com

Please think of the environment before printing this email.

This email and any attachments may be confidential and/or privileged. If you 
are not the intended recipient of this email, you must not disclose or use the 
information contained in it. Please notify the sender immediately and delete 
this document if you have received it in error. We do not guarantee this email 
is error or virus free.

Re: [pygame] pyopengl sprite/particle performance

[flx]

2008/6/16 Hugo Arts <[EMAIL PROTECTED]>:
> Your bottleneck might not be in your rendering code. I don't know wether
> PyOpenGL is even supposed to be much faster than pygame, but if rendering is
> not where your bottleneck is, switching will not help at all.
You are right, i'll try something like sprite pooling for particles or
something similar.

> I didn't look at the code, but in the profile it seems _collide_bullet is a
> frequently used method. Are you using a naive collision detection algorithm?
> In that case, something like a quadtree or cell-based collision detection
> approach may heavily improve the performance of your game.

The collision detection is a simple bounding spheres method using
square distances, I don't think that building a quadtree would be much
faster but I'll give it a try too when i have some time

Aniway, i believe that particles are what are making the whole thing
lag and they aren't counted for collisions, so i'll check the particle
updating methods

>
> Hugo

thanks for your reply

>> [1] - http://code.google.com/p/pyship/
>>
>> --
>> .__.·º(foolhu!)
>> (oO)
>> / | | \




-- 
.__.·º(foolhu!)
(oO)
/ | | \

Re: [pygame] pyopengl sprite/particle performance

[Hugo Arts]

Your bottleneck might not be in your rendering code. I don't know wether
PyOpenGL is even supposed to be much faster than pygame, but if rendering is
not where your bottleneck is, switching will not help at all.

I didn't look at the code, but in the profile it seems _collide_bullet is a
frequently used method. Are you using a naive collision detection algorithm?
In that case, something like a quadtree or cell-based collision detection
approach may heavily improve the performance of your game.

Hugo

On Sun, Jun 15, 2008 at 10:21 PM, flx <[EMAIL PROTECTED]> wrote:

> Hi all
>
> I've been fidling for some time with pygame on a tryout project [1],
> it's a fast 2d action game.
>
> After a while i switched the drawing code to pyopengl looking for a
> litle performance boost, but i haven't got the expected results, i
> have had to lower the global fps from 60 to 30 and even then, it lags
> with 150-200 sprites on screen.
>
> I know there must be something wrong with my code because  there are
> more complicated things drawn with pyopengl.
>
> This are the first lines of profiling output (switch to monospace font now
> ;) )
> 6202178 function calls in 52.748 CPU seconds
>
>   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
>   1480666.5070.000   28.7800.000 gl.py:114(draw)
>   2006205.5320.000   27.8060.000 wrapper.py:650(wrapperCall)
>   2006163.8280.0003.8280.000 numpymodule.py:114(contiguous)
>   2006163.5790.0005.6220.000 numpymodule.py:19(dataPointer)
>   7665402.8030.0003.0000.000 error.py:167(glCheckError)
>   4406602.3680.0003.8150.000 ship.py:60(_collide_bullet)
>
> code referenced is on [1] or running > svn checkout
> http://pyship.googlecode.com/svn/trunk/ pyship < recomended since the
> tarbal is several days old and there are some particle and sprite
> especific examples on the svn
>
> [1] - http://code.google.com/p/pyship/
>
> --
> .__.·º(foolhu!)
> (oO)
> / | | \
>

[pygame] pyopengl sprite/particle performance

[flx]

Hi all

I've been fidling for some time with pygame on a tryout project [1],
it's a fast 2d action game.

After a while i switched the drawing code to pyopengl looking for a
litle performance boost, but i haven't got the expected results, i
have had to lower the global fps from 60 to 30 and even then, it lags
with 150-200 sprites on screen.

I know there must be something wrong with my code because  there are
more complicated things drawn with pyopengl.

This are the first lines of profiling output (switch to monospace font now ;) )
 6202178 function calls in 52.748 CPU seconds

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
   1480666.5070.000   28.7800.000 gl.py:114(draw)
   2006205.5320.000   27.8060.000 wrapper.py:650(wrapperCall)
   2006163.8280.0003.8280.000 numpymodule.py:114(contiguous)
   2006163.5790.0005.6220.000 numpymodule.py:19(dataPointer)
   7665402.8030.0003.0000.000 error.py:167(glCheckError)
   4406602.3680.0003.8150.000 ship.py:60(_collide_bullet)

code referenced is on [1] or running > svn checkout
http://pyship.googlecode.com/svn/trunk/ pyship < recomended since the
tarbal is several days old and there are some particle and sprite
especific examples on the svn

[1] - http://code.google.com/p/pyship/

-- 
.__.·º(foolhu!)
(oO)
/ | | \

RE: BUG: pygame.image.save(screen) with pyopengl 3.x Re: [pygame] PyOpenGL Screenshots

[Nicholas Dudfield]

Hi,

pygame.image.save() of gl Surfaces is still a problem on windows, causing
segfaults.

I commited a test called image__save_gl_surface_test.py 

cheers.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of René Dudfield
Sent: Monday, June 02, 2008 12:35 PM
To: pygame-users@seul.org
Subject: Re: BUG: pygame.image.save(screen) with pyopengl 3.x Re: [pygame]
PyOpenGL Screenshots

hi,

I fixed this on the weekend.  I stopped using pyopengl to get
glReadPixels (since pyopengl 3.x broke the glReadPixels API), and
instead loaded the gl functions dynamically with C.

Committed revision 1261.

You can get auto-built binaries for windows/mac osx here if needed:
http://thorbrian.com/pygame/builds.php

cheers,



On Wed, May 7, 2008 at 2:47 PM, René Dudfield <[EMAIL PROTECTED]> wrote:
> Added a bug to the subject.
>
> cu,
>
> On Wed, May 7, 2008 at 2:44 PM, René Dudfield <[EMAIL PROTECTED]> wrote:
>> looks like pyopengl 3.x returns a numpy array now instead of a string
>>  by default... which breaks pygame.image.save on gl with pyopengl 3.x.
>>
>>  Here's a work around screenshot function for gl.
>>
>>
>>  def save_screen(screen, filename):
>>
>> def readScreen(x, y, width, height):
>> """ Read in the screen information in the area specified """
>> glFinish()
>> glPixelStorei(GL_PACK_ALIGNMENT, 4)
>> glPixelStorei(GL_PACK_ROW_LENGTH, 0)
>> glPixelStorei(GL_PACK_SKIP_ROWS, 0)
>> glPixelStorei(GL_PACK_SKIP_PIXELS, 0)
>>
>> data = glReadPixels(x, y, width, height, GL_RGB,
GL_UNSIGNED_BYTE)
>> if hasattr(data, "tostring"):
>> data = data.tostring()
>>
>> return data
>> def saveImageData(width, height, data, filename):
>> """ Save image data """
>> surface = pygame.image.fromstring(data, (width, height), 'RGB',
1)
>> pygame.image.save(surface, filename)
>>
>> data = readScreen(0,0, screen.get_width(), screen.get_height())
>> saveImageData(screen.get_width(), screen.get_height(), data,
filename)
>>
>>
>>
>>
>>
>>  On Wed, May 7, 2008 at 2:27 PM, René Dudfield <[EMAIL PROTECTED]> wrote:
>>  > hi,
>>  >
>>  >  glReadPixels, make a surface, then use pygame.image.save()
>>  >
>>  >  Then use ffmpeg, or vlc etc to make a movie out of still frames.
>>  >
>>  >  cheers,
>>  >
>>
>

Re: BUG: pygame.image.save(screen) with pyopengl 3.x Re: [pygame] PyOpenGL Screenshots

[René Dudfield]

hi,

I fixed this on the weekend.  I stopped using pyopengl to get
glReadPixels (since pyopengl 3.x broke the glReadPixels API), and
instead loaded the gl functions dynamically with C.

Committed revision 1261.

You can get auto-built binaries for windows/mac osx here if needed:
http://thorbrian.com/pygame/builds.php

cheers,



On Wed, May 7, 2008 at 2:47 PM, René Dudfield <[EMAIL PROTECTED]> wrote:
> Added a bug to the subject.
>
> cu,
>
> On Wed, May 7, 2008 at 2:44 PM, René Dudfield <[EMAIL PROTECTED]> wrote:
>> looks like pyopengl 3.x returns a numpy array now instead of a string
>>  by default... which breaks pygame.image.save on gl with pyopengl 3.x.
>>
>>  Here's a work around screenshot function for gl.
>>
>>
>>  def save_screen(screen, filename):
>>
>> def readScreen(x, y, width, height):
>> """ Read in the screen information in the area specified """
>> glFinish()
>> glPixelStorei(GL_PACK_ALIGNMENT, 4)
>> glPixelStorei(GL_PACK_ROW_LENGTH, 0)
>> glPixelStorei(GL_PACK_SKIP_ROWS, 0)
>> glPixelStorei(GL_PACK_SKIP_PIXELS, 0)
>>
>> data = glReadPixels(x, y, width, height, GL_RGB, GL_UNSIGNED_BYTE)
>> if hasattr(data, "tostring"):
>> data = data.tostring()
>>
>> return data
>> def saveImageData(width, height, data, filename):
>> """ Save image data """
>> surface = pygame.image.fromstring(data, (width, height), 'RGB', 1)
>> pygame.image.save(surface, filename)
>>
>> data = readScreen(0,0, screen.get_width(), screen.get_height())
>> saveImageData(screen.get_width(), screen.get_height(), data, filename)
>>
>>
>>
>>
>>
>>  On Wed, May 7, 2008 at 2:27 PM, René Dudfield <[EMAIL PROTECTED]> wrote:
>>  > hi,
>>  >
>>  >  glReadPixels, make a surface, then use pygame.image.save()
>>  >
>>  >  Then use ffmpeg, or vlc etc to make a movie out of still frames.
>>  >
>>  >  cheers,
>>  >
>>
>

Re: [pygame] PyOpenGL Screenshots

[Astan Chee]

Hmm, thanks, I thought it was a simple solution.
I guess I'd rather cheat and do it as a progress-window kinda thing.
Thanks again for the info.
Astan

René Dudfield wrote:

hi,

You could do this with mesa 3d.  I don't think you can do it without
an x server.

You can also draw offscreen with a software surface by using the dummy
video driver - but that won't work for opengl.

cu,


On Tue, May 13, 2008 at 4:24 PM, Astan Chee <[EMAIL PROTECTED]> wrote:
  

Hi,
 I was wondering if the latest solution to render pyopengl from pygame
(Alistair Buxton's script) includes off-screen rendering.
 I want to render something and save it as a sequence of images, but I dont
want to display it anywhere. Is there a way to 'hide' this window?
 Thanks
 Astan

 --
 "Formulations of number theory: Complete, Consistent, Non-trivial. Choose
two."


 Animal Logic
 http://www.animallogic.com

 Please think of the environment before printing this email.

 This email and any attachments may be confidential and/or privileged. If
you are not the intended recipient of this email, you must not disclose or
use the information contained in it. Please notify the sender immediately
and delete this document if you have received it in error. We do not
guarantee this email is error or virus free.







  


--
"Formulations of number theory: Complete, Consistent, Non-trivial. Choose two."



Animal Logic
http://www.animallogic.com

Please think of the environment before printing this email.

This email and any attachments may be confidential and/or privileged. If you 
are not the intended recipient of this email, you must not disclose or use the 
information contained in it. Please notify the sender immediately and delete 
this document if you have received it in error. We do not guarantee this email 
is error or virus free.

Re: [pygame] PyOpenGL Screenshots

[René Dudfield]

hi,

You could do this with mesa 3d.  I don't think you can do it without
an x server.

You can also draw offscreen with a software surface by using the dummy
video driver - but that won't work for opengl.

cu,


On Tue, May 13, 2008 at 4:24 PM, Astan Chee <[EMAIL PROTECTED]> wrote:
> Hi,
>  I was wondering if the latest solution to render pyopengl from pygame
> (Alistair Buxton's script) includes off-screen rendering.
>  I want to render something and save it as a sequence of images, but I dont
> want to display it anywhere. Is there a way to 'hide' this window?
>  Thanks
>  Astan
>
>  --
>  "Formulations of number theory: Complete, Consistent, Non-trivial. Choose
> two."
>
>
>  Animal Logic
>  http://www.animallogic.com
>
>  Please think of the environment before printing this email.
>
>  This email and any attachments may be confidential and/or privileged. If
> you are not the intended recipient of this email, you must not disclose or
> use the information contained in it. Please notify the sender immediately
> and delete this document if you have received it in error. We do not
> guarantee this email is error or virus free.
>
>
>
>

Re: [pygame] PyOpenGL Screenshots

[Astan Chee]

Hi,
I was wondering if the latest solution to render pyopengl from pygame 
(Alistair Buxton's script) includes off-screen rendering.
I want to render something and save it as a sequence of images, but I 
dont want to display it anywhere. Is there a way to 'hide' this window?

Thanks
Astan

--
"Formulations of number theory: Complete, Consistent, Non-trivial. Choose two."


Animal Logic
http://www.animallogic.com

Please think of the environment before printing this email.

This email and any attachments may be confidential and/or privileged. If you 
are not the intended recipient of this email, you must not disclose or use the 
information contained in it. Please notify the sender immediately and delete 
this document if you have received it in error. We do not guarantee this email 
is error or virus free.

Re: [pygame] PyOpenGL Screenshots

[Alistair Buxton]

Here it is. I didn't spend any time making this code nice, but you can
just rip out the parts you need.

2008/5/8 Alistair Buxton <[EMAIL PROTECTED]>:
> I have a full example of doing exactly this task using python to
>  render to a series of png images (which you can load into something
>  like adobe premier), or a raw RV24 file (which you can transcode under
>  linux using... transcode). Will post it as soon as I've dug it out and
>  tested it still works. Includes examples of using transcode too.
>
>  2008/5/8 Ian Mallett <[EMAIL PROTECTED]>:
>
>
> > I figured out a way to do it in my program--Animation Shop Pro.  It would
>  > still be cool to have examples of how to do this without Animation Shop.  I
>  > was thinking ffmpeg or pil for doing so.  I looked around, but couldn't 
> find
>  > anything.
>  >  Thanks everyone,
>  > Ian
>  >
>
>
>
>  --
>  Alistair Buxton
>  [EMAIL PROTECTED]
>



-- 
Alistair Buxton
[EMAIL PROTECTED]
#!/usr/bin/env python

# Python OpenGL -> Video file
# (c) 2008 Alistair Buxton <[EMAIL PROTECTED]>
# Handy for doing procedural animations for compositing with other 
# videos in 

import os, random, math

from OpenGL.GL import *
from OpenGL.GLU import *
import pygame, pygame.image, pygame.key
from pygame.locals import *
from PIL import Image

##

# render settings

# 1 = best
QUALITY = 16

# whether to actually write output files or just preview
render_on = True

# If you don't want to write separate png files, you can just dump the output 
# from glReadPixels() into one huge file and encode it with transcode:

# transcode --use_rgb -i whatever.rv24 -x raw=RGB,null -y xvid4 -o output.xvid.avi -k -z  -f 25
# (for xvid)

# But beware that whatever.rv24 will be HUGE as it is uncompressed (not even RLE). 
# the size will be width*height*numframes*3 bytes, that's 31mb/sec for standard PAL video.

# Also worth mentioning: RV24 export is RGB, but png export is RGBA - thus if you use
# RV24 method, you will loose the alpha channel of your video.

# render type
# if true, write one big RV24 raw video file
# if false, write a png sequence
render_rv24 = False

if render_on:
# size of final render
w = 720
h = 576
else:
# size for preview
w = 720
h = 576

# how many frames to render before exiting
max_frames = 25

# framerate of rendered video
fps = 25.0

if render_rv24:
framefile = file("whatever.rv24", "wb")

##

# the snowflake animation stuff

flakes = []

class SnowFlake(object):
def __init__(self):
self.x = random.randrange(0,720)
self.y = random.randrange(0,576)

self.z = 3 + (random.randrange(3,20) / random.randrange(3,25))

self.dy = random.randrange(1,10)
self.drift = random.randrange(1,100)/1000.0 
self.rad = random.randrange(1,100)/100.0

def draw(self):
glColor4f(1.0,1.0,1.0,1.0)
if self.z < 0:
return
glBegin(GL_POLYGON)
r = math.floor(self.z * 4)
for i in range(int(r)):
glVertex2f( self.x+(self.z*math.sin(2*math.pi*(i/r))), self.y+(self.z*math.cos(2*math.pi*(i/r))) )
glVertex2f( self.x, self.y+self.z )
glEnd()


def update(self, ftime):

self.rad += ((ftime*0.5)+self.drift)
self.x += math.sin(self.rad)

self.y -= 0.7*ftime*(40.0+self.dy)*self.z;

if (self.y < -10):
self.y = 586

if (self.x < -10):
self.x = 730

if (self.x > 730):
self.x = -10

# standard opengl stuff init/draw/update/resize

def resize((width, height)):
if height==0:
height=1.0
glViewport(0, 0, width, height)
glMatrixMode(GL_PROJECTION)
glLoadIdentity()
gluOrtho2D(0, 720, 0, 576)
#gluOrtho2D(-(width/(2*height)), width/(2*height), 0, 1)
glMatrixMode(GL_MODELVIEW)
glLoadIdentity()

def init():
glShadeModel(GL_SMOOTH)
glClearColor(0.3,0.5,0.7,0.0)
glClearDepth(1.0)
glClear( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT )
glHint(GL_PERSPECTIVE_CORRECTION_HINT, GL_NICEST)
glDisable(GL_DEPTH_TEST)

for i in range(100):
flakes.append(SnowFlake())

def update(ftime):
for f in flakes:
f.update(ftime)

def draw():
glClear( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT )

glMatrixMode(GL_MODELVIEW)
glLoadIdentity()
glDisable(GL_TEXTURE_2D)

for f in flakes:
f.draw()

###

# write a png file from GL framebuffer data

def png_file_write(name, number, data):
im = Image.frombuffer("RGBA", (720,576), data, "raw", "RGBA", 0, 0)
fnumber = "%05d" % number
im.save(name + fnumber + ".png")

Re: [pygame] PyOpenGL Screenshots

[Alistair Buxton]

I have a full example of doing exactly this task using python to
render to a series of png images (which you can load into something
like adobe premier), or a raw RV24 file (which you can transcode under
linux using... transcode). Will post it as soon as I've dug it out and
tested it still works. Includes examples of using transcode too.

2008/5/8 Ian Mallett <[EMAIL PROTECTED]>:
> I figured out a way to do it in my program--Animation Shop Pro.  It would
> still be cool to have examples of how to do this without Animation Shop.  I
> was thinking ffmpeg or pil for doing so.  I looked around, but couldn't find
> anything.
>  Thanks everyone,
> Ian
>



-- 
Alistair Buxton
[EMAIL PROTECTED]

Re: [pygame] PyOpenGL Screenshots

[Ian Mallett]

I figured out a way to do it in my program--Animation Shop Pro.  It would
still be cool to have examples of how to do this without Animation Shop.  I
was thinking ffmpeg or pil for doing so.  I looked around, but couldn't find
anything.
Thanks everyone,
Ian

Re: [pygame] PyOpenGL Screenshots

[René Dudfield]

hi,

as I mentioned in the other emails you can make gif images with at
least image magik, ffmpeg, and gimp.

cheers,



On Thu, May 8, 2008 at 6:28 AM, Ian Mallett <[EMAIL PROTECTED]> wrote:
> AWESOME!
> That screenshot taker works!  Thanks so much!
>
> Now, I could copy each frame individually to the animation maker, but I
> would prefer it automated.  Is there a way to make the screenshots be
> clumped together into a .gif file via a program?  (Incidentally, I agree
> about the implausibility of using a .gif file for a movie.  The gif animator
> I'm working with does exports).
>
> Ian
>

Re: [pygame] PyOpenGL Screenshots

[Ian Mallett]

AWESOME!
That screenshot taker works!  Thanks so much!

Now, I could copy each frame individually to the animation maker, but I
would prefer it automated.  Is there a way to make the screenshots be
clumped together into a .gif file via a program?  (Incidentally, I agree
about the implausibility of using a .gif file for a movie.  The gif animator
I'm working with does exports).

Ian

Re: [pygame] PyOpenGL Screenshots

[René Dudfield]

hi again,

note, you can convert a series of images with image magik, or the gimp
most easily I think...

convert -delay 20 -loop 0 bla*.tga animated.gif

Or opening them as gimp layers, then saving to an animated gif.

cu,



On Wed, May 7, 2008 at 2:44 PM, René Dudfield <[EMAIL PROTECTED]> wrote:
> looks like pyopengl 3.x returns a numpy array now instead of a string
>  by default... which breaks pygame.image.save on gl with pyopengl 3.x.
>
>  Here's a work around screenshot function for gl.
>
>
>  def save_screen(screen, filename):
>
> def readScreen(x, y, width, height):
> """ Read in the screen information in the area specified """
> glFinish()
> glPixelStorei(GL_PACK_ALIGNMENT, 4)
> glPixelStorei(GL_PACK_ROW_LENGTH, 0)
> glPixelStorei(GL_PACK_SKIP_ROWS, 0)
> glPixelStorei(GL_PACK_SKIP_PIXELS, 0)
>
> data = glReadPixels(x, y, width, height, GL_RGB, GL_UNSIGNED_BYTE)
> if hasattr(data, "tostring"):
> data = data.tostring()
>
> return data
> def saveImageData(width, height, data, filename):
> """ Save image data """
> surface = pygame.image.fromstring(data, (width, height), 'RGB', 1)
> pygame.image.save(surface, filename)
>
> data = readScreen(0,0, screen.get_width(), screen.get_height())
> saveImageData(screen.get_width(), screen.get_height(), data, filename)
>
>
>
>
>
>  On Wed, May 7, 2008 at 2:27 PM, René Dudfield <[EMAIL PROTECTED]> wrote:
>  > hi,
>  >
>  >  glReadPixels, make a surface, then use pygame.image.save()
>  >
>  >  Then use ffmpeg, or vlc etc to make a movie out of still frames.
>  >
>  >  cheers,
>  >
>

BUG: pygame.image.save(screen) with pyopengl 3.x Re: [pygame] PyOpenGL Screenshots

[René Dudfield]

Added a bug to the subject.

cu,

On Wed, May 7, 2008 at 2:44 PM, René Dudfield <[EMAIL PROTECTED]> wrote:
> looks like pyopengl 3.x returns a numpy array now instead of a string
>  by default... which breaks pygame.image.save on gl with pyopengl 3.x.
>
>  Here's a work around screenshot function for gl.
>
>
>  def save_screen(screen, filename):
>
> def readScreen(x, y, width, height):
> """ Read in the screen information in the area specified """
> glFinish()
> glPixelStorei(GL_PACK_ALIGNMENT, 4)
> glPixelStorei(GL_PACK_ROW_LENGTH, 0)
> glPixelStorei(GL_PACK_SKIP_ROWS, 0)
> glPixelStorei(GL_PACK_SKIP_PIXELS, 0)
>
> data = glReadPixels(x, y, width, height, GL_RGB, GL_UNSIGNED_BYTE)
> if hasattr(data, "tostring"):
> data = data.tostring()
>
> return data
> def saveImageData(width, height, data, filename):
> """ Save image data """
> surface = pygame.image.fromstring(data, (width, height), 'RGB', 1)
> pygame.image.save(surface, filename)
>
> data = readScreen(0,0, screen.get_width(), screen.get_height())
> saveImageData(screen.get_width(), screen.get_height(), data, filename)
>
>
>
>
>
>  On Wed, May 7, 2008 at 2:27 PM, René Dudfield <[EMAIL PROTECTED]> wrote:
>  > hi,
>  >
>  >  glReadPixels, make a surface, then use pygame.image.save()
>  >
>  >  Then use ffmpeg, or vlc etc to make a movie out of still frames.
>  >
>  >  cheers,
>  >
>

Re: [pygame] PyOpenGL Screenshots

[René Dudfield]

looks like pyopengl 3.x returns a numpy array now instead of a string
by default... which breaks pygame.image.save on gl with pyopengl 3.x.

Here's a work around screenshot function for gl.


def save_screen(screen, filename):

def readScreen(x, y, width, height):
""" Read in the screen information in the area specified """
glFinish()
glPixelStorei(GL_PACK_ALIGNMENT, 4)
glPixelStorei(GL_PACK_ROW_LENGTH, 0)
glPixelStorei(GL_PACK_SKIP_ROWS, 0)
glPixelStorei(GL_PACK_SKIP_PIXELS, 0)

data = glReadPixels(x, y, width, height, GL_RGB, GL_UNSIGNED_BYTE)
if hasattr(data, "tostring"):
data = data.tostring()

return data
def saveImageData(width, height, data, filename):
""" Save image data """
surface = pygame.image.fromstring(data, (width, height), 'RGB', 1)
pygame.image.save(surface, filename)

data = readScreen(0,0, screen.get_width(), screen.get_height())
saveImageData(screen.get_width(), screen.get_height(), data, filename)



On Wed, May 7, 2008 at 2:27 PM, René Dudfield <[EMAIL PROTECTED]> wrote:
> hi,
>
>  glReadPixels, make a surface, then use pygame.image.save()
>
>  Then use ffmpeg, or vlc etc to make a movie out of still frames.
>
>  cheers,
>

Re: [pygame] PyOpenGL Screenshots

[René Dudfield]

hi,

glReadPixels, make a surface, then use pygame.image.save()

Then use ffmpeg, or vlc etc to make a movie out of still frames.

cheers,

Re: [pygame] PyOpenGL Screenshots

[Noah Kantrowitz]

Ian Mallett wrote:

Hello,

-I have a project which must be finished by Thursday.  The project is a
movie, for a presentation, and my solution has been to make a program to
render each frame in OpenGL.  I can now render each frame individually, but
now I face the challenge of turning these renders into a movie.  (Movie
capture programs are no good--free ones have drawbacks, and in any case the
renders are slow to update (think 1 fps tops).).

-I decided to do it as a .gif animation, as I have several programs for
making movies from a series of images


Using an animated gif would be dumb. 
http://www.yourmachines.org/tutorials/mgpy.html shows how to use ffmpeg 
to create video files from images.


--Noah




signature.asc
Description: OpenPGP digital signature

[pygame] PyOpenGL Screenshots

[Ian Mallett]

Hello,

-I have a project which must be finished by Thursday.  The project is a
movie, for a presentation, and my solution has been to make a program to
render each frame in OpenGL.  I can now render each frame individually, but
now I face the challenge of turning these renders into a movie.  (Movie
capture programs are no good--free ones have drawbacks, and in any case the
renders are slow to update (think 1 fps tops).).

-I decided to do it as a .gif animation, as I have several programs for
making movies from a series of images.
-The obvious thing to do is to copy each frame into the programs, building
my movie that way.
-However, there are exactly 1200 frames in the movie at a minimal
quality--that's (150 frames/scene)*(8 scenes).  I want this framerate to be
higher.  This pushes the frame count higher, naturally.  The stupendous
number of necessary frames is impractical to copy via ALT-PRINTSCREEN--(my
current method).

-The ideal solution is to directly export the frames into a .gif animation.

-My second best option would be to save each render in a separate file.  I
could then drag and drop these renders chunks at a time into my program to
make the animation.
-I face several challenges here.  The most important is that I have no idea
how to save screenshots from PyOpenGL.  Last I heard, people sort-of had
ideas about how to do it.  pygame.image.save() *does not work* on OpenGL
surfaces.  Any concrete working examples here?

-Summary: From an PyOpenGL program, what is a working method of saving
renders to either many files or directly to a .gif animation?

Thanks,
Ian

adding note to glTexImage2D exception for non-power of 2 textures. Re: [pygame] compiled exe in pygame/pyopengl working locally but not elsewhere

[René Dudfield]

hi,

It would almost even be worth it adding a note about this FAQ into the
exception for glTexImage2D - or add a warning to a log somewhere
perhaps?

cu,

[snip]
> > > It gives me the following error:
> > > Unhandled exception in thread started by
> > > Traceback (most recent call last):
> > >  File "wxSolOutWindow.py", line 637, in Run
> > >  File "wxSolOutWindow.py", line 152, in Inited
> > >  File "wxSolOutWindow.py", line 241, in ObjMain
> > >  File "c:\Documents and
> Settings\$USER\Desktop\2\dist\PyOpenGL-3.0.0b1-py2.5.egg\OpenGL\wrapper.py",
> line 1624 in __call__
> > >  File "c:\Documents and
> Settings\$USER\Desktop\2\dist\PyOpenGL-3.0.0b1-py2.5.egg\OpenGL\wrapper.py",
> line 924 in wrapperCall
> > > OpenGL.error.GLError: GLError(
> > >  err = 1281,
> > >  description = 'invalid value',
> > >  baseOperation = glTexImage2D,
> > >  pyArgs = [
> > > GL_TEXTURE_2D,
> > > 0,
> > > GL_RGBA,
> > > 750,
> > > 750,
> > > 0,
> > > GL_RGBA,
> > > GL_UNSIGNED_BYTE,
> > > '\x00\x00\x00\xff\x00\x00\x00\xff\x00...
> > >  ],
> > >  cArgs = [
> > > GL_TEXTURE_2D,
> > > 0,
> > > GL_RGBA,
> > > 750,
> > > 750,
> > > 0,
> > > GL_RGBA,
> > > GL_UNSIGNED_BYTE,
> > > '\x00\x00\x00\xff\x00\x00\x00\xff\x00...
> > >  ],
> > >  cArguments = (
> > > GL_TEXTURE_2D,
> > > 0,
> > > GL_RGBA,
> > > 750,
> > > 750,
> > > 0,
> > > GL_RGBA,
> > > GL_UNSIGNED_BYTE,
> > > c_void_p(146210868),
> > >  )
> > > )
> > >

Re: [pygame] compiled exe in pygame/pyopengl working locally but not elsewhere

[Astan Chee]

Yes, it did work. I tried resizing the image to 512 and it worked. 
Thanks again for all your help


Astan Chee wrote:
I'll try that now. So height and width of 256 or 512 should be 
alright,right?
Also upon further reflection, it seems that in wxglcanvas, it doesnt 
actually error, but the textures arent loaded and a blank black 
texture is used anyway. I had a hard time seeing this because the 
texture image itself is almost black.

Thanks again for your help.
Cheers
Astan

Brian Fisher wrote:
the error you originally sent shows 750 as the width and height 
arguments to glTexImage2D on the exception- 750 is not a power of 2. 
Hence you were trying to use non-power of 2 textures. To make it use 
of power-of-2 you'd have to either put that 750 wide & high image in 
some bigger texture (i.e. scale it up or black box it) or split it 
across multiple textures.


As far as what is different between pygame display and wxglcanvas, I 
don't know - is it still the same size for the window for both? Are 
there possibly some calculations that are different with your 
different code related to texture size? Also the problem could be 
something else other than texture size (maybe something with the 
texture format not being supported, or maybe the driver didn't like 
some of the texture contents?) that would be related to how the GL 
context was created...


On Mon, May 5, 2008 at 9:52 PM, Astan Chee <[EMAIL PROTECTED] 
> wrote:


Thanks for the reply.
Here is where it gets wierd.
I have modified the script to not use a pygame display. Instead
it uses a wxglcanvas on a wx frame/notebook. Compiled using the
same parameters but still use pygame to load the image.
That one worked fine compiled or not in any machine.
So im willing to discount anything from py2exe. Since it is a
pygame display, i was wondering what is different about it? or
how do i check if im using a non power-of-2 texture or convert my
textures so that it can work?
Thanks again for your help.
Astan


Brian Fisher wrote:

I'm 99.9% sure that error has nothing to do with Py2Exe at all.

It seems the system that has the problem must not like something
about the way glTexImage2D was called in that case - GL errors
like you see there come from the drivers. I would guess that it
is that you are using a non power-of-2 texture size (a bad thing
to do if you didn't explicitly check for support and you care at
all about compatibility)

On Mon, May 5, 2008 at 8:31 PM, Astan Chee <[EMAIL PROTECTED]
> wrote:

Hi,
I have a python script that uses wx, pygame and pyopengl.
I've combined wx and pygame similar to
http://wiki.wxpython.org/IntegratingPyGame (in windows) and
the pygame has a separate thread. The pygame part of it uses
pyopengl for a display window and to load images. When I
create a .exe from this script, the executable works fine on
the pc that i compiled it on (my one), but it wont run
anywhere else; even ones that are almost identical build to
mine (it doesnt have python, pygame or pyopengl installed).
It gives me a wierd error that I dont know what it means.
Does anyone know what might cause it? or how do I debug
these problems? Why would it work on my pc and not anywhere
else?
Thanks for any help

It gives me the following error:
Unhandled exception in thread started by
Traceback (most recent call last):
 File "wxSolOutWindow.py", line 637, in Run
 File "wxSolOutWindow.py", line 152, in Inited
 File "wxSolOutWindow.py", line 241, in ObjMain
 File "c:\Documents and

Settings\$USER\Desktop\2\dist\PyOpenGL-3.0.0b1-py2.5.egg\OpenGL\wrapper.py",
line 1624 in __call__
 File "c:\Documents and

Settings\$USER\Desktop\2\dist\PyOpenGL-3.0.0b1-py2.5.egg\OpenGL\wrapper.py",
line 924 in wrapperCall
OpenGL.error.GLError: GLError(
 err = 1281,
 description = 'invalid value',
 baseOperation = glTexImage2D,
 pyArgs = [
GL_TEXTURE_2D,
0,
GL_RGBA,
750,
750,
0,
GL_RGBA,
GL_UNSIGNED_BYTE,
'\x00\x00\x00\xff\x00\x00\x00\xff\x00...
 ],
 cArgs = [
GL_TEXTURE_2D,
0,
GL_RGBA,
750,
750,
0,
GL_RGBA,
GL_UNSIGNED_BYTE,
'\x00\x00\x00\xff\x00\x00\x00\xff\x00...
 ],
 cArguments = (
GL_TEXTURE_2D,
0,
GL_RGBA,
750,
750,
0,
GL_RGBA,
GL_UNSIGNED_BYTE,
c_void_p(146210868),
 )
)

-- 
"Formulations of number theory: Complet

Re: [pygame] compiled exe in pygame/pyopengl working locally but not elsewhere

[Astan Chee]

I'll try that now. So height and width of 256 or 512 should be 
alright,right?
Also upon further reflection, it seems that in wxglcanvas, it doesnt 
actually error, but the textures arent loaded and a blank black texture 
is used anyway. I had a hard time seeing this because the texture image 
itself is almost black.

Thanks again for your help.
Cheers
Astan

Brian Fisher wrote:
the error you originally sent shows 750 as the width and height 
arguments to glTexImage2D on the exception- 750 is not a power of 2. 
Hence you were trying to use non-power of 2 textures. To make it use 
of power-of-2 you'd have to either put that 750 wide & high image in 
some bigger texture (i.e. scale it up or black box it) or split it 
across multiple textures.


As far as what is different between pygame display and wxglcanvas, I 
don't know - is it still the same size for the window for both? Are 
there possibly some calculations that are different with your 
different code related to texture size? Also the problem could be 
something else other than texture size (maybe something with the 
texture format not being supported, or maybe the driver didn't like 
some of the texture contents?) that would be related to how the GL 
context was created...


On Mon, May 5, 2008 at 9:52 PM, Astan Chee <[EMAIL PROTECTED] 
> wrote:


Thanks for the reply.
Here is where it gets wierd.
I have modified the script to not use a pygame display. Instead it
uses a wxglcanvas on a wx frame/notebook. Compiled using the same
parameters but still use pygame to load the image.
That one worked fine compiled or not in any machine.
So im willing to discount anything from py2exe. Since it is a
pygame display, i was wondering what is different about it? or how
do i check if im using a non power-of-2 texture or convert my
textures so that it can work?
Thanks again for your help.
Astan


Brian Fisher wrote:

I'm 99.9% sure that error has nothing to do with Py2Exe at all.

It seems the system that has the problem must not like something
about the way glTexImage2D was called in that case - GL errors
like you see there come from the drivers. I would guess that it
is that you are using a non power-of-2 texture size (a bad thing
to do if you didn't explicitly check for support and you care at
all about compatibility)

On Mon, May 5, 2008 at 8:31 PM, Astan Chee <[EMAIL PROTECTED]
> wrote:

Hi,
I have a python script that uses wx, pygame and pyopengl.
I've combined wx and pygame similar to
http://wiki.wxpython.org/IntegratingPyGame (in windows) and
the pygame has a separate thread. The pygame part of it uses
pyopengl for a display window and to load images. When I
create a .exe from this script, the executable works fine on
the pc that i compiled it on (my one), but it wont run
anywhere else; even ones that are almost identical build to
mine (it doesnt have python, pygame or pyopengl installed).
It gives me a wierd error that I dont know what it means.
Does anyone know what might cause it? or how do I debug these
problems? Why would it work on my pc and not anywhere else?
Thanks for any help

It gives me the following error:
Unhandled exception in thread started by
Traceback (most recent call last):
 File "wxSolOutWindow.py", line 637, in Run
 File "wxSolOutWindow.py", line 152, in Inited
 File "wxSolOutWindow.py", line 241, in ObjMain
 File "c:\Documents and

Settings\$USER\Desktop\2\dist\PyOpenGL-3.0.0b1-py2.5.egg\OpenGL\wrapper.py",
line 1624 in __call__
 File "c:\Documents and

Settings\$USER\Desktop\2\dist\PyOpenGL-3.0.0b1-py2.5.egg\OpenGL\wrapper.py",
line 924 in wrapperCall
OpenGL.error.GLError: GLError(
 err = 1281,
 description = 'invalid value',
 baseOperation = glTexImage2D,
 pyArgs = [
GL_TEXTURE_2D,
0,
GL_RGBA,
750,
750,
0,
GL_RGBA,
GL_UNSIGNED_BYTE,
'\x00\x00\x00\xff\x00\x00\x00\xff\x00...
 ],
 cArgs = [
GL_TEXTURE_2D,
0,
GL_RGBA,
750,
750,
0,
GL_RGBA,
GL_UNSIGNED_BYTE,
'\x00\x00\x00\xff\x00\x00\x00\xff\x00...
 ],
 cArguments = (
GL_TEXTURE_2D,
0,
GL_RGBA,
750,
750,
0,
GL_RGBA,
GL_UNSIGNED_BYTE,
c_void_p(146210868),
 )
)

-- 
"Formulations of number theory: Complete, Consistent,

Non-trivial. Choose two."


Animal Logic
http://www.animallogic.com

Please thi

Re: [pygame] compiled exe in pygame/pyopengl working locally but not elsewhere

[Brian Fisher]

the error you originally sent shows 750 as the width and height arguments to
glTexImage2D on the exception- 750 is not a power of 2. Hence you were
trying to use non-power of 2 textures. To make it use of power-of-2 you'd
have to either put that 750 wide & high image in some bigger texture (i.e.
scale it up or black box it) or split it across multiple textures.

As far as what is different between pygame display and wxglcanvas, I don't
know - is it still the same size for the window for both? Are there possibly
some calculations that are different with your different code related to
texture size? Also the problem could be something else other than texture
size (maybe something with the texture format not being supported, or maybe
the driver didn't like some of the texture contents?) that would be related
to how the GL context was created...

On Mon, May 5, 2008 at 9:52 PM, Astan Chee <[EMAIL PROTECTED]> wrote:

>  Thanks for the reply.
> Here is where it gets wierd.
> I have modified the script to not use a pygame display. Instead it uses a
> wxglcanvas on a wx frame/notebook. Compiled using the same parameters but
> still use pygame to load the image.
> That one worked fine compiled or not in any machine.
> So im willing to discount anything from py2exe. Since it is a pygame
> display, i was wondering what is different about it? or how do i check if im
> using a non power-of-2 texture or convert my textures so that it can work?
> Thanks again for your help.
> Astan
>
>
> Brian Fisher wrote:
>
> I'm 99.9% sure that error has nothing to do with Py2Exe at all.
>
> It seems the system that has the problem must not like something about the
> way glTexImage2D was called in that case - GL errors like you see there come
> from the drivers. I would guess that it is that you are using a non
> power-of-2 texture size (a bad thing to do if you didn't explicitly check
> for support and you care at all about compatibility)
>
> On Mon, May 5, 2008 at 8:31 PM, Astan Chee <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> > I have a python script that uses wx, pygame and pyopengl. I've combined
> > wx and pygame similar to http://wiki.wxpython.org/IntegratingPyGame (in
> > windows) and the pygame has a separate thread. The pygame part of it uses
> > pyopengl for a display window and to load images. When I create a .exe from
> > this script, the executable works fine on the pc that i compiled it on (my
> > one), but it wont run anywhere else; even ones that are almost identical
> > build to mine (it doesnt have python, pygame or pyopengl installed). It
> > gives me a wierd error that I dont know what it means. Does anyone know what
> > might cause it? or how do I debug these problems? Why would it work on my pc
> > and not anywhere else?
> > Thanks for any help
> >
> > It gives me the following error:
> > Unhandled exception in thread started by
> > Traceback (most recent call last):
> >  File "wxSolOutWindow.py", line 637, in Run
> >  File "wxSolOutWindow.py", line 152, in Inited
> >  File "wxSolOutWindow.py", line 241, in ObjMain
> >  File "c:\Documents and
> > Settings\$USER\Desktop\2\dist\PyOpenGL-3.0.0b1-py2.5.egg\OpenGL\wrapper.py",
> > line 1624 in __call__
> >  File "c:\Documents and
> > Settings\$USER\Desktop\2\dist\PyOpenGL-3.0.0b1-py2.5.egg\OpenGL\wrapper.py",
> > line 924 in wrapperCall
> > OpenGL.error.GLError: GLError(
> >  err = 1281,
> >  description = 'invalid value',
> >  baseOperation = glTexImage2D,
> >  pyArgs = [
> > GL_TEXTURE_2D,
> > 0,
> > GL_RGBA,
> > 750,
> > 750,
> > 0,
> > GL_RGBA,
> > GL_UNSIGNED_BYTE,
> > '\x00\x00\x00\xff\x00\x00\x00\xff\x00...
> >  ],
> >  cArgs = [
> > GL_TEXTURE_2D,
> > 0,
> > GL_RGBA,
> > 750,
> > 750,
> > 0,
> > GL_RGBA,
> > GL_UNSIGNED_BYTE,
> > '\x00\x00\x00\xff\x00\x00\x00\xff\x00...
> >  ],
> >  cArguments = (
> > GL_TEXTURE_2D,
> > 0,
> > GL_RGBA,
> > 750,
> > 750,
> > 0,
> > GL_RGBA,
> > GL_UNSIGNED_BYTE,
> > c_void_p(146210868),
> >  )
> > )
> >
> > --
> > "Formulations of number theory: Complete, Consistent, Non-trivial.
> > Choose two."
> >
> >
> > Animal Logic
> > http://www.animallogic.com
> >
> > Please think of the environment before printing this email.
> >
> > This email and any attachments may be confidential and/or privileged. If
> > you are not the intended recipient of this email, you must not disclose or
> > use the information contained in it. Please notify the sender immediately
> > and delete this document if you have received it in error. We do not
> > guarantee this email is error or virus free.
> >
> >
> >
> >
>
> --
> "Formulations of number theory: Complete, Consistent, Non-trivial. Choose 
> two."
>
>
>  
>
> Please think of the environment before printing this email.
>
> This email and any attachments may be confidential and/or privileged. If
> you are not the intended recipient of this email, you must not disclose or

Re: [pygame] compiled exe in pygame/pyopengl working locally but not elsewhere

[Astan Chee]

Thanks for the reply.
Here is where it gets wierd.
I have modified the script to not use a pygame display. Instead it uses 
a wxglcanvas on a wx frame/notebook. Compiled using the same parameters 
but still use pygame to load the image.

That one worked fine compiled or not in any machine.
So im willing to discount anything from py2exe. Since it is a pygame 
display, i was wondering what is different about it? or how do i check 
if im using a non power-of-2 texture or convert my textures so that it 
can work?

Thanks again for your help.
Astan

Brian Fisher wrote:

I'm 99.9% sure that error has nothing to do with Py2Exe at all.

It seems the system that has the problem must not like something about 
the way glTexImage2D was called in that case - GL errors like you see 
there come from the drivers. I would guess that it is that you are 
using a non power-of-2 texture size (a bad thing to do if you didn't 
explicitly check for support and you care at all about compatibility)


On Mon, May 5, 2008 at 8:31 PM, Astan Chee <[EMAIL PROTECTED] 
> wrote:


Hi,
I have a python script that uses wx, pygame and pyopengl. I've
combined wx and pygame similar to
http://wiki.wxpython.org/IntegratingPyGame (in windows) and the
pygame has a separate thread. The pygame part of it uses pyopengl
for a display window and to load images. When I create a .exe from
this script, the executable works fine on the pc that i compiled
it on (my one), but it wont run anywhere else; even ones that are
almost identical build to mine (it doesnt have python, pygame or
pyopengl installed). It gives me a wierd error that I dont know
what it means. Does anyone know what might cause it? or how do I
debug these problems? Why would it work on my pc and not anywhere
else?
Thanks for any help

It gives me the following error:
Unhandled exception in thread started by
Traceback (most recent call last):
 File "wxSolOutWindow.py", line 637, in Run
 File "wxSolOutWindow.py", line 152, in Inited
 File "wxSolOutWindow.py", line 241, in ObjMain
 File "c:\Documents and
Settings\$USER\Desktop\2\dist\PyOpenGL-3.0.0b1-py2.5.egg\OpenGL\wrapper.py",
line 1624 in __call__
 File "c:\Documents and
Settings\$USER\Desktop\2\dist\PyOpenGL-3.0.0b1-py2.5.egg\OpenGL\wrapper.py",
line 924 in wrapperCall
OpenGL.error.GLError: GLError(
 err = 1281,
 description = 'invalid value',
 baseOperation = glTexImage2D,
 pyArgs = [
GL_TEXTURE_2D,
0,
GL_RGBA,
750,
750,
0,
GL_RGBA,
GL_UNSIGNED_BYTE,
'\x00\x00\x00\xff\x00\x00\x00\xff\x00...
 ],
 cArgs = [
GL_TEXTURE_2D,
0,
GL_RGBA,
750,
750,
0,
GL_RGBA,
GL_UNSIGNED_BYTE,
'\x00\x00\x00\xff\x00\x00\x00\xff\x00...
 ],
 cArguments = (
GL_TEXTURE_2D,
0,
GL_RGBA,
750,
750,
0,
GL_RGBA,
GL_UNSIGNED_BYTE,
c_void_p(146210868),
 )
)

-- 
"Formulations of number theory: Complete, Consistent, Non-trivial.

Choose two."


Animal Logic
http://www.animallogic.com

Please think of the environment before printing this email.

This email and any attachments may be confidential and/or
privileged. If you are not the intended recipient of this email,
you must not disclose or use the information contained in it.
Please notify the sender immediately and delete this document if
you have received it in error. We do not guarantee this email is
error or virus free.






--
"Formulations of number theory: Complete, Consistent, Non-trivial. Choose two."



Animal Logic
http://www.animallogic.com

Please think of the environment before printing this email.

This email and any attachments may be confidential and/or privileged. If you 
are not the intended recipient of this email, you must not disclose or use the 
information contained in it. Please notify the sender immediately and delete 
this document if you have received it in error. We do not guarantee this email 
is error or virus free.

Re: [pygame] compiled exe in pygame/pyopengl working locally but not elsewhere

[Brian Fisher]

I'm 99.9% sure that error has nothing to do with Py2Exe at all.

It seems the system that has the problem must not like something about the
way glTexImage2D was called in that case - GL errors like you see there come
from the drivers. I would guess that it is that you are using a non
power-of-2 texture size (a bad thing to do if you didn't explicitly check
for support and you care at all about compatibility)

On Mon, May 5, 2008 at 8:31 PM, Astan Chee <[EMAIL PROTECTED]> wrote:

> Hi,
> I have a python script that uses wx, pygame and pyopengl. I've combined wx
> and pygame similar to http://wiki.wxpython.org/IntegratingPyGame (in
> windows) and the pygame has a separate thread. The pygame part of it uses
> pyopengl for a display window and to load images. When I create a .exe from
> this script, the executable works fine on the pc that i compiled it on (my
> one), but it wont run anywhere else; even ones that are almost identical
> build to mine (it doesnt have python, pygame or pyopengl installed). It
> gives me a wierd error that I dont know what it means. Does anyone know what
> might cause it? or how do I debug these problems? Why would it work on my pc
> and not anywhere else?
> Thanks for any help
>
> It gives me the following error:
> Unhandled exception in thread started by
> Traceback (most recent call last):
>  File "wxSolOutWindow.py", line 637, in Run
>  File "wxSolOutWindow.py", line 152, in Inited
>  File "wxSolOutWindow.py", line 241, in ObjMain
>  File "c:\Documents and
> Settings\$USER\Desktop\2\dist\PyOpenGL-3.0.0b1-py2.5.egg\OpenGL\wrapper.py",
> line 1624 in __call__
>  File "c:\Documents and
> Settings\$USER\Desktop\2\dist\PyOpenGL-3.0.0b1-py2.5.egg\OpenGL\wrapper.py",
> line 924 in wrapperCall
> OpenGL.error.GLError: GLError(
>  err = 1281,
>  description = 'invalid value',
>  baseOperation = glTexImage2D,
>  pyArgs = [
> GL_TEXTURE_2D,
> 0,
> GL_RGBA,
> 750,
> 750,
> 0,
> GL_RGBA,
> GL_UNSIGNED_BYTE,
> '\x00\x00\x00\xff\x00\x00\x00\xff\x00...
>  ],
>  cArgs = [
> GL_TEXTURE_2D,
> 0,
> GL_RGBA,
> 750,
> 750,
> 0,
> GL_RGBA,
> GL_UNSIGNED_BYTE,
> '\x00\x00\x00\xff\x00\x00\x00\xff\x00...
>  ],
>  cArguments = (
> GL_TEXTURE_2D,
> 0,
> GL_RGBA,
> 750,
> 750,
> 0,
> GL_RGBA,
> GL_UNSIGNED_BYTE,
> c_void_p(146210868),
>  )
> )
>
> --
> "Formulations of number theory: Complete, Consistent, Non-trivial. Choose
> two."
>
>
> Animal Logic
> http://www.animallogic.com
>
> Please think of the environment before printing this email.
>
> This email and any attachments may be confidential and/or privileged. If
> you are not the intended recipient of this email, you must not disclose or
> use the information contained in it. Please notify the sender immediately
> and delete this document if you have received it in error. We do not
> guarantee this email is error or virus free.
>
>
>
>

[pygame] compiled exe in pygame/pyopengl working locally but not elsewhere

[Astan Chee]

Hi,
I have a python script that uses wx, pygame and pyopengl. I've combined 
wx and pygame similar to http://wiki.wxpython.org/IntegratingPyGame (in 
windows) and the pygame has a separate thread. The pygame part of it 
uses pyopengl for a display window and to load images. When I create a 
.exe from this script, the executable works fine on the pc that i 
compiled it on (my one), but it wont run anywhere else; even ones that 
are almost identical build to mine (it doesnt have python, pygame or 
pyopengl installed). It gives me a wierd error that I dont know what it 
means. Does anyone know what might cause it? or how do I debug these 
problems? Why would it work on my pc and not anywhere else?

Thanks for any help

It gives me the following error:
Unhandled exception in thread started by
Traceback (most recent call last):
  File "wxSolOutWindow.py", line 637, in Run
  File "wxSolOutWindow.py", line 152, in Inited
  File "wxSolOutWindow.py", line 241, in ObjMain
  File "c:\Documents and 
Settings\$USER\Desktop\2\dist\PyOpenGL-3.0.0b1-py2.5.egg\OpenGL\wrapper.py", 
line 1624 in __call__
  File "c:\Documents and 
Settings\$USER\Desktop\2\dist\PyOpenGL-3.0.0b1-py2.5.egg\OpenGL\wrapper.py", 
line 924 in wrapperCall

OpenGL.error.GLError: GLError(
  err = 1281,
  description = 'invalid value',
  baseOperation = glTexImage2D,
  pyArgs = [
 GL_TEXTURE_2D,
 0,
 GL_RGBA,
 750,
 750,
 0,
 GL_RGBA,
 GL_UNSIGNED_BYTE,
 '\x00\x00\x00\xff\x00\x00\x00\xff\x00...
  ],
  cArgs = [
 GL_TEXTURE_2D,
 0,
 GL_RGBA,
 750,
 750,
 0,
 GL_RGBA,
 GL_UNSIGNED_BYTE,
 '\x00\x00\x00\xff\x00\x00\x00\xff\x00...
  ],
  cArguments = (
 GL_TEXTURE_2D,
 0,
 GL_RGBA,
 750,
 750,
 0,
 GL_RGBA,
 GL_UNSIGNED_BYTE,
 c_void_p(146210868),
  )
)

--
"Formulations of number theory: Complete, Consistent, Non-trivial. Choose two."


Animal Logic
http://www.animallogic.com

Please think of the environment before printing this email.

This email and any attachments may be confidential and/or privileged. If you 
are not the intended recipient of this email, you must not disclose or use the 
information contained in it. Please notify the sender immediately and delete 
this document if you have received it in error. We do not guarantee this email 
is error or virus free.

Re: [pygame] PyGame / PyOpenGL Example

[Ian Mallett]

That would explain weird problems people have had with my code...

Re: [pygame] PyGame / PyOpenGL Example

[Greg Ewing]

David wrote:


Do you have an algorithm as to how to automatically divide an
arbitrary rectangle into a near-optimal set of smaller power-of-two
rectangles?


For an exact subdivision, decompose each of the coordinates
into powers of 2 (which is easy, just look at the bits) and
take all the pairwise combinations of widths and heights.

You might want to impose some minimum size on the pieces,
though, to avoid creating ridiculously small fragments.

--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,  | Carpe post meridiem! |
Christchurch, New Zealand  | (I'm not a morning person.)  |
[EMAIL PROTECTED]  +--+

Re: [pygame] PyGame / PyOpenGL Example

[Brian Fisher]

On Thu, Feb 14, 2008 at 5:42 AM, David <[EMAIL PROTECTED]> wrote:
>  Do you have an algorithm as to how to automatically divide an
>  arbitrary rectangle into a near-optimal set of smaller power-of-two
>  rectangles?
>
I've never written one myself - I've seen somebody else's code (I
think it might have been the popcap framework) that split stuff into
at most 4 textures only did a split only if the image was > .5 and >=
.75 of the next higher power-of-2 - so like 800 would stick with 1024
cause 512 + 256 < 800, but 600 would become 512 + 128 cause 512 + 256
> 600. In that case it would save like 30% of the memory usage of the
alternative (1024x1024 texture), and it also puts an upper bound on
the waste per image to be like 69%, as opposed to 400%.

I suppose it would be very simple to write a nice recursively defined
algo - basically where the function can be asked to decide how to
split some quad (either vertical horizontal or both) and when it does
split it would call itself on the leftovers as appropriate. I would
guess that you just put in some practical limit as the decision to
split in terms of pixel or percentage waste (to have 0 waste in the
crazy bad case of a 511x127 image you would have 9x7=63 textures for
that one image, while 1 texture would only be 1% waste - and you may
start getting occasional seams on some cards cause of floating point
issues on coords)


>  I am the author of Lamina, and just have never worried about
>  optimizing the texture usage.  Now that it has my attention, the
>  mapping of multiple subtextures into one continuous panel seems
>  straightforward, but choosing the subtexture sizes to start with is
>  not obvious.  I suppose I could just premap all the common full-screen
>  window sizes by hand, and then nearest-fit any other window sizes.
>
It's probably not important if you haven't found a case where it's
important. Compared to the weirdness that happens when you don't
address the power-of-2 problems at all (stuff like large white
textures or invisible content or slow performance on some machines,
like Richard mentioned)  it's small beans.

Re: [pygame] PyGame / PyOpenGL Example

[Brian Fisher]

On Wed, Feb 13, 2008 at 10:10 PM, Kris Schnee <[EMAIL PROTECTED]> wrote:
>  So, if I wanted to draw a GUI window across the screen, and I'd normally
>  want it to be, say, 800x200, I'd have to either split it and draw two
>  textures, or make the texture 1024x256, or just draw a polygon with
>  shading provided by OpenGL and use that as the window?
>
well I would think that in the general case redrawing the components
of the window would be the best solution - along the lines of the
third thing you mentioned - drawing a filled polygon (or maybe more
likely a quad). I don't think you'd want to use shading (i.e. lighting
off), and if you wanted to use power-of-2 textures as tiling for the
body of the window you could do that by setting the texture mode to
wrap. You could also draw window borders either by stretching or
tiling edge images.

If however you had a GUI that changed relatively little and already
performed well in Software rendering, doing the Lamina overlay
approach would probably be just as good. In fact it would be superior
if the gui overlay wasn't changing from frame to frame.

As far as whether to put your images in the next largest power-of-2
texture, or spread across multiple textures or packing multiple images
in a texture or whatever - I would say unless it sounds fun to write
the code to try one approach, the best thing is to make the problem
easy and just do the image in a larger texture thing. Then you can
optimize things later - if you need to. If you unload textures when
you don't need them (like after every level), or have fairly small art
requirements it will probably never be an issue.

Re: [pygame] PyGame / PyOpenGL Example

[Greg Ewing]

Ian Mallett wrote:
Strangely enough, I've never had problems using textures which are not a 
standard size.  Any idea why?


Some OpenGL implementations support non-power-of-2 sizes
(I believe it's one of the officially sanctioned extensions)
but not all. You're probably lucky enough to have one that
does -- but don't rely on your code working for other people.

--
Greg

Re: [pygame] PyGame / PyOpenGL Example

[Greg Ewing]

Brian Fisher wrote:

On Feb 13, 2008 3:43 PM, René Dudfield <[EMAIL PROTECTED]> wrote:


Have you seen the Lamina code?
http://pitchersduel.python-hosting.com/browser/branches/Lamina/


I would guess that it would perform poorly if you
wanted a lot of moving/animating pygame surfaces drawn all over.


You don't have to redraw the whole overlay -- you can just
update selected parts of the texture and redraw those, e.g.
the bounding rectangles of your sprites.


Also,
it appears to take the approach of putting the overlay into a subset
of a power of 2 texture.


I don't see much disadvantage in that, other than perhaps
wasting a bit of video memory. The unused parts of the
texture are never touched once the texture has been set
up.

And if you're clever, you may find something useful to
pack into the otherwise unused areas.

It's probably not the best in all cases, but the Lamina
approach has the advantage that it's very simple and
requires little modification of the techniques one
uses in normal 2D pygame apps. So it's often possible
to use one of the existing pygame gui libraries with
it almost unchanged.

--
Greg

Re: [pygame] PyGame / PyOpenGL Example

[David]

On 2/13/08, Brian Fisher <[EMAIL PROTECTED]> wrote:

> 2. spread images across multiple textures and draw all of them (so the
> 24x12 image would be spread across 4 textures, a 16x8, an 8x8, a 16x4
> and an 8x4) which lets you draw more polys in order to not waste so
> much video memory

Do you have an algorithm as to how to automatically divide an
arbitrary rectangle into a near-optimal set of smaller power-of-two
rectangles?

I am the author of Lamina, and just have never worried about
optimizing the texture usage.  Now that it has my attention, the
mapping of multiple subtextures into one continuous panel seems
straightforward, but choosing the subtexture sizes to start with is
not obvious.  I suppose I could just premap all the common full-screen
window sizes by hand, and then nearest-fit any other window sizes.

David

-- 
[EMAIL PROTECTED]
Pitcher's Duel -> pitchersduel.python-hosting.com

Re: [pygame] PyGame / PyOpenGL Example

[Richard Jones]

On Thu, 14 Feb 2008, Brian Fisher wrote:
> support for non-power of 2 texures is pretty much standard for recent
> graphics cards

Note that there can be a *significant* performance penalty when using some 
cards / drivers.


Richard

Re: [pygame] PyGame / PyOpenGL Example

[Brian Fisher]

On Wed, Feb 13, 2008 at 10:16 PM, Ian Mallett <[EMAIL PROTECTED]> wrote:
> Strangely enough, I've never had problems using textures which are not a
> standard size.  Any idea why?
>
I assume by "standard size" you mean non-power of 2... you probably
have no problem with it because all the machines you've worked with
have openGL 2.1 drivers and/or drivers with
ARB_texture_non_power_of_two enabled (glGetString(GL_EXTENSIONS) will
tell you what extensions you have - but as Rene found out for me,
don't call it before creating your window on Mac OSX)

support for non-power of 2 texures is pretty much standard for recent
graphics cards ...provided the user is running opengl drivers from the
card manufacturer (probably because it's part of the 2.1 standard) but
one notable place support is missing on windows is Vista's standard
OpenGL 1.4 implementation. It probably doesn't have that support
because it maps to Direct3D, where support for such textures is still
optional.

On Mac OSX, I *think* it's standard as of the machines that came out
about the 10.4/Intel change era

Re: [pygame] PyGame / PyOpenGL Example

[Ian Mallett]

Strangely enough, I've never had problems using textures which are not a
standard size.  Any idea why?

Re: [pygame] PyGame / PyOpenGL Example

[Kris Schnee]

Brian Fisher wrote:

... Also, I have to say that at first I thought it would be a "Royal
Pain" to have to deal with rendering 2d stuff in openGL - but it
actually turned out to be much easier than I thought and kind of a lot
of fun (although I may have more pain later I suppose). The only thing
that isn't trivially simple, in my opinion, is figuring out how you
want to deal with texture size limitations. In particular, on the
majority of systems out there, textures have to be a power-of-2 in
width and height - so you have to deal with that to upload say a 24x12
image for blitting. The 3 basic approaches are:
1. overallocate textures and render just the portion of the texture
that has an image (so that 24x12 image would be on a 32x16 texture and
would render just texcoords (.0,.0)-(.75,.75)), which will waste about
50% of your video memory and possibly cause extra texture thrashing,
but actually some commercial games ship this way cause it just never
ended up being a problem for their game.
2. spread images across multiple textures and draw all of them (so the
24x12 image would be spread across 4 textures, a 16x8, an 8x8, a 16x4
and an 8x4) which lets you draw more polys in order to not waste so
much video memory
3. pack multiple images into a single texture - the attached example
uses that approach. It can be pathologically bad in terms of memory
thrashing in some cases (like say if you wanted to draw one image each
from 100 large multi-image textures) but if images that are used
together are in a texture together, it is actually the optimal
approach in terms of performance (like it tends to be good to make
sure font characters are all packed in textures together)


Thanks for the code.

So, if I wanted to draw a GUI window across the screen, and I'd normally 
want it to be, say, 800x200, I'd have to either split it and draw two 
textures, or make the texture 1024x256, or just draw a polygon with 
shading provided by OpenGL and use that as the window?

Re: [pygame] PyGame / PyOpenGL Example

[Ian Mallett]

On Feb 13, 2008 4:02 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:

> In my experience, doing anything in 3D is very hard work,
> and if you don't tackle the most important parts first,
> there's a danger of running out of steam before you
> get it finished.
>
  Greg is correct.  Do the most important stuff first, even though it is
often annoying to work on the basecode when you really want to write the fun
parts.  If you try to hang the game on a non-existent skeleton, you will
have problems.  And, continuing the metaphor, putting the skeleton in after
assembling the outside requires destroying parts of the skin and organs.  It
is also less efficient, reliable, and it takes longer.  Just do the basecode
first.

  Also, you must make sure you do it right.  Skeletal problems are hard to
fix later.  In particular, the draw function in which you implement the
camera is by far the most important.  Problems here can affect your code
horribly later.  Make sure it is right.  I recommend writing it by drawing a
simple object (say, a cube) and then build the code, constantly testing.  It
hurts in the short term, but it will pay off in the long run.

Ian

Re: [pygame] PyGame / PyOpenGL Example

[René Dudfield]

yeah, I think there are a couple of approaches.

Lamina takes the first approach... which is to make almost everything
work - just by updating dirty rects.  So you render to an offscreen
surface.  As long as you are careful with dirty rects - it should be
fairly fast, and not very complex.  Mainly to be able to use software
rendering in your opengl app.

However for lots of moving images, it's probably not the fastest way -
which is where your approach is better.


At one point a few years ago I tried to make a spritegl class - that
wasn't very sophisticated, but worked ok for basic games.  It's in
http://rene.f0o.com/rdpyg/ but it doesn't work on all games.  The idea
was to do it at the sprite level so you can optimize things like
drawing 20 sprites at once etc.  I found it ran mostly slower than SDL
- but it was really badly written, mostly as a prototype.  Both your
code, and Lamina are better.

It would be nice if pygame.sprite was more hardware friendly.  So
things like rotation, and scaling were abstracted.

Also note, that SDL 1.3 has pretty good opengl, and direct 3d
support... they basically use the idea of hardware surfaces for their
abstraction.  You can run some demos already, and it's interesting to
look at that API.


Also, here is some code to make opengl act like it's in 2D.  So you
can draw things using pixel coordinates, rather than 3d coordinates.

http://pygame.org/wiki/MakeOpenglDrawIn2D

def glEnable2D():
""" make opengl behave like you are drawing in 2d."""
vPort = glGetIntegerv(GL_VIEWPORT)
glMatrixMode(GL_PROJECTION)
glPushMatrix()
glLoadIdentity()
glOrtho(0, vPort[2], 0, vPort[3], -1, 1)
glMatrixMode(GL_MODELVIEW)
glPushMatrix()
glLoadIdentity()



def glDisable2D():
   """ Use when you've finished drawing in 2D.   """
   glMatrixMode(GL_PROJECTION)
   glPopMatrix()
   glMatrixMode(GL_MODELVIEW)
   glPopMatrix()





cu,


On Feb 14, 2008 12:22 PM, Brian Fisher <[EMAIL PROTECTED]> wrote:
> On Feb 13, 2008 3:43 PM, René Dudfield <[EMAIL PROTECTED]> wrote:
> > Have you seen the Lamina code?
> > http://pitchersduel.python-hosting.com/browser/branches/Lamina/
> >
> I hadn't seen it before - It appears to take the approach of
> maintaining a single full-screen overlay which is created from a
> pygame surface. I would guess that it would perform poorly if you
> wanted a lot of moving/animating pygame surfaces drawn all over. Also,
> it appears to take the approach of putting the overlay into a subset
> of a power of 2 texture.
>
>
> > It'd be nice to be able to get one of these into the pygame
> > examples... or onto the cookbook.  Especially if it can be used to run
> > existing games (with a little modification).
> >
> It sounds fun to write something like that up - should the goal be
> something that is close to a drop in replacement for pygame.display
> stuff? maybe with some additional interface for getting transformed
> and colored blits or something?
>

Re: [pygame] PyGame / PyOpenGL Example

[Brian Fisher]

On Feb 13, 2008 3:43 PM, René Dudfield <[EMAIL PROTECTED]> wrote:
> Have you seen the Lamina code?
> http://pitchersduel.python-hosting.com/browser/branches/Lamina/
>
I hadn't seen it before - It appears to take the approach of
maintaining a single full-screen overlay which is created from a
pygame surface. I would guess that it would perform poorly if you
wanted a lot of moving/animating pygame surfaces drawn all over. Also,
it appears to take the approach of putting the overlay into a subset
of a power of 2 texture.


> It'd be nice to be able to get one of these into the pygame
> examples... or onto the cookbook.  Especially if it can be used to run
> existing games (with a little modification).
>
It sounds fun to write something like that up - should the goal be
something that is close to a drop in replacement for pygame.display
stuff? maybe with some additional interface for getting transformed
and colored blits or something?

Re: [pygame] PyGame / PyOpenGL Example

[Brian Fisher]

On Feb 13, 2008 4:28 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> There's also
>
> 4. Scale the texture image so that it has power-of-2 sizes
>
> which may work well enough for photographic images and such
> like where you're not too concerned about the appearance of
> fine details.
>
I've heard that approach suggested before, but In my opinion, that
approach is either inferior or equivalent in every respect to approach
1 that I mentioned (putting the image in a portion of a power of 2
texture, and draw from a subset of the texture)

The reasons why are:
1. They both take up exactly the same amount of video memory
2. Performance is worse for the scaled one because when drawing only
the original image pixels from a subset of the texture the video card
only has to lookup and filter those original pixels, but when the
image was scaled now the video card has to lookup and filter
additional pixels (it would tend to be around 2x the mem lookup)
3. Quality is worse for the scaled one, especially when rendering at
the original image size - even if you got a super awesome up scale
(like blackman or something) going into the texture, you are still
getting a bilinear filter on the rendering
4. Time to load images to the card is (ever so slightly) worse with
the scaled one, cause you have to do the scale
5. You have to write/utilize more code in the scaling case

For that reason, I would say there are only 3 sensible approaches to
the images to power-of-2 texture mapping problem, that I am aware of.

Re: [pygame] PyGame / PyOpenGL Example

[Greg Ewing]

Brian Fisher wrote:

textures have to be a power-of-2 in
width and height - so you have to deal with that to upload say a 24x12
image for blitting. The 3 basic approaches are:


There's also

4. Scale the texture image so that it has power-of-2 sizes

which may work well enough for photographic images and such
like where you're not too concerned about the appearance of
fine details.

--
Greg

Re: [pygame] PyGame / PyOpenGL Example

[Greg Ewing]

Kris Schnee wrote:

Maybe I'm answering my own question here. I'm basically looking for eye 
candy instead of focusing on the gameplay concepts I want to develop.


It's probably better to focus on getting the gameplay right
before going after eye candy. Maybe prototype the whole
thing in 2D first.

In my experience, doing anything in 3D is very hard work,
and if you don't tackle the most important parts first,
there's a danger of running out of steam before you
get it finished.

--
Greg

Re: [pygame] PyGame / PyOpenGL Example

[René Dudfield]

Very cool :)


Have you seen the Lamina code?
http://pitchersduel.python-hosting.com/browser/branches/Lamina/

btw, I had to comment out this line, which seems to be fcked on
pyopengl cvs.  Otherwise it segfaulted.
#print glGetString(GL_EXTENSIONS)

I also get this on exit:
Exception exceptions.TypeError: "'NoneType' object is not callable" in
> ignored


It'd be nice to be able to get one of these into the pygame
examples... or onto the cookbook.  Especially if it can be used to run
existing games (with a little modification).



cheers,




On Feb 14, 2008 10:14 AM, Brian Fisher <[EMAIL PROTECTED]> wrote:
> attached is an example of one way to draw pygame surfaces in OpenGL.
> It's originally a piece of a larger library, so I tried to rip out
> dependencies on that library. It exports a "Display" class which takes
> over creating the pygame display and can blit objects which have 4
> attributes on them - surface (pygame surface), width, height and
> hotspot (2 element sequence saying where the center of the image is).
> When things are blit, the Display class adds attributes to the object
> to track GL texture info. If you run it, it shows itself working (if
> __name__=="__main__": thing)
>
> It doesn't show how to print text (my class for that was too hairy to
> extract) but the approach I take is to have pygame.font render
> individual characters from strings to surfaces as needed and store
> them in dict (so they won't be regenerated all the the time), and then
> blit the cached surfaces for each letter in the string to the display
>
> There are 2 somewhat unusual things about this code - first is it
> uploads the textures as "premultiplied-alpha" or what it calls
> Light-Opacity model, where the blend mode is GL_ONE,
> GL_ONE_MINUS_SRC_ALPHA - the reason for that is that its the only way
> to get GL's bilinear filtering math to be accurate (so you don't
> introduce edge artifacts by blending color's that are supposed to be
> transparent - the yellow blocks in the exampleGL.py would have brown
> edges if it used Color-Opacity RGBA). The other weird thing is it has
> some 2d motion blur stuff.
>
> ... Also, I have to say that at first I thought it would be a "Royal
> Pain" to have to deal with rendering 2d stuff in openGL - but it
> actually turned out to be much easier than I thought and kind of a lot
> of fun (although I may have more pain later I suppose). The only thing
> that isn't trivially simple, in my opinion, is figuring out how you
> want to deal with texture size limitations. In particular, on the
> majority of systems out there, textures have to be a power-of-2 in
> width and height - so you have to deal with that to upload say a 24x12
> image for blitting. The 3 basic approaches are:
> 1. overallocate textures and render just the portion of the texture
> that has an image (so that 24x12 image would be on a 32x16 texture and
> would render just texcoords (.0,.0)-(.75,.75)), which will waste about
> 50% of your video memory and possibly cause extra texture thrashing,
> but actually some commercial games ship this way cause it just never
> ended up being a problem for their game.
> 2. spread images across multiple textures and draw all of them (so the
> 24x12 image would be spread across 4 textures, a 16x8, an 8x8, a 16x4
> and an 8x4) which lets you draw more polys in order to not waste so
> much video memory
> 3. pack multiple images into a single texture - the attached example
> uses that approach. It can be pathologically bad in terms of memory
> thrashing in some cases (like say if you wanted to draw one image each
> from 100 large multi-image textures) but if images that are used
> together are in a texture together, it is actually the optimal
> approach in terms of performance (like it tends to be good to make
> sure font characters are all packed in textures together)
>
> I hope the example helps - also I'm interested in ways people think
> this code could be improved.
>
>
>
> > On Tue, 12 Feb 2008 23:23:49 +1030, fragged <[EMAIL PROTECTED]>
> > wrote:
> > Hey guys,
> >
> > I've been searching for some decent examples of PyOpenGL to help me port
> > my current application to OpenGL to speed things up on my perty new
> > 1920x1200 LCD (Getting about 20fps, using no acceleration whatsoever),
> > however I've been unable to find any decent guides on the net that
> > simply show me how to do the equivalent of loading an image and some
> > text - the small fragments I have found have still been using PyGame to
> > render text and this seems to break on my gentoo system whilist working
> > on another and I'm not really sure if this is the /propper/ way to do it.
> >
> > would somebody have one of these laying about, know of one or be able to
> > hack one up for me? It'd be a great help and I'd also love to see it go
> > in the examples directory on PyGame.org as there seems to be very few
> > extreme beguinners guides.
> >
>

Re: [pygame] PyGame / PyOpenGL Example

[Brian Fisher]

attached is an example of one way to draw pygame surfaces in OpenGL.
It's originally a piece of a larger library, so I tried to rip out
dependencies on that library. It exports a "Display" class which takes
over creating the pygame display and can blit objects which have 4
attributes on them - surface (pygame surface), width, height and
hotspot (2 element sequence saying where the center of the image is).
When things are blit, the Display class adds attributes to the object
to track GL texture info. If you run it, it shows itself working (if
__name__=="__main__": thing)

It doesn't show how to print text (my class for that was too hairy to
extract) but the approach I take is to have pygame.font render
individual characters from strings to surfaces as needed and store
them in dict (so they won't be regenerated all the the time), and then
blit the cached surfaces for each letter in the string to the display

There are 2 somewhat unusual things about this code - first is it
uploads the textures as "premultiplied-alpha" or what it calls
Light-Opacity model, where the blend mode is GL_ONE,
GL_ONE_MINUS_SRC_ALPHA - the reason for that is that its the only way
to get GL's bilinear filtering math to be accurate (so you don't
introduce edge artifacts by blending color's that are supposed to be
transparent - the yellow blocks in the exampleGL.py would have brown
edges if it used Color-Opacity RGBA). The other weird thing is it has
some 2d motion blur stuff.

... Also, I have to say that at first I thought it would be a "Royal
Pain" to have to deal with rendering 2d stuff in openGL - but it
actually turned out to be much easier than I thought and kind of a lot
of fun (although I may have more pain later I suppose). The only thing
that isn't trivially simple, in my opinion, is figuring out how you
want to deal with texture size limitations. In particular, on the
majority of systems out there, textures have to be a power-of-2 in
width and height - so you have to deal with that to upload say a 24x12
image for blitting. The 3 basic approaches are:
1. overallocate textures and render just the portion of the texture
that has an image (so that 24x12 image would be on a 32x16 texture and
would render just texcoords (.0,.0)-(.75,.75)), which will waste about
50% of your video memory and possibly cause extra texture thrashing,
but actually some commercial games ship this way cause it just never
ended up being a problem for their game.
2. spread images across multiple textures and draw all of them (so the
24x12 image would be spread across 4 textures, a 16x8, an 8x8, a 16x4
and an 8x4) which lets you draw more polys in order to not waste so
much video memory
3. pack multiple images into a single texture - the attached example
uses that approach. It can be pathologically bad in terms of memory
thrashing in some cases (like say if you wanted to draw one image each
from 100 large multi-image textures) but if images that are used
together are in a texture together, it is actually the optimal
approach in terms of performance (like it tends to be good to make
sure font characters are all packed in textures together)

I hope the example helps - also I'm interested in ways people think
this code could be improved.


> On Tue, 12 Feb 2008 23:23:49 +1030, fragged <[EMAIL PROTECTED]>
> wrote:
> Hey guys,
>
> I've been searching for some decent examples of PyOpenGL to help me port
> my current application to OpenGL to speed things up on my perty new
> 1920x1200 LCD (Getting about 20fps, using no acceleration whatsoever),
> however I've been unable to find any decent guides on the net that
> simply show me how to do the equivalent of loading an image and some
> text - the small fragments I have found have still been using PyGame to
> render text and this seems to break on my gentoo system whilist working
> on another and I'm not really sure if this is the /propper/ way to do it.
>
> would somebody have one of these laying about, know of one or be able to
> hack one up for me? It'd be a great help and I'd also love to see it go
> in the examples directory on PyGame.org as there seems to be very few
> extreme beguinners guides.
>
"""
Implementation of how to render to the display for gl stuff

(C) Copyright 2005 Hamster Republic Productions - but you are free to do whatever you want with this
"""



import pygame
import math
import OpenGL
from OpenGL.GL import *
import weakref
import types
#from motherhamster.imageassets import ImageAsset
#from motherhamster import editorinfo
import array


def GetHigherPowerOf2(value):
return 2**int(math.ceil(math.log(value, 2)))

def UnpackImage(image):
#CHECK: really need to queue up the item for later...
# in a multithreaded envron. this might happen at a bad time
if hasattr(image, "GLtexture"):
texture_pack = image.GLtexture
textur

Re: [pygame] PyGame / PyOpenGL Example

[René Dudfield]

Also note most of the nehe tutorials have been translated to python in
the pyopengl Demo directory.

chairs,

On Feb 14, 2008 7:49 AM, Ian Mallett <[EMAIL PROTECTED]> wrote:
> If you really want to make something nice, even if it is a 2D
> background, your best option is to render a 3D image.
>
> The image you're looking at doesn't look like it was created with a
> heightmap, the simplest way of making 3D terrain, because the texture
> does not appear to stretch.
>
> You can something almost as good by using a heightmap (a heightmap
> codes elevations into pixels.  You can use a tool to make them, like
> "Earth Sculpter", because doing so by hand is inaccurate and slow).
>
> You then convert the image into a mesh of polygons by iterating
> through each pixel.  There some nice tutorials out there for this,
> too.  The mesh is then compiled into a display list for speed.  The
> map is then drawn at the correct location.  The houses, trees, and the
> like in the image you pointed out are made separately, then
> superimposed into the final scene before it is drawn.
>
> All in all, it is a pretty complicated mess.  If you're just beginning
> OpenGL, I recommend the Python NeHe tutorials:
> http://www.pygame.org/gamelets/ as a good introduction.  gamedev.net
> can help you with the finer details.
>
> Ian
>

Re: [pygame] PyGame / PyOpenGL Example

[Ian Mallett]

If you really want to make something nice, even if it is a 2D
background, your best option is to render a 3D image.

The image you're looking at doesn't look like it was created with a
heightmap, the simplest way of making 3D terrain, because the texture
does not appear to stretch.

You can something almost as good by using a heightmap (a heightmap
codes elevations into pixels.  You can use a tool to make them, like
"Earth Sculpter", because doing so by hand is inaccurate and slow).

You then convert the image into a mesh of polygons by iterating
through each pixel.  There some nice tutorials out there for this,
too.  The mesh is then compiled into a display list for speed.  The
map is then drawn at the correct location.  The houses, trees, and the
like in the image you pointed out are made separately, then
superimposed into the final scene before it is drawn.

All in all, it is a pretty complicated mess.  If you're just beginning
OpenGL, I recommend the Python NeHe tutorials:
http://www.pygame.org/gamelets/ as a good introduction.  gamedev.net
can help you with the finer details.

Ian

Re: [pygame] PyGame / PyOpenGL Example

[Kris Schnee]

Richard Jones wrote:

On Wed, 13 Feb 2008, René Dudfield wrote:

Apart from Richards shameless self promotion of pyglet, here's some
other things to look at...


It was more an attempt to dispel the "even in Python" statement :)


Heh. Thanks, both of you.

It looks like with Pyglet I'd need to learn its equivalents to Pygame's 
event handling, although that doesn't look too complex, and in exchange 
I'd get the ability to load textures and draw images and text easily 
while still being able to use standard OpenGL drawing functions. Maybe 
that's worth trying.


I'm having a hard time figuring out which of these many systems is best 
for my purposes, if I'm to do 3D. Am I making a mistake by looking at 3D 
at all? Since I'm working alone I have no ambitions to do full 3D 
animation; basically it'd be a way to represent a landscape with height. 
The terrain I'd like is a simple island landscape with rocks, trees and 
buildings, like this: 
 
Does it make sense to go to the trouble of a 3D engine to get the 
flexibility of being able to look at the terrain from any angle?


Maybe I'm answering my own question here. I'm basically looking for eye 
candy instead of focusing on the gameplay concepts I want to develop.

Re: [pygame] PyGame / PyOpenGL Example

[Brian Fisher]

On Feb 12, 2008 1:51 PM, Richard Jones <[EMAIL PROTECTED]> wrote:
> On Wed, 13 Feb 2008, René Dudfield wrote:
> > Apart from Richards shameless self promotion of pyglet, here's some
> > other things to look at...
>
> It was more an attempt to dispel the "even in Python" statement :)
>
Can't it be both? :)

Re: [pygame] PyGame / PyOpenGL Example

[Richard Jones]

On Wed, 13 Feb 2008, René Dudfield wrote:
> Apart from Richards shameless self promotion of pyglet, here's some
> other things to look at...

It was more an attempt to dispel the "even in Python" statement :)


Richard

Re: [pygame] PyGame / PyOpenGL Example

[René Dudfield]

Apart from Richards shameless self promotion of pyglet, here's some
other things to look at...


Have a look in the Demo directory of pyopengl for many goodies.  It's
an often overlooked place of python opengl code.

If you want to render text in 3d: http://ttfquery.sourceforge.net/

soya, openglcontext, python-ogre, blender, vision egg, visual
python... the all have text stuff.  Have a look here for more goodies:
http://www.vrplumber.com/py3d.py

And here's how to use pygame gui libraries(pgu, ocemp etc) with opengl:
http://pitchersduel.python-hosting.com/browser/branches/Lamina/

There's some easy to use demos included with Lamina using pygame to
render in 2D and only updating the screen as needed.

Also have a look at http://pygame.org/wiki/CookBook  There appears to
be some text things in there too.


Good idea about adding to pygame examples of such a common thing.
Mostly people go to the pyopengl Demo directory for opengl stuff - but
we should put something like this into pygame too.  Maybe Lamina
itself should be included with pygame.

For now the cookbook would be a great place to put examples for this.



cu,




On Feb 13, 2008 7:56 AM, Richard Jones <[EMAIL PROTECTED]> wrote:
> On Wed, 13 Feb 2008, kschnee wrote:
> > Loading images and
> > displaying those and text is a royal pain in OpenGL, even in Python.
>
> The "even in Python" is a little out of date now :)
>
> from pyglet import image, font
>
> # display an image
> im = image.load('image.png')
> im.blit()
>
> # display some text
> t = font.Text(font.load('', 24), 'Hello, world!')
> t.draw()
>
>
>  Richard
>

Re: [pygame] PyGame / PyOpenGL Example

[Richard Jones]

On Wed, 13 Feb 2008, kschnee wrote:
> Loading images and
> displaying those and text is a royal pain in OpenGL, even in Python.

The "even in Python" is a little out of date now :)

from pyglet import image, font

# display an image
im = image.load('image.png')
im.blit()

# display some text
t = font.Text(font.load('', 24), 'Hello, world!')
t.draw()


 Richard

Re: [pygame] PyGame / PyOpenGL Example

[Ian Mallett]

I don't exactly recommend the NeHe tutorials for their nice code, but
there are some nice clear enough python examples.

http://www.pygame.org/gamelets/
Has nehe tutorials 1-10.

I'll write some OpenGL basecode sometime too.

Re: [pygame] PyGame / PyOpenGL Example

[kschnee]

On Tue, 12 Feb 2008 23:23:49 +1030, fragged <[EMAIL PROTECTED]>
wrote:
> Hey guys,
> 
> I've been searching for some decent examples of PyOpenGL to help me port
> my current application to OpenGL to speed things up on my perty new
> 1920x1200 LCD (Getting about 20fps, using no acceleration whatsoever),
> however I've been unable to find any decent guides on the net that
> simply show me how to do the equivalent of loading an image and some
> text - the small fragments I have found have still been using PyGame to
> render text and this seems to break on my gentoo system whilist working
> on another and I'm not really sure if this is the /propper/ way to do it.
> 
> would somebody have one of these laying about, know of one or be able to
> hack one up for me? It'd be a great help and I'd also love to see it go
> in the examples directory on PyGame.org as there seems to be very few
> extreme beguinners guides.


Hey.

I'll look again at my old code later, but for now: Loading images and
displaying those and text is a royal pain in OpenGL, even in Python. For
images you basically need to load a texture and convert it, and I think
there's a restriction on the size or proportion of textures. Drawing stuff
in 2D, as for a GUI, involves switching to an "ortho" mode and either
manually drawing shaded rectangles, or drawing rectangles textured with a
pre-loaded texture. Drawing the text can be done in several ways:
finding/creating a bitmap of a font, or making a bunch of textures out of
an image, or using a stand-alone module like PyGlyph (with which I've had
some success). It's easier to draw a spinning translucent textured cube in
OpenGL than to write "Hello World!" The "ortho" switch is not that hard, at
least; I've got code for that. After much fiddling every so often, I've
been reverting to 2D. Still, I'd like to get a simple 3D landscape with a
sky and "billboarded" sprites, plus the ability to use my GUI with it.

For the moment, try looking up the "NeHe OpenGL" tutorials, the first few
of which are available in Python. (The key parts are pretty much the same
in any language too.) Also look up the "OpenGL RedBook," a version of which
is available free online. I think I put the crude OpenGL code I was using
into the ZIP at , so you
might look at that for ideas.

A(nother) good basic demo of images and text would be great, yeah.

Kris

[pygame] PyGame / PyOpenGL Example

[fragged]

Hey guys,

I've been searching for some decent examples of PyOpenGL to help me port 
my current application to OpenGL to speed things up on my perty new 
1920x1200 LCD (Getting about 20fps, using no acceleration whatsoever), 
however I've been unable to find any decent guides on the net that 
simply show me how to do the equivalent of loading an image and some 
text - the small fragments I have found have still been using PyGame to 
render text and this seems to break on my gentoo system whilist working 
on another and I'm not really sure if this is the /propper/ way to do it.


would somebody have one of these laying about, know of one or be able to 
hack one up for me? It'd be a great help and I'd also love to see it go 
in the examples directory on PyGame.org as there seems to be very few 
extreme beguinners guides.


Oh, and if your looking at 20fps on that resolution thinking that it is 
something else your probbably right. Although there is 
pygame.update.rect() or whatever I'd much prefer something that is 
accelerated both for my understanding of computers and that smooth 60fps 
that I'd be getting :D


Cheers
Fragged aka Colin

Re: [pygame] MacOS/PyGame/PyOpenGL mouse inversion

[Dave LeCompte (really)]

> I'm not sure how you got the older version, and why pygame is loading
> it... I'm pretty sure I installed 1.8.0pre from the pythonmac.org
> universal binary prebuilt:

Yeah, that looks like the same place I installed from, too.

This weekend, I'll do some exploring around my installation and see if I
can turn up any clues - perhaps my last upgrade left things in a slightly
inconsistent state.


Thanks for the assistance.
-Dave LeCompte