[pygame] PyOpenGL and pygame.display.flip
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()
Re: [pygame] PyOpenGL and pygame.display.flip
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] the pygame/pyopengl sprint has started
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
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
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
[pygame] (pyopengl) GLSL fragment shader with arrays uniform cause sporadic screen blinking
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
On Fri, Feb 11, 2011 at 3:37 PM, amdlintuxo amdlintu...@gmail.com 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
Re: [pygame] (pyopengl) GLSL fragment shader with arrays uniform cause sporadic screen blinking
On Fri, Feb 11, 2011 at 5:01 PM, claudio canepa ccanep...@gmail.com wrote:
On Fri, Feb 11, 2011 at 3:37 PM, amdlintuxo amdlintu...@gmail.com 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
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 amdlintu...@gmail.com 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.
[pygame] [pyopengl] glActiveTexture(GL_TEXTURE1) cause failure in my code, can't get the reason why
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!
[pygame] Pygame, PyOpenGl, and py2exe, OH MY!
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 module
File zipextimporter.pyo, line 82, in load_module
File pygl2d\__init__.pyo, line 5, in module
File zipextimporter.pyo, line 82, in load_module
File pygl2d\window.pyo, line 3, in module
File .\OpenGL\GL\__init__.py, line 2, in module
from OpenGL.raw.GL import *
File .\OpenGL\raw\GL\__init__.py, line 6, in module
from OpenGL.raw.GL.constants import *
File .\OpenGL\raw\GL\constants.py, line 7, in module
from OpenGL import platform, arrays
File .\OpenGL\arrays\__init__.py, line 22, in module
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 module
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
names = []
Re: [pygame] Pygame, PyOpenGl, and py2exe, OH MY!
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 module
File zipextimporter.pyo, line 82, in load_module
File pygl2d\__init__.pyo, line 5, in module
File zipextimporter.pyo, line 82, in load_module
File pygl2d\window.pyo, line 3, in module
File .\OpenGL\GL\__init__.py, line 2, in module
from OpenGL.raw.GL import *
File .\OpenGL\raw\GL\__init__.py, line 6, in module
from OpenGL.raw.GL.constants import *
File .\OpenGL\raw\GL\constants.py, line 7, in module
from OpenGL import platform, arrays
File .\OpenGL\arrays\__init__.py, line 22, in module
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 module
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)
Re: [pygame] PyOpenGL Release 3.0.0 (final)
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. PyOpenGL 3.0.0 is intended for use with the Python 2.x series, porting to Python 3.x is not
Re: [pygame] PyOpenGL Release 3.0.0 (final)
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)
On Fri, Apr 3, 2009 at 2:20 AM, Mike C. Fletcher mcfle...@vrplumber.comwrote: 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] Python - Pygame - PyOpenGL performance
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] roeb...@gmail.com 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] roeb...@gmail.com 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 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
Re: [pygame] Python - Pygame - PyOpenGL performance
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 peter.geba...@stockholm.bostream.se 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
Re: [pygame] Python - Pygame - PyOpenGL performance
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 ca...@pandora.com 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] roeb...@gmail.com 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] roeb...@gmail.com 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 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
Re: [pygame] Python - Pygame - PyOpenGL performance
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.comwrote: 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
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] roeb...@gmail.com 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] roeb...@gmail.com 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 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. -- Thanks, Richie Ward
Re: [pygame] Python - Pygame - PyOpenGL performance
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 peter.geba...@stockholm.bostream.se 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 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
Re: [pygame] Python - Pygame - PyOpenGL performance
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 peter.geba...@stockholm.bostream.se 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.
Re: [pygame] Python - Pygame - PyOpenGL performance
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 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%. 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 peter.geba...@stockholm.bostream.se 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,
Re: [pygame] Python - Pygame - PyOpenGL performance
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.comwrote: 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
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 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
[pygame] Python - Pygame - PyOpenGL performance
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
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 zack.schill...@gmail.comwrote: 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
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 zack.schill...@gmail.comwrote: 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 zack.schill...@gmail.com 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
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
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 zack.schill...@gmail.com 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 zack.schill...@gmail.com 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
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
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] gui with pygame + pyopengl
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.Theme('test_theme');
[pygame] gui with pygame + pyopengl
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] gui with pygame + pyopengl
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.
Re: [pygame] pyopengl sprite/particle performance
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) / | | \
Re: [pygame] pyopengl sprite/particle performance
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) / | | \
[pygame] pyopengl sprite/particle performance
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
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: [pygame] PyOpenGL Screenshots
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
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
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,
Re: [pygame] PyOpenGL Screenshots
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
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
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
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 your favourite video editing package. 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)
adding note to glTexImage2D exception for non-power of 2 textures. Re: [pygame] compiled exe in pygame/pyopengl working locally but not elsewhere
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] PyOpenGL Screenshots
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
Re: [pygame] PyOpenGL Screenshots
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
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
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,
[pygame] compiled exe in pygame/pyopengl working locally but not elsewhere
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] compiled exe in pygame/pyopengl working locally but not elsewhere
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.
Re: [pygame] compiled exe in pygame/pyopengl working locally but not elsewhere
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] mailto:[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
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. 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
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] mailto:[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] mailto:[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
Re: [pygame] compiled exe in pygame/pyopengl working locally but not elsewhere
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] mailto:[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] mailto:[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,
Re: [pygame] PyGame / PyOpenGL Example
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
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
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
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
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
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
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
That would explain weird problems people have had with my code...
Re: [pygame] PyGame / PyOpenGL Example
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: http://www.terragame.com/downloadable/strategy/tribal_trouble/screen_1.jpg 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
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
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
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 texture_pack.lose_image(image) def
Re: [pygame] PyGame / PyOpenGL Example
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 bound method TexturePack.__del__ of __main__.TexturePack instance at 0x2b2a8f0 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
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
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
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
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
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
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
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
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
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
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
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
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 http://kschnee.xepher.net/code/070801cubeland.zip, 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
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
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
Re: [pygame] MacOS/PyGame/PyOpenGL mouse inversion
I'm running Mac OS X 10.4.8, and my pygame version is 1.8.0pre. I ran the sample script provided on an intel iMac OS X 10.4.8 with pygame 1.8.0pre and both windowed and full-screen behaved correctly (the diamond followed the mouse) according to the headers for the framework sdl build I've got, it's 1.2.11 It makes sense to me that it would be fixed in the latest because I looked at the libsdl mailing list archives and this post seemed to be a patch for the problem: http://www.libsdl.org/pipermail/sdl/2005-November/071307.html and this post indicated it had been applied: http://www.libsdl.org/pipermail/sdl/2005-November/071404.html So Dave, what OS X version are you running on? Can you tell which SDL your pygame is running on?
Re: [pygame] MacOS/PyGame/PyOpenGL mouse inversion
Dave, what sdl version is pygame calling when you see the inverted mouse problem? call: print pygame.base.get_sdl_version() to confirm, if you run your script and the diamond follows the mouse, everything is working correctly, right? i.e. when the y is inverted the diamond is at the wrong spot, yes? On 1/18/07, Dave LeCompte (really) [EMAIL PROTECTED] wrote: I'm running Mac OS X 10.4.8, and my pygame version is 1.8.0pre.
Re: [pygame] MacOS/PyGame/PyOpenGL mouse inversion
On 1/18/07, Dave LeCompte (really) [EMAIL PROTECTED] wrote: call: print pygame.base.get_sdl_version() (1, 2, 7) Ah - that must be the issue... mine is (1, 2, 11).. the sdl bug with the y inversion must have been fixed somewhere between patch 7 and patch 11 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: http://pythonmac.org/packages/py24-fat/mpkg/pygame-1.8.0pre-py2.4-macosx10.4.zip and that it installed the framework build of sdl... do you know where you installed from?
Re: [pygame] MacOS/PyGame/PyOpenGL mouse inversion
Chris Ashurst wrote: I think on all systems (and if you're used to getting mouse x/y coordinates via the SDL side of pygame) the mouse is flipped when you use OpenGL. No, it's a known (and resolved in later versions) bug in SDL. Workaround locally by flipping Y or use a later version. Alex.
RE: [pygame] MacOS/PyGame/PyOpenGL mouse inversion
Aha! Thanks for clarifying... After doing so many braintwisting tutorials that required me to move my camera right to make my object go left has left my brain swiss-cheesed :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Alex Holkner Sent: Wednesday, January 17, 2007 09:45 To: pygame-users@seul.org Subject: Re: [pygame] MacOS/PyGame/PyOpenGL mouse inversion Chris Ashurst wrote: I think on all systems (and if you're used to getting mouse x/y coordinates via the SDL side of pygame) the mouse is flipped when you use OpenGL. No, it's a known (and resolved in later versions) bug in SDL. Workaround locally by flipping Y or use a later version. Alex. CONFIDENTIAL NOTICE: This email including any attachments, contains confidential information belonging to the sender. It may also be privileged or otherwise protected by work product immunity or other legal rules. This information is intended only for the use of the individual or entity named above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or the taking of any action in reliance on the contents of this emailed information is strictly prohibited. If you have received this email in error, please immediately notify us by reply email of the error and then delete this email immediately.
Re: [pygame] MacOS/PyGame/PyOpenGL mouse inversion
try to use glOrtho instead og gluOrtho2D and see if you still get the same # glOrtho(left, right, bottom, top, zNear, zFar) glOrtho(0, 640, 480, 0, 1, 0) should set 0,0 to the left,top Chris Ashurst wrote: I think on all systems (and if you're used to getting mouse x/y coordinates via the SDL side of pygame) the mouse is flipped when you use OpenGL. I think it's something to do with the fact that OpenGL itself is device and system agnostic, and was built with the idea in mind that it's just a 3d engine rather than a 3d engine + widgets. Additionally, it may also be something to do with the fact that any object you manipulate in an OGL context is relative to the camera, and to move the camera around an object you have to move it right if you want the object to move left, up to move it down and so on. People with more experience with OpenGL can probably clarify, but I have hit this same issue before, too. I think the x coord turned out to be fine, all I needed to do was write a function that inverted the y coordinate to get the real value. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dave LeCompte (really) Sent: Tuesday, January 16, 2007 20:20 To: pygame-users@seul.org Subject: [pygame] MacOS/PyGame/PyOpenGL mouse inversion Hi there, I'm new to the list, so this may have been answered before. I've got a PyGame/PyOpenGL app that I'm working on which I can run under MSWindows or Mac OSX and in windowed or fullscreen mode. I notice that when I run in a window on my Mac, the value returned by pygame.mouse.get_pos() is relative to the lower left corner of the screen, but if I run fullscreen on the Mac, fullscreen on by Windows PC, or in a window on the Windows PC, the value is relative the the upper left corner (agreeing with the docs at http://www.pygame.org/docs/ref/mouse.html#pygame.mouse.get_pos ). Is this a known issue? Attached is a short test script that displays the strange behavior. -Dave LeCompte CONFIDENTIAL NOTICE: This email including any attachments, contains confidential information belonging to the sender. It may also be privileged or otherwise protected by work product immunity or other legal rules. This information is intended only for the use of the individual or entity named above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or the taking of any action in reliance on the contents of this emailed information is strictly prohibited. If you have received this email in error, please immediately notify us by reply email of the error and then delete this email immediately.
Re: [pygame] MacOS/PyGame/PyOpenGL mouse inversion
altern wrote: No, it's a known (and resolved in later versions) bug in SDL. Workaround locally by flipping Y or use a later version. My pygame.__version__ reports '1.8.0pre', which suggests to me that this bug fix hasn't made it into the latest Mac binaries. altern wrote: try to use glOrtho instead og gluOrtho2D and see if you still get the same # glOrtho(left, right, bottom, top, zNear, zFar) glOrtho(0, 640, 480, 0, 1, 0) should set 0,0 to the left,top Replacing glOrtho with glOrtho2D produced identical results on all platforms, including the inconsistency on the Mac when windowed. Thanks for the help. -Dave LeCompte Chris Ashurst wrote: I think on all systems (and if you're used to getting mouse x/y coordinates via the SDL side of pygame) the mouse is flipped when you use OpenGL. I think it's something to do with the fact that OpenGL itself is device and system agnostic, and was built with the idea in mind that it's just a 3d engine rather than a 3d engine + widgets. Additionally, it may also be something to do with the fact that any object you manipulate in an OGL context is relative to the camera, and to move the camera around an object you have to move it right if you want the object to move left, up to move it down and so on. People with more experience with OpenGL can probably clarify, but I have hit this same issue before, too. I think the x coord turned out to be fine, all I needed to do was write a function that inverted the y coordinate to get the real value. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dave LeCompte (really) Sent: Tuesday, January 16, 2007 20:20 To: pygame-users@seul.org Subject: [pygame] MacOS/PyGame/PyOpenGL mouse inversion Hi there, I'm new to the list, so this may have been answered before. I've got a PyGame/PyOpenGL app that I'm working on which I can run under MSWindows or Mac OSX and in windowed or fullscreen mode. I notice that when I run in a window on my Mac, the value returned by pygame.mouse.get_pos() is relative to the lower left corner of the screen, but if I run fullscreen on the Mac, fullscreen on by Windows PC, or in a window on the Windows PC, the value is relative the the upper left corner (agreeing with the docs at http://www.pygame.org/docs/ref/mouse.html#pygame.mouse.get_pos ). Is this a known issue? Attached is a short test script that displays the strange behavior. -Dave LeCompte CONFIDENTIAL NOTICE: This email including any attachments, contains confidential information belonging to the sender. It may also be privileged or otherwise protected by work product immunity or other legal rules. This information is intended only for the use of the individual or entity named above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or the taking of any action in reliance on the contents of this emailed information is strictly prohibited. If you have received this email in error, please immediately notify us by reply email of the error and then delete this email immediately.
Re: [pygame] MacOS/PyGame/PyOpenGL mouse inversion
This is all good knowledge to have, to be sure, but I think we're wandering afield from my original issue - I didn't want to ask about the default OpenGL coordinate systems, I'm reporting that the same code behaves differently on a Mac in a window than anywhere else. Run the code fullscreen on a Mac, it behaves as I expect. Run the code on a MSWindows PC, it behaves as I expect. I'm proceeding with the understanding that this is a known and resolved bug in the Mac SDL code and will be fixed when the 1.8 (final) binaries of PyGame are ready. Thanks, Dave LeCompte On 1/17/07, Chris Ashurst [EMAIL PROTECTED] wrote: I think on all systems (and if you're used to getting mouse x/y coordinates via the SDL side of pygame) the mouse is flipped when you use OpenGL. People with more experience with OpenGL can probably clarify, but I have hit this same issue before, too. I think the x coord turned out to be fine, all I needed to do was write a function that inverted the y coordinate to get the real value. If your use of openGL changes anything about the mouse coordinates returned from pygame, then I think it's a bug, like Alex says. Moving the mouse down (towards you) should always make it's y position increase, and moving it up (away from you) should always make it's y position decrease. However, when it comes to window coordinates, openGL by default uses a coordinate system where 0,0 is the lower left, and positive x goes right and positive y goes up. This is different from most computer systems where y goes down and 0,0 is the upper left. OpenGL uses the system it does because it follows the conventions of the cartesian coordinate space used in math physics. The place where you'd notice this the most in games is when using trig functions like sin cos, which also are designed for math physics openGL coordinate systems (positive rotations are counter-clockwise, 0 degrees is straight right y is up) So basically, I'm saying it's not that the mouse is flipped with OpenGL, it's that unless you set up your transforms to change it, OpenGL is flipped from what all the pygame/SDL and desktop position stuff is
Re: [pygame] MacOS/PyGame/PyOpenGL mouse inversion
Dave LeCompte (really) wrote: This is all good knowledge to have, to be sure, but I think we're wandering afield from my original issue - I didn't want to ask about the default OpenGL coordinate systems, I'm reporting that the same code behaves differently on a Mac in a window than anywhere else. Run the code fullscreen on a Mac, it behaves as I expect. Run the code on a MSWindows PC, it behaves as I expect. I'm proceeding with the understanding that this is a known and resolved bug in the Mac SDL code and will be fixed when the 1.8 (final) binaries of PyGame are ready. Sorry, made a mistake; the Pygame mac binary (1.7, haven't checked 1.8pre) includes SDL 1.2.11, which is current. Evidentally the issue is known but not resolved (some Googling on the topic will give you an idea of which releases of SDL it is fixed in, and which ones it is broken in). Alex.
Re: [pygame] MacOS/PyGame/PyOpenGL mouse inversion
I ran the sample script provided on an intel iMac OS X 10.4.8 with pygame 1.8.0pre and both windowed and full-screen behaved correctly (the diamond followed the mouse) according to the headers for the framework sdl build I've got, it's 1.2.11 It makes sense to me that it would be fixed in the latest because I looked at the libsdl mailing list archives and this post seemed to be a patch for the problem: http://www.libsdl.org/pipermail/sdl/2005-November/071307.html and this post indicated it had been applied: http://www.libsdl.org/pipermail/sdl/2005-November/071404.html So Dave, what OS X version are you running on? Can you tell which SDL your pygame is running on?
[pygame] MacOS/PyGame/PyOpenGL mouse inversion
Hi there, I'm new to the list, so this may have been answered before. I've got a PyGame/PyOpenGL app that I'm working on which I can run under MSWindows or Mac OSX and in windowed or fullscreen mode. I notice that when I run in a window on my Mac, the value returned by pygame.mouse.get_pos() is relative to the lower left corner of the screen, but if I run fullscreen on the Mac, fullscreen on by Windows PC, or in a window on the Windows PC, the value is relative the the upper left corner (agreeing with the docs at http://www.pygame.org/docs/ref/mouse.html#pygame.mouse.get_pos ). Is this a known issue? Attached is a short test script that displays the strange behavior. -Dave LeCompte import sys import pygame from pygame.locals import * from OpenGL.GL import * from OpenGL.GLU import * def main(): video_flags = OPENGL|DOUBLEBUF if -f in sys.argv: video_flags |= FULLSCREEN pygame.init() surf=pygame.display.set_mode((640,480), video_flags) glMatrixMode(GL_PROJECTION) glLoadIdentity() gluOrtho2D(0,640,480,0) glMatrixMode(GL_MODELVIEW) glLoadIdentity() glColor3f(1.0, 1.0, 1.0) done=False while not done: glClear(GL_COLOR_BUFFER_BIT) for e in pygame.event.get(): if e.type==QUIT or e.type == KEYDOWN: done=True mx,my=pygame.mouse.get_pos() glBegin(GL_LINE_LOOP) glVertex2f(320,0) glVertex2f(340,20) glVertex2f(300,20) glEnd() glBegin(GL_LINE_LOOP) glVertex2f(mx-5.0,my) glVertex2f(mx,my-5.0) glVertex2f(mx+5.0,my) glVertex2f(mx,my+5.0) glEnd() pygame.display.flip() main()
Re: [pygame] PyOpenGL and win32screensaver
Thanks Luke, it works great. Luke Paireepinart wrote: What kind of side effect should I expect from the OPENGL flag? Any ideas/workarounds? Happy Everything, Thanks, Ken! Okay, you asked for a workaround :) Don't use win32screensaver! If you just create a py2exe of your program, rename it to .scr, and put it in the right folder, it will work as the screensaver. Now, you won't get to create a cool demo in the preview window. Whenever your program's run, Windows will pass it arguments. SO when it's passed the -p, or whatever the 'preview' argument is, just do nothing. This should eliminate all conflicts, and you don't have to do any weird hardcoding of values! However, as I said, no preview. Also, it doesn't pack everything into a single EXE. Well, that's why it's called a workaround! By the way, does win32screensaver create a single file? I don't really want to take the time to check, so if you could just answer that for me it would be nice. Also, remember you have to handle the inputs yourself. I don't know if win32 screensaver exits on mousemovements or whatever, but your program won't if you just py2exe it. You'll have to check for mousemotion events, or keypresses, and whatnot. Anyway, HTH, -Luke
Re: [pygame] PyOpenGL and win32screensaver
What kind of side effect should I expect from the OPENGL flag? Any ideas/workarounds? Happy Everything, Thanks, Ken! Okay, you asked for a workaround :) Don't use win32screensaver! If you just create a py2exe of your program, rename it to .scr, and put it in the right folder, it will work as the screensaver. Now, you won't get to create a cool demo in the preview window. Whenever your program's run, Windows will pass it arguments. SO when it's passed the -p, or whatever the 'preview' argument is, just do nothing. This should eliminate all conflicts, and you don't have to do any weird hardcoding of values! However, as I said, no preview. Also, it doesn't pack everything into a single EXE. Well, that's why it's called a workaround! By the way, does win32screensaver create a single file? I don't really want to take the time to check, so if you could just answer that for me it would be nice. Also, remember you have to handle the inputs yourself. I don't know if win32 screensaver exits on mousemovements or whatever, but your program won't if you just py2exe it. You'll have to check for mousemotion events, or keypresses, and whatnot. Anyway, HTH, -Luke
[pygame] PyOpenGL and win32screensaver
I am trying to get a 3D screensaver to work using PyGame, PyOpenGL and win32screensaver. There seems to be an incompatibility that I haven't been able to resolve. Since win32screensaver invokes a special instance of pygame, I know I can't import pygame myself or use pygame.display.set_mode without extreme care. So I tried changing win32screensaver to have a configurable video_flags parameter. So pyscr_pygame.py[86] has: self.window = self.pygame.display.set_mode((self.width, self.height), self.video_flags) Now I set video_flags to 0x4002 (that's OPENGL|DOUBLEBUF, but of course I can't import pygame, so for now I just hard code it, until I get something working). Apparently the OPENGL flag is killing it. If I use the OPENGL flag, the process hangs during initialization (before the first draw is attempted). What kind of side effect should I expect from the OPENGL flag? Any ideas/workarounds? Should I try taking PyGame out of the loop? Neither PyOpenGL and win32screensaver actually require PyGame, but PyGame seems like it should be a convenient glue between the two. Besides, I have be able to make my PyOpenGL content work under PyGame, and I have successfully used win32screensaver with Pygame (without PyOpenGL). It would be nice to be able to do both at the same time. Happy Everything, - Ken Seehart
Re: [pygame] PyOpenGL
Bob Ippolito wrote: On Aug 8, 2006, at 2:28 PM, Kris Schnee wrote: I'm interested in trying OpenGL again with that sample code just posted, but isn't using PyOpenGL now a problem considering that it seems to require NumPy rather than Numeric, and that NumPy blatantly withholds its documentation? Since when does PyOpenGL require NumPy? The version I see is from Jan 2005, about a year before NumPy even existed (under that name as its own project). The answer to your question is most definitely No. because normal use involves just built-in types... but did PyOpenGL move away from sourceforge, or is your question simply not based on reality? It could be, but I was looking here: http://sourceforge.net/project/showfiles.php?group_id=5988 And saw PyOpenGL-2.0.2.01.py2.3-numpy23.exe (and py2.4) presented as what seemed to be the most recent distribution. Kris
Re: [pygame] PyOpenGL
On 8/8/06, Kris Schnee [EMAIL PROTECTED] wrote: I'm interested in trying OpenGL again with that sample code just posted, but isn't using PyOpenGL now a problem considering that it seems to require NumPy rather than Numeric, and that NumPy blatantly withholds its documentation? Isn't that begging the question? Honestly though, I use PyOpenGL, and I can't see how NumPy is used by PyOpenGL at all... in particular I haven't found any features of PyOpenGL which require me to write any code using NumPy, so I haven't had any need for documentation at all.
