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 q
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
m
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 Pyg
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)
On Fri, Feb 11, 2011 at 5:01 PM, claudio canepa wrote:
>
>
> On Fri, Feb 11, 2011 at 3:37 PM, amdlintuxo wrote:
>
>>
>>
>> Full code is here:
>> http://bpaste.net/show/13615/
>>
>> Could some one test the full code or provide the idea what can cause
>> sporadic screen blinking.
>> Looking forwar
On Fri, Feb 11, 2011 at 3:37 PM, amdlintuxo wrote:
>
>
> Full code is here:
> http://bpaste.net/show/13615/
>
> Could some one test the full code or provide the idea what can cause
> sporadic screen blinking.
> Looking forwards for you support, i have nothing left to try to
> resolve this problem
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 (ima
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
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
<
pyopengl 3.0 is notoriously difficult to py2exe.
However, I was able to find this page, which suggests a possible
solution:
http://blog.vrplumber.com/index.php?/archives/325-Got-py2exe-+-PyOpenGL-limping-across-the-line...-Need-to-add-the-.egg-files-to-the-path.html
---
James Paige
On Thu, Apr
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 recen
On Fri, Apr 3, 2009 at 2:20 AM, Mike C. Fletcher wrote:
> Peter Gebauer wrote:
>
>> Hi Mike!
>>
>> Will PyOpenGL 3.x be rewritten in the future to use SWIG, Pyrex or
>> Python extensions written in C to improve performance? Is there a
>> possibility
>> of mixing ctypes with Python extensions in C
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 C
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
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
It does: http://www.pyglet.org/doc/api/pyglet.image.Animation-class.html
Though I am not sure of the exact implementation. However that is
easily found 8^)
-Casey
On Mar 22, 2009, at 2:52 AM, Peter Gebauer wrote:
Hi!
Iirc, Pyglet doesn't do animations for textures? That is,
changing the t
Hi!
Iirc, Pyglet doesn't do animations for textures? That is,
changing the texture based on a preset time scale.
/Peter
On 2009-03-19 (Thu) 08:36, Casey Duncan wrote:
> You should check out how pyglet uses VBOs (and vertex arrays as a
> fallback) for its batched sprite engine. It also has some
You should check out how pyglet uses VBOs (and vertex arrays as a
fallback) for its batched sprite engine. It also has some pretty keen
texture atlas support to reduce texture state changes.
-Casey
On Mar 19, 2009, at 8:03 AM, Peter Gebauer wrote:
Hi casey!
Yeh, unfortunately, I haven't f
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 c
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 type
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
Yes, from what I have seen the differences are negligible (the links I found
stated that) a few fps or something.
And the new opengl has support for more features, the old version only goes
to like opengl 1.2 compatibility or something when I last checked.
I would recommend you use the ctypes one
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 wo
why did they not make 3.0 with swig?
On Tue, Mar 17, 2009 at 12:26 PM, RB[0] wrote:
> http://groups.google.com/group/pyglet-users/msg/832b15389fccd28d?pli=1
>
> Hmm, this is a bit outdated, but I found a few other references that say
> SWIG will generally be faster to run, though would have more
http://groups.google.com/group/pyglet-users/msg/832b15389fccd28d?pli=1
Hmm, this is a bit outdated, but I found a few other references that say
SWIG will generally be faster to run, though would have more overhead - so I
dunno.
HTH
On Tue, Mar 17, 2009 at 7:17 AM, RB[0] wrote:
> I saw saw test
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 (wh
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/buil
That's called a texture atlas, but be careful with the mipmaps. They
usually have to be generated specially I think.
http://http.download.nvidia.com/developer/NVTextureSuite/Atlas_Tools/Texture_Atlas_Whitepaper.pdf
On Mon, Mar 16, 2009 at 1:49 PM, Zack Schilling
wrote:
> If someone did this and
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
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
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 e
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
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'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(
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
Hmm, how are you loading your textures - GL_NEAREST or are you using LINEAR
or Mip mapped filtering?
Otherwise, only thing I can think of is you might have a cruddy card that is
dumping some odd functionality to your cpu instead of gpu?
On Thu, Feb 26, 2009 at 1:17 PM, Zack Schilling wrote:
> Tha
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
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
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
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 id
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 wonderin
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 o
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 s
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
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 th
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 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.co
Hmm, thanks, I thought it was a simple solution.
I guess I'd rather cheat and do it as a progress-window kinda thing.
Thanks again for the info.
Astan
René Dudfield wrote:
hi,
You could do this with mesa 3d. I don't think you can do it without
an x server.
You can also draw offscreen with a s
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,
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
--
"For
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 ad
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. I
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
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
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 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:
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 f
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
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,
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
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. (Movi
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):
> > > Fi
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 texture
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
itse
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.
sc
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 w
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 tex
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 f
That would explain weird problems people have had with my code...
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 pairwi
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
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
> sha
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 t
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 ove
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 hav
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 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
Strangely enough, I've never had problems using textures which are not a
standard size. Any idea why?
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
t
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
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 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
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 tha
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 im
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
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 except
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 - surf
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.
>
> T
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 somethi
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 le
On Feb 12, 2008 1:51 PM, Richard Jones <[EMAIL PROTECTED]> wrote:
> On Wed, 13 Feb 2008, René Dudfield wrote:
> > Apart from Richards shameless self promotion of pyglet, here's some
> > other things to look at...
>
> It was more an attempt to dispel the "even in Python" statement :)
>
Can't it be b
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
Apart from Richards shameless self promotion of pyglet, here's some
other things to look at...
Have a look in the Demo directory of pyopengl for many goodies. It's
an often overlooked place of python opengl code.
If you want to render text in 3d: http://ttfquery.sourceforge.net/
soya, openglco
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 = fo
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 whatsoev
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
simp
> 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
1 - 100 of 129 matches
Mail list logo
