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
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
Hey,
it's in spaghetti, and on irc. There's a hat/sign on the table in
spaghetti.
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:
-
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
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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 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
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%
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:
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:
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
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
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,
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
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
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 =
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
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
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
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
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
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
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
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
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
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
--
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
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:
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
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
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
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
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
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
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,
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
That would explain weird problems people have had with my code...
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
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
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
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 -
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
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
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
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
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
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
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
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
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
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 =
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
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.
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),
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
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'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
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,
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
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.
, 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
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
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
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
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
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
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
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,
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
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
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
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
1 - 100 of 104 matches
Mail list logo
