Re: [pygame] physics engine?
Heya! It was really too bad that the gsoc project wasn't really finished. It didn't need to be a full 2D physics engine like Chipmunk or Box2D, but in it's current state it is lacking some basic, mandatory features to be useful. I think the collision part should be rewritten to be a part of the PyGame standard collision library. This way you can have traditional rect collisions, pixel based collision detection and vector based testing all in one neet package for PyGame. That collision library would also provide PyGame community with much needed types for vectors, quats and the math surounding it. As for the physics, if you can write a simple platformer it's good enough. Just my two cents. Also, for a good physics library check out PyODE, it now features a 2D joint lock so you can go from 3D to 2D without much effort. /Peter On 2009-06-19 (Fri) 11:57, René Dudfield wrote: On Fri, Jun 19, 2009 at 11:25 AM, machinim...@gmail.commachinim...@gmail.com wrote: hi, what 2d physics engine would you recommend for using with pygame? what happened to the SOC physics project? is it finished? will it be included in pygame? Unfortunately not much work has been done on that since the gsoc last year finished... and no one else has really picked it up. It lives in pgreloaded now. However I don't know of any games using it. Perhaps if it got some users and a maintainer it might improve. I think Marcus might have plans for it, but not sure what they are. Perhaps it might get into pygame 1.9.1... but definitely not 1.9.0. The main engines used by people are these two engines: pybox2d http://pygame.org/project/723/ http://code.google.com/p/pybox2d/ pymunk http://pygame.org/project/780/ http://code.google.com/p/pymunk/ There are a number of successful games using them - and both projects have people working on them, and they seem well maintained. There's also py-lepton, which is a particle library... which does some particle physics stuff, but not really a physics library: (no pygame project page) http://code.google.com/p/py-lepton/ and finally pyode - which is more complex, and seems harder for people to finish games with, but does 3d stuff: (no pygame project page) http://pyode.sourceforge.net/ Also have a look on the pygame website for physics stuff. There's some simple stuff in there, which might be nice to learn from. http://pygame.org/tags/physics cheers,
Re: [pygame] PyGame and SVG
Hi! I'm not sure, but maybe something like OpenVG would be useful? http://www.khronos.org/openvg/ Once you have a OpenVG implementation for SDL/PyGame you have a complete and free API to do vector graphics for games, UI's and what not with (potentially) hardware acceleration specifically for vector graphics. Just FYI. :) /Peter On 2009-05-05 (Tue) 18:47, Daniel Jo wrote: I don't have very much time during the week, but I'll try to get it working in Windows (XP) this weekend. As for OS X, I don't own a system running OS X, so unfortunately there's little that I can do there. . . -Daniel On Tue, May 5, 2009 at 8:48 AM, Bo Jangeborg b...@softwave.se wrote: Do you know if this will be made available for Windows and OS X too ? Bo) Daniel Jo skrev: I was thinking about UIs today and recalled a post by Brad Wardel about the UI in Galactic Civilizations. He mentioned how it would look pretty much the same regardless of the resolution one runs the game at, due to the use of SVG. Presumably, the UI is designed as vector drawings and at runtime rendered to a texture whose size depends upon the current screen resolution. I thought that this would be a great idea for PyGame, but then I found that the only implementation of SVG that exists for PyGame actually uses Cairo. Personally, I think that using Cairo within PyGame is, at best, suboptimum. What you end up with is a whole lot of redundant library that is doing exactly nothing. It would be much better to have a implementation with relatively atomic dependencies. Fortunately, after a bit of googling I discovered SDL_svg. It appears to require only libxml-2.0 and libSDL. Perfect. It also has a very small API. Perfect. After a bit more research I managed to create my own Python bindings using Pyrex. Take a look: http://code.google.com/p/pygame-svg/ -Daniel No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.325 / Virus Database: 270.12.15/2093 - Release Date: 05/02/09 14:23:00
Re: [pygame] pygame.midi
Hi! Yes, I also discovered it's using portmidi. I'll check it and the python bindings for more info, thanks! /Peter On 2009-05-01 (Fri) 08:08, René Dudfield wrote: Hello, it uses portmidi, so best to look at that for capabilities. Also to ask on that mailing list for advanced usage. 1(not sure of capability detection), 3 ,4 I know of to be true. Not sure of 2, or 5. You can download either the source, and build that. Or you can download prebuilt win/mac versions. You should be able to take just the pypm.pyd or pypm.so, and the midi.py... the midi.py might have some dependencies on other parts of pygame. Consider the pypm private, and an implementation detail... it might dissapear to be replaced by a different one later. There's an examples/midi.py with example listing, input and output. The documentation hasn't quite been finished yet, but is mostly done as docstrings in lib/midi.py It's still unfinished, so maybe it will have a few issues and the API may change slightly, but expected to stabalise after the pygame 1.9 release due in approximately 6 weeks. Any bug reports, and patches welcome! cu, On Fri, May 1, 2009 at 12:51 AM, Peter Gebauer peter.geba...@stockholm.bostream.se wrote: Hello! I recently wrote an application for configuration of Akai's USB EWI and I used PyAlsa's (Python extension of Alsa) sequencer API. After tracking down and fixing at least three bugs (most of which concerning segfaults tediously tracked down in gdb) and mailing back and forth the maintainer I realized it would take a lot of time and energy since I have no easy access to apply patches. I also realized porting would be an issue. Enter pygame. So, enough background, here are some questions: I'm sending NRPN's and Sysex's, does the following functionality work in pygame.midi? 1) List connected MIDI devices (if possible with capabilities) 2) Connect duplex (read/write) 3) Send events 4) Read events 5) List active port connections 6) What other dependencies will be added to Linux, OSX and Windows Is it possible to download just the midi module somewhere and build it to work with my current version of pygame (1.8.1-3)? Anybody else interrested in EWI's who might want to add support for their device, maybe we can work it in with my Akai project. /Peter
Re: [pygame] PyGame Website Rewrite
Hello! The two main priorities, imho, would be 1) documentation up to date with code 2) a wiki for additional documentation, examples, build instructions on various platforms, etc. The project content could be easily transfered to wiki too. It might not be better than a full database interface, but it's sufficient and easy to maintain. Also, there are already api doc generators for Python and good wiki's, so no extra code would be written, only a build script for automating the process. As a bonus, if we can generate API docs for specific versions that would be a huge help. /Peter On 2009-04-21 (Tue) 22:38, jug wrote: Hello, Even if it was not selected as a project for GSoC, I would like to do the pygame website rewrite. Like the other applicants, I'd do that with Django. Now that there can not only be one student/participant, it would be cool to work together and combine forces. Since I applied for GSoC, I've already made a small concept. Merging multiple implementing-/design ideas may become difficult, but before I go into detail just say me if you are interested. Regards Jug
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] PHP/MySQL high score server with Python library
Hi! Check out things like XMLRPC. As for the backend server, it's up to the game developer to implement, they can use anything which is way better than locking Python game developers up with PHP and MySQL. Not to mention the fact that online statistics may vary greatly from game to game, I don't see general functionality of this being very useful. Writing this is sort of trivial and, imo, out of the PyGame scope. /Peter On 2009-03-29 (Sun) 16:14, Ian Mallett wrote: This would be really great, I think. A module made out of this that is generic (and maybe a bit documented) would be extremely useful. I, for one, have been trying to find something like this myself.
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] GSoC: Improved Sprite and scene system
Hey Erisvaldo! Your first task would be to summarize all the features that people think is a must have for a scene. I think the sprites could be removed from PyGame, just keep the collision code. Rects need to be float, not int, or have two types, int's won't cut it for more advanced collision math. Then rewrite the collision library to use vectors, calculate penetration depths and support more shapes. That would be well worth the effort and could be reused for the physics engine and any scene manager. I've been meaning to do this for a while, but never able to muster up the strength to do it. :) /Peter On 2009-03-18 (Wed) 21:21, Erisvaldo Junior wrote: Hi, My name is Erisvaldo, I'm 21, graduated in Internet Systems (2006-2008) and last year student of Computer Science at UFPB (Brazil). I have some experiencie with game development, mainly with mobile games (JavaME), but also have used many engines like HGE, Pygame and some 3D ones (Crystal Space, Ogre and Irrlicht). I would like to help improving Sprite system of PyGame and also add a generic scene system to the engine. Is there anyone working on it at the moment? How can I apply for this? If someone could give me some tips of how should I make my proposal I would appreciate. A list of desired features is also appreciated. Thank you all, Erisvaldo Junior. Contact: erisvaldojun...@gmail.com Website: http://erisvaldojunior.com
Re: [pygame] Weird lag
How is collision testing done? 200 sprites tested against 200 sprites
is a big difference from just testing 2-3 sprites against 200, in particular
if you do the iteration in Python.
/P
On 2009-03-01 (Sun) 08:51, Daniel Mateos wrote:
Hey again,
In a 2d scroller game im making i seem to get FPS drops at random
points, i am using the Clock class to keep it at a constant 60 fps and
it never seems to go above 9%-15% cpu usage so im not sure what could be
causing it.
Seems to run well for 90% of the time with spikes that drop the fps to
10-40 at some points in the level, other times it runs fine at exactly
the same points and its not doing anything extra doing these spikes, im
bliting about 100-200 sprites per frame.
Some quick profiler output, doesnt really tell me much tho:
ncalls tottime percall cumtime percall filename:lineno(function)
1233 10.1770.008 10.1770.008 {built-in method tick}
12334.9820.0044.9820.004 {pygame.display.flip}
1536993.2110.0003.2110.000 {method 'blit' of
'pygame.Surface' objects}
5425200.4240.0000.4240.000
game_level.py:129(CheckOnScreen)
12330.4190.0003.8890.003 game_level.py:56(RenderLevel)
4872870.3120.0000.4190.000
game_level.py:105(CheckCollide)
12330.2910.0000.7570.001
game_level.py:122(CheckCollides)
36150.1600.0000.1600.000 {method 'render' of
'pygame.font.Font' objects}
10.1500.1500.1500.150 {pygame.base.init}
10.1260.126 20.979 20.979 main.py:18(module)
4872870.1070.0000.1070.000 {method 'colliderect' of
'pygame.Rect' objects}
10.0930.0930.1210.121 {pygame.display.set_mode}
493258/4930310.0480.0000.0480.000 {len}
40.0480.0120.0480.012
{pygame.imageext.load_extended}
12330.0420.0000.0420.000 {pygame.event.poll}
12330.0400.0000.0960.000 game_osd.py:79(DrawBar)
40.0340.0080.0340.008 {method 'convert' of
'pygame.Surface' objects}
12330.0330.0000.8050.001 game_level.py:44(update)
10.0170.0170.1250.125 __init__.py:25(module)
12330.0160.0000.0410.000 game_osd.py:106(WriteText)
Any help or suggestions for better profileing/tracking down the lag
would be good :)
--
Daniel Mateos
http://daniel.mateos.cc
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
Re: [pygame] Name self not defined
Hi! __new__ returns a new instance of the class while __init__ is simply used to initialize instance variables. Normally you don't bother with __new__ unless you have a particular need (does not happen to often in my experience with Python), some types written in C may require it for deviating signatures of the constructor. Also, I try to make it a rule of thumb to place any superclass calls at the top of the __init__ method, this is useful to get a quick overview of what superclass init's are called, in particular if you have more than one. It's not possible or desirable in 100% of the cases, but I try to do it that way for better readability. Just my personal preference. /Peter On 2009-01-29 (Thu) 09:00, John Eikenberry wrote: Jake b wrote: On Tue, Jan 27, 2009 at 9:18 PM, Yanom Mobis ya...@rocketmail.com wrote: this is the code in question: class Car(Basicsprite): #car class def __init__(self, speedarg=(0,0)): self.speed = speedarg Basicsprite.__init__(self) Is this valid to call parent constructor after other statements? ( Think this is invalid in other languages -- just not sure about python ) Yes. You can call the parents __init__() anywhere in the overridden method. But... __init__() is not the constructor in the traditional sense (as I understand it), it is already passed the constructed instance. In python the constructor is the __new__() method which is passed the class and you must call the superclass' __new__() to get the instance to work with. -- John Eikenberry [...@zhar.net - http://zhar.net] [PGP public key @ http://zhar.net/jae_at_zhar_net.gpg] __ Perfection is attained, not when no more can be added, but when no more can be removed. -- Antoine de Saint-Exupery
[pygame] Events and X
Hi guys! I was writing a quick test that use pygame.key.get_pressed, but had had no window and the keys won't get updated. After browsing the source code for the various event implementations under src/video and looking at the X11 code I realized that the code checks for a focused window before even processing events. Is it impossible to get the X11 input events without a window with the current implementation? Is it possible to get X11 input events without a window in the current X implementation at all? The svga implementation is using ioctl, but I don't really want to venture down that road and reimplement keyboard completely. /Peter
[pygame] Clock.tick() freeze.
Hi! I've tried googling, but came up with nothing. I'm using the Debian testing (AMD64) version of pygame (1.7.1release-4.2), sometimes when Clock.tick() is called the entire Python process will hang, only SIGKILL will actually stop it. Anybody recognize this bug? Is it fixed in later versions? /Peter
Re: [pygame] which Box2D wrapper to use?
Hey Joe. There are also entirely separate engines to choose from. My experience with Box2D is that it's very Microsoftish, I had to edit the header files before being able to build it. The project is mainly maintained and written through some visual stuff, I don't know what. So, just a heads up if you plan on multi platform release. It does run, I'm just saying multi platform targets isn't it strong suite at the moment. I also got an attribute error from Elements' Python code and gave up immediately. (latest tarballs) There's also Chipmunk, another similar library, it too has some Python bindings. Then there's the soon-to-be-in-PyGame library from GSOC, but at this time it lacks much of the functionality you'd come to expect from 2d physics engines. You'll have to see what fits your project best. Oh, you'll be pleasantly surprised to learn that both Box2D and Chipmunk have sort of incredible machine implementations, sandboxes and/or 2d physics toys. Go ahead, build yourself a crazy machine. /Peter On 2008-11-28 (Fri) 20:23, Joe Strout wrote: There appear to be two of them: http://www.pygame.org/project/913/ http://www.pygame.org/project/723/ Any advice as to which one a newbie should choose? Thanks, - Joe
Re: [pygame] which Box2D wrapper to use? additional info
Just wanted to add, I tried Box2D and PyBox2D from SVN trunk, the ladder failed, as do the noobie-style zip-file (Warning! no root directory included) that is the downloadable tarball. Like I said, it's all Windows on this one or major headache. The various buildscripts interpret environment compiler flags differently and there's a far share of warnings before gcc croaks. /Peter
Re: [pygame] Linux binaries
Hey there! There are some alternatives, some like automatic generation like Swig, Boost, etc, some like Pyrex, I prefer to write Python extensions in C using the standard Python C-implementation API. PyGame, being written in C, is also easy to access. As for C++, I don't know of any specific C++ API's, but then again I don't use C++ at all so I haven't looked. There's also the option of doing the reverse scenario, embedding instead of extending, you'll have to see what fits your project best. /Peter On 2008-11-05 (Wed) 08:29, Matt Pearson wrote: i agree, does the wrapper have a name, or is it on the python/pygame sites On Wed, Nov 5, 2008 at 8:13 AM, René Dudfield [EMAIL PROTECTED] wrote: yeah, best to use both! Use each tool where it is best at - and get best of both worlds! cu, On Thu, Nov 6, 2008 at 12:53 AM, Peter Gebauer [EMAIL PROTECTED] wrote: Hi guys! I agree, just wanted to add that many iterations over trivial code benefits (speed-wise) tremendously from being written in C and accessed in Python, or at least that is my experience. :) Guess you have to weigh it against the added complexity of having to compile C code, maybe for mulitple platforms, etc. On 2008-11-05 (Wed) 13:57, Greg Ewing wrote: Patrick Mullen wrote: On Tue, Nov 4, 2008 at 12:55 AM, Greg Ewing [EMAIL PROTECTED] wrote: The only way to improve speed is to re-code the cpu-intensive parts using something more efficent, such as C or Pyrex. Or, of course, write better python code if possible in those parts. Yes, certainly -- finding a better algorithm is always the best form of optimization! -- Greg
Re: [pygame] Linux binaries
Hi guys! I agree, just wanted to add that many iterations over trivial code benefits (speed-wise) tremendously from being written in C and accessed in Python, or at least that is my experience. :) Guess you have to weigh it against the added complexity of having to compile C code, maybe for mulitple platforms, etc. On 2008-11-05 (Wed) 13:57, Greg Ewing wrote: Patrick Mullen wrote: On Tue, Nov 4, 2008 at 12:55 AM, Greg Ewing [EMAIL PROTECTED] wrote: The only way to improve speed is to re-code the cpu-intensive parts using something more efficent, such as C or Pyrex. Or, of course, write better python code if possible in those parts. Yes, certainly -- finding a better algorithm is always the best form of optimization! -- Greg
Re: [pygame] pixel-perfect physics?
Once the PyGame physics module supports other shapes and collision callbacks it would be easy to first do the regular AABB test and then do a mask collision test. As for the physics, I'm not sure the GSOC project will ever include support for adding custom contact points, etc, but it seems like a collision joint on the colliding pixels would be in order. However, all this would be akward and quite cpu expensive since in modern games, both in graphics and physics, shapes are in and pixels are out. /Peter On 2008-10-26 (Sun) 10:04, Nirav Patel wrote: Certainly not an easy problem, especially if the shapes are convex. A sort of hackish way to do this in PyBox2D, if the shapes aren't already known polygons, is to use Mask.outline() to get some points on the outline of your object and create a Box2D Poly out of a bunch of thin connected rects shaped like your object. This is a really bad description, but check out this thread: http://www.box2d.org/forum/viewtopic.php?f=8t=563 . Elements, a wrapper for PyBox2D, has functions similar to this written that you may also want to look at. Take a look at complexPoly and concavePoly in http://dev.laptop.org/git?p=activities/physics;a=blob;f=elements/add_objects.py;h=3842b750a8dfe46d9400bab1c6ff5d6206dc718f;hb=HEAD This still isn't pixel perfect, but accurate physics and pixel perfect collision do not go together. Nirav On Fri, Oct 24, 2008 at 4:50 PM, Michael George [EMAIL PROTECTED] wrote: Has anyone had experience using pixel-perfect collision detection with a 2d physics engine? I've looked into pymunk, but that seems to have baked-in collision detection so I don't see how to do it. ODE has rudimentary python bindings and has separate collision detection, but it's intended for 3d and the 2d support hasn't been added to the python port yet. There's the GSOC pygame physics project, but I don't see docs for that and can't tell if it would be suitable. Also, as far as doing the collision detection, AFAICT there isn't a way to rotate a mask, or to do collision detection on rotated objects. Are there plans for something like this, or am I stuck with using an image, rotating it with the transform package and then using Mask.from_surface? Thanks. --Mike
Re: [pygame] Physics, collision detection etc?
Hi Niki! Yes I have, a well a Box2D for Python. Neither or Python extensions and neither will be a permanent part of PyGame. There's already a cool physics module part of PyGame, I'll try to see if we can extend it's API further. /Peter On 2008-10-14 (Tue) 10:59, niki wrote: Peter Gebauer wrote: Hello Ian! Nice code! I was thinking of exposing some of the code Zhang Fan wrote for the physics engine, but as of yet it only handles rectangles. There's plenty of code available on the net, but I feel reluctant to produce yet another Python extension for PyGame. I'll continue to check for reusing already existing projects, most likely fast C code that can be easily used to extend Python functionality. Have you tried pymunk? Niki
Re: [pygame] Physics, collision detection etc?
Yo René! Indeed, it would be nice to see a Python extension for this. I still think it'd be nice to use Zhang Fan's wonderful code, it has the basic concepts there, just needs that extra to become a collision testing library as well. From what I understand from Zhang Fan the plan was to provide full collision testing capabilities, but there wasn't any time left. Before the wishlist grows too large, let's just see if we can summarize what functions are needed for polygon and plane tests. /Peter On 2008-10-10 (Fri) 07:10, René Dudfield wrote: hi, it'd be cool if we also had a good kdtree implementation for spatial stuff too :) For cases when we had say 1000 objects or so. note, the wikipedia entry has a basic implementation in python http://en.wikipedia.org/wiki/Kd-tree There's also some quadtree python code lying around if you needed it(see cookbook). However, maybe even a simple grid will be better for you. cu, On Fri, Oct 10, 2008 at 2:46 AM, Peter Gebauer [EMAIL PROTECTED] wrote: Hello René. The thing is, in a large world spanning 16000x1 pixels that will be a huge mask. Even if I reduce the resolution of the mask alone it will be either top inprecise or still too large. I don't want to write for OpenGL alone even though the plan is to use OpenGL as test output. My plan is to build a large world of 3 or 4-sided convex polygons that could be used to detect colliding with large shapes in that world. The best way to do this is probably to expose some of Zhang Fan's physics code, much of the math involved is already there, it just lacks non-rectangular shapes and a nice Python API to access it. /Peter On 2008-10-09 (Thu) 11:41, René Dudfield wrote: hi, Note, that you can find contact normals with the mask module. See mask example. For some types of games, per pixel collision detection is fast enough. It uses rect bounding boxes as a first pass, so mostly it's not much slower than rect collision detection. Assuming you are working in 2d, and you cache the mask(not regenerating it every frame) that is. However the mask.from_surface routine is fairly fast, it could do with some more optimization. For opengl, it'd be interesting to do it in a shader too... since then you could just reuse your drawing routines to draw your objects(sprites) into a buffer (each with a different color), then use a shader to find all of the contact normals. That way your collision could be pixel perfect, even with different methods of drawing(cartoon, glow, and other shaders) where the polygon representation is not correct. cheers, On Wed, Oct 8, 2008 at 9:46 PM, Greg Ewing [EMAIL PROTECTED] wrote: Nirav Patel wrote: If the polygons are Surfaces or can be turned into Surfaces, they can be turned into Masks to do pixel collision. On Tue, Oct 7, 2008 at 11:21 AM, Peter Gebauer [EMAIL PROTECTED] wrote: Yep, but as I said, I need to find colliding polygons, not pixels. Pixel collision isn't suitable for all purposes, e.g. if you need to find contact normals for physics calculations.
Re: [pygame] Physics, collision detection etc?
Hello René. The thing is, in a large world spanning 16000x1 pixels that will be a huge mask. Even if I reduce the resolution of the mask alone it will be either top inprecise or still too large. I don't want to write for OpenGL alone even though the plan is to use OpenGL as test output. My plan is to build a large world of 3 or 4-sided convex polygons that could be used to detect colliding with large shapes in that world. The best way to do this is probably to expose some of Zhang Fan's physics code, much of the math involved is already there, it just lacks non-rectangular shapes and a nice Python API to access it. /Peter On 2008-10-09 (Thu) 11:41, René Dudfield wrote: hi, Note, that you can find contact normals with the mask module. See mask example. For some types of games, per pixel collision detection is fast enough. It uses rect bounding boxes as a first pass, so mostly it's not much slower than rect collision detection. Assuming you are working in 2d, and you cache the mask(not regenerating it every frame) that is. However the mask.from_surface routine is fairly fast, it could do with some more optimization. For opengl, it'd be interesting to do it in a shader too... since then you could just reuse your drawing routines to draw your objects(sprites) into a buffer (each with a different color), then use a shader to find all of the contact normals. That way your collision could be pixel perfect, even with different methods of drawing(cartoon, glow, and other shaders) where the polygon representation is not correct. cheers, On Wed, Oct 8, 2008 at 9:46 PM, Greg Ewing [EMAIL PROTECTED] wrote: Nirav Patel wrote: If the polygons are Surfaces or can be turned into Surfaces, they can be turned into Masks to do pixel collision. On Tue, Oct 7, 2008 at 11:21 AM, Peter Gebauer [EMAIL PROTECTED] wrote: Yep, but as I said, I need to find colliding polygons, not pixels. Pixel collision isn't suitable for all purposes, e.g. if you need to find contact normals for physics calculations.
Re: [pygame] Physics, collision detection etc?
Hi again Nirav! Yes, but the number of pixels involved makes it too time consuming. Also, I'll be using OpenGL to render the polygons which means I have to copy the pixels to RAM or use occlusion tests, neither of which are optimal. /Peter On 2008-10-07 (Tue) 15:03, Nirav Patel wrote: Peter, If the polygons are Surfaces or can be turned into Surfaces, they can be turned into Masks to do pixel collision. Though, I may be misunderstanding what you are trying to do. Nirav On Tue, Oct 7, 2008 at 11:21 AM, Peter Gebauer [EMAIL PROTECTED] wrote: Hey Nirav! Yep, but as I said, I need to find colliding polygons, not pixels. /Peter On 2008-10-06 (Mon) 12:05, Nirav Patel wrote: Peter, There are some new functions in SVN in the mask module. New ones since 1.8.1 that could be useful for collision are: Mask.overlap_mask - Returns a mask of the overlapping pixels Mask.draw - Draws a mask onto another Mask.erase - Erases a mask from another Mask.count - Returns the number of set pixels Mask.centroid - Returns the centroid of the pixels in a Mask Mask.angle - Returns the orientation of the pixels Mask.connected_component - Returns a mask of a connected region of pixels. The mask module does pixel collisions pretty quickly. I think on modern systems it shouldn't be a significant difference (compared to say, blitting) between using pixel perfect detection and something like the seperating axis theorem. Nirav On Mon, Oct 6, 2008 at 11:27 AM, Peter Gebauer [EMAIL PROTECTED] wrote: Hey guys! I've been looking around for various libraries that handle intersection/colliding polygons/line segments, I'm just wondering if/when there will be polygon shapes and additional collision testing functions that can be used seemlessly with the old rect and mask libraries that already exist in PyGame? /Peter
Re: [pygame] Physics, collision detection etc?
Hello Ian! Nice code! I was thinking of exposing some of the code Zhang Fan wrote for the physics engine, but as of yet it only handles rectangles. There's plenty of code available on the net, but I feel reluctant to produce yet another Python extension for PyGame. I'll continue to check for reusing already existing projects, most likely fast C code that can be easily used to extend Python functionality. /Peter On 2008-10-07 (Tue) 12:17, Ian Mallett wrote: I once wrote a program which collides a point and a convex polygon, returning a boolean result. http://pygame.org/project/649/ This project uses it, for instance. It may be of help.Ian
Re: [pygame] Physics, collision detection etc?
Hey Nirav! Yep, but as I said, I need to find colliding polygons, not pixels. /Peter On 2008-10-06 (Mon) 12:05, Nirav Patel wrote: Peter, There are some new functions in SVN in the mask module. New ones since 1.8.1 that could be useful for collision are: Mask.overlap_mask - Returns a mask of the overlapping pixels Mask.draw - Draws a mask onto another Mask.erase - Erases a mask from another Mask.count - Returns the number of set pixels Mask.centroid - Returns the centroid of the pixels in a Mask Mask.angle - Returns the orientation of the pixels Mask.connected_component - Returns a mask of a connected region of pixels. The mask module does pixel collisions pretty quickly. I think on modern systems it shouldn't be a significant difference (compared to say, blitting) between using pixel perfect detection and something like the seperating axis theorem. Nirav On Mon, Oct 6, 2008 at 11:27 AM, Peter Gebauer [EMAIL PROTECTED] wrote: Hey guys! I've been looking around for various libraries that handle intersection/colliding polygons/line segments, I'm just wondering if/when there will be polygon shapes and additional collision testing functions that can be used seemlessly with the old rect and mask libraries that already exist in PyGame? /Peter
[pygame] Physics, collision detection etc?
Hey guys! I've been looking around for various libraries that handle intersection/colliding polygons/line segments, I'm just wondering if/when there will be polygon shapes and additional collision testing functions that can be used seemlessly with the old rect and mask libraries that already exist in PyGame? /Peter
Re: [pygame] The gsoc project physics engine, some issues?
Hey all! I wondered if the these two issues will be addressed? 1) The fact that heavy mass objects fall through static objects with low mass. Static objects should probably be treated like inf mass. (it's as if they first hit water and then slowly sink through) 2) Locked joint rotation. There should be a way to make sure that joints do not rotate. 3) Round shapes. 4) Callbacks. Is there any way to override the default behavior of a collision? It could be a simple Python method override where the method accepts the new body paramaters (velocities, etc). 5) Open polygon (i.e walls). A lot of 2D physics engines support walls, single, blocking lines in a sequence. It's not necessary, but sure would be nice to have an open polygon shape for collision testing. An additional inquiry about collisions, is there a way to test for collisions without running the simulation? It would be very nice to have the collision code for shapes avaialable for use in games even without the physics simulation going on. That's it for now. :) /Peter
Re: [pygame] Sprite Code
Hi!
I use a horizontal sheet and just blit a rect with a horizontal offset and
then some code to advance through the frames. I was thinking of rewriting my
code as a pygame C extension, but I can't find the time. People have all
sorts of solutions, but they are all similar so maybe some animation could
find it's way into the pygame library. I'd use specific types to define the
animation frames and frame list instead of dicts and lists.
/Peter
On 2008-08-19 (Tue) 14:46, kschnee wrote:
I've been looking at my sprite code again and finding a different way than
I'd used for loading animation frames. That is, Pygame.sprite doesn't seem
to have any way to set up the notion of having multiple frames, and my old
method involved loading a single sprite sheet image and finding a set of
rect objects refering to sections of the sprite sheet.
What I'm doing lately involves looking in a graphics directory
(\graphics\sprites) for text files, loading some info from those, and using
them to define the rects to be used from a sprite sheet image. The input is
some simple text files and the images. The output is a dictionary that
looks like this (for a sheet called guy having 4 rows of a 3-frame
walking animation):
{guy:
{frame_size:(96,128),image:surface 388x512,
animations:{ stand:[ (45,[(0,0,96,128),(96,0,96,128)]) [...] ]}
}
}
...Well, something like that! Anyway it's listed by sprite, then by
animation name (like stand), then by some angle that's used to determine
which frames to use based on the character's facing direction, and finally
as a list of rects marking the individual animation frames. (An alternative
method might be to use the text files just to say things like walk =
frames 0,1,2,3 and then automatically load frames by number only and trust
the program using this code to know how to use them.) With this code you
should be able to auto-load all sprite data on startup and then, for any
movement angle, look up which frames to cycle through.
Any interest in this code? What methods do you use to get your sheet
together?
Re: [pygame] Physics module status note, more things...
Hey there, Greg! Yep, I did a test implementation of both drag and bouyancy and it looked nice, but had a bad flaw: it didn't take not of contact points. Granted, contact points aren't important when the object is fully submerged, but once on the surface it's needed to calculate displacement and rotational velocity. In my experiment the boxes floating on top of water would be tilted the angle they had when rotation was stopped (due to drag). So, even though my test looked good under water it sucked when floating. I wasn't sure how to overcome this problem so I scrapped it all until someone more capable than me takes a look at it. Here's a few things that might be useful to anybody who has a go with this: 1) Drag is calculated using the fluid viscosity and the surface area exposed in the linear velocity direction, i.e the surface that hits the water head on. Drag is applied in direct opposite to the linear velocity and may be equal to linear velocity (like with viscoisity 1.0, i.e solid), but never more. (just keeping it simple) You might also want to take in account the body friction of the solid, maybe you're making a shaved vs hairy swimmers game? :) 2) Bouyancy is calculated using standard displacement, but for 2D instead of 3D, basically density * area. Density is mass / area. The way I solved this was to be practical. To make things easy I decided that the area would remain if density or mass was changed, just so I, as a game programmer, didn't have to do any density or mass calculations in game code. body.mass = 100 # set density to mass / area, area remains the same body.density = 10 # set mass to density * area, area remains the same body.shape.size = 50,50 # sets mass to density * area, density remains This solved a lot of problems, but I had to add width and height to the shape or reverse the rotational transformation, this needs to be solved nicer. Maybe cache width and height in the shape? This worked great aside from the fact that the whole area was used instead of calculating the submerged area only. This will be vital for correct floating. If someone who is more capable would have go at implementing viscosity support and rudimentary support for netwonian fluid bodies I think it can be done with ease and without disrupting the current implementation of solids too much. I definately think this is the more simple and usable way to do it than adding general dampers to the world or single bodies. I think this would be very useful for making games, maybe the characters will finally float instead of dying when hitting water? :) /Peter On 2008-08-18 (Mon) 13:17, Greg Ewing wrote: Peter Gebauer wrote: In our simple simulation a constant drag force applied in opposite to gravity should be sufficient No, that won't work, because the object will still accelerate indefinitely, or decelerate until it stops completely, whereas it should reach some terminal velocity. we don't have to take in account all the other details of non-solid friction. It doesn't have to be complicated, just a force proportional to the velocity of the object, with a coefficient depending on the fluid and the object concerned. -- Greg
Re: [pygame] Physics module status note, more things...
Hi again, Greg! I agree that it needs a new attribute, but it's gravity that makes mass continue down, not the sudden loss of drag. In our simple simulation a constant drag force applied in opposite to gravity should be sufficient, we don't have to take in account all the other details of non-solid friction. Naturally, just like in real life the drag force cannot exceed the force pulling it down, i.e gravity. A drag force equal to gravity would be considered solid, anything below make it sink very slow or very fast depending on viscosity. I'm experimenting with something now that simulates viscosity using the extra attribute viscosity where 0.0 is vacuum and 1.0 is a solid. What happens in zero gravity is that the drag actually will stop the bodies at some point given enough time in the netwonian fluid unless other forces are applied. I haven't started experimenting with bouyancy yet, that will be done in a separate step and involves only already existing attributes (mass and, normally volume, but for us area), but I'm thinking of adding density as an extra attribute, I'll get into detail on this once I have viscosity working. The one thing I have not been able to do yet is properly reduce rotation velocity, if an edge hits the water with enough speed it should roll on the surface until the drag has reduced it to zero. There's all sorts of odd circumstances that doesn't have to work. The normal case is having a huge area with water with a large mass. A smaller solid object falls into and penetrates the water, but consider the other way around; Small fluid objects hitting a large solid, in particular statics, will seem to sink into the solid, this behavior does not work or look like rain hitting pavement, for example. I think this is a fair trade-off for the 99% of the time scenario where solids and non-solids hit large areas of static non-solids. I could even go as far as to decide that all non-solids are considered static in our little pretend universe, just because that is how they will mostly be used. Other simulations will require enhancement outside the scope of simple game creation. /Peter On 2008-08-17 (Sun) 11:40, Greg Ewing wrote: Peter Gebauer wrote: Great point, I was thinking about using the friction attribute to achieve this, but maybe something like viscosity is better to calculate drag? A separate parameter would probably be better, since unlike friction between solid surfaces, the drag force has to be velocity-dependent -- otherwise the object would slow down and stop somewhere in the fluid instead of reaching a terminal velocity. -- Greg
Re: [pygame] Physics module status note, more things...
Hi Zhang! I'm experimenting with drag based on the non-solid object instead of setting a damper to each body or the world. I'll check bouyancy when drag is done, it requires more calculations to compare mass and area (displacement), but drag will be a factor here too. I'm working on integrating this without changing the existing collision behavior for minimum changes. /Peter On 2008-08-17 (Sun) 13:34, 帆 张 wrote: Hi, Nice idea and suggestion! Thank you. First, 3. Algorithm For particle simulation *DONE*** in TODOLIST is a step in todolist of previous coding phase. particle simulation is very simple and implemented at beginning(not need to consider shape and constraint). Second, in fact, air friction has already been added by a simple damping algorithm (body.linear_vel_damping and body.angle_vel_damping). I also add a new test case (test5.py), it's a chain simulation with damping of velocity enabled. you can compare it with test4.py. :-) Best wishes Zhang Fan Peter Gebauer [EMAIL PROTECTED] 写道： Sweet! I have a new question as well. :) From the todo: 3. Algorithm For particle simulation *DONE*** What is it? Bodies with a single point shape? I've already done a dozen experiments with the latest svn updates, everything looks excellent so far. I'm really impressed with Zhang Fan's effort. Your assistance is also appreciated. Good work guys! I see in the quote the issue of falling through other bodies, it is relevant to the fluid discussion as well. It would probably prove valuable to have friction in air as well simply to get a terminal velocity. I'm working on a fluid solution that would intergate nicely with solids, this still involves changing the behavior of a collision between two bodies. From what I've gathered, implementing a rudementary dynamic viscosity for netwonian fluids based on friction (or a separate attribute for viscosity where 0.0 is vacuum and 1.0 is a solid) wouldn't be that hard. /Peter On 2008-08-15 (Fri) 15:33, [EMAIL PROTECTED] wrote: Peter Gebauer : Hi again! Should have waited with my previous post, but here's a few things I don't understand: 1) if the mass of a static body is under 1.0 it behaves as a semi-solid, is this intentional? (i.e other bodies fall into the static body and with mass reaching 0.0 they fall right through) In test3.py, set the static body mass to 0.1, as an example. This is due to the fact, that the current collision algorithm is not a CCD method. Thus the collision detection highly depends on the step time, size and speed of a body. Other systems, which do not implement a CCD, suffer from the same issue. Zhang Fan wrote a lot about that in pgShapeObject.c. In order to get rid of that, you have to choose matching step times, sizes and the speed for bodies according to your simulation needs - at least as long as there is no CCD algorithm implemented :-). 2) is there a way to get simulated bouncing? If there was a way to describe how much energy the object retains (in new direction) after collision, a float between 0.0 and 1.0 (0-100% energy retained, 0.01 would be a rock and 0.5 would be more of a tennis ball)? Simulated bouncing is implemented already. The collision energy, and how it is applied on the colliding bodies, depends on the restitution set for them. So, whether you will receive an elastic or inelastic collision, depends on that factor. A quick search for Coefficient of restitution and elastic collisions will provide you tons of explanations and even some values for different materials. Attached you'll find a small bouncing test script. 3) can we add bouyancy? :) Body 1 is called floater and Body 2 is called water, if floater is inside water it should, depending on it' displacement, either pop back up or sink to the bottom. We would be able to calculate this with the already existing shape, mass and friction attributes, but it would probably require a new boolean attribute, maybe solid? Here's how I'd do it. * create a World with relatively high damping, the gravity vector points to the top (e.g. world.gravity = 0, -3). * place body into that world with a certain damping, mass, etc. * have fun watching the simulation. Limiting the world's area would be left to the user. As you can have multiple worlds, which behave completely different, you could e.g. split the screen into sky and sea, being two different worlds. If the body reaches a certain point, you could remove it from sea and add it to sky (which reminds of adding remove_* methods, so wait 'til the end of the weekend before doing that ;-). Simulating a varying density of the world would require a slightly different approach for worlds. Currently the world does not know anything about its size and such, that however would be necessary, I think. Regards
Re: [pygame] Physics module status note
Hi there, Hugo! Yes, using radians in math-related softare is common, but not in games. It will simply add a call the math.degrees for every call and to increment the angle you'd have to convert it back, or be forced to use radians in the game. If you're drawing using OpenGL or any rotational transformations it will be a lot of calls. I see it as more comfortable when the angles use degrees since graphic drawing is more common than in a game than asin/atan calls. It will also be a miniscule performance enhancenment to do this in C rather than Python which will add up if you do this conversion many times for each polygon you draw. :) So, it's more comfortable to use degrees and it's better suited for use with graphic libraries, which mostly use degrees, including pygame.transform.rotate. /Peter On 2008-08-15 (Fri) 15:39, Hugo Arts wrote: most of python's math functions like asin en atan (from math) return their values in radians, and sin and tan take their arguments as radians. So using radians is more common than degrees. Conversion is also pretty trivial, using math.radians and math.degrees. Hugo On Fri, Aug 15, 2008 at 6:53 AM, Peter Gebauer [EMAIL PROTECTED] wrote: Hi! Hm, I've been experimenting a bit now and I wonder about the body.rotation, it's using radians. Wouldn't it make more sense to use degrees in the API for all angle values? On 2008-08-14 (Thu) 21:35, Marcus von Appen wrote: On, Thu Aug 14, 2008, Peter Gebauer wrote: [...] Too early for a wishlist? :) No, but do not expect it to be implemented within the next days ;-). We'd be happy to discuss and put your wishes on the TODO list. Regards Marcus
Re: [pygame] Physics module status note, more things...
Hey Greg! Man, everybody in this list are so responsive, I like it. You'll also want a drag force proportional to the velocity of the body and the immersed volume, to stop it from accelerating indefinitely while submerged, and to damp down oscillations when it's floating on the surface. Great point, I was thinking about using the friction attribute to achieve this, but maybe something like viscosity is better to calculate drag? Or is viscosity based on friction? Gotta Wikipedia this. If we could add this attribute (calling it viscosity, just for the sake of argument) to both worlds and bodies you can get terminal velocity for air, water and whatever non-solids you might like to simulate. It would also make sure that projectiles slow down faster in water. If you want a fancy version you could include surface area in the drag calculation. /Peter
Re: [pygame] Physics module status note, more things...
Sweet!
I have a new question as well. :)
From the todo: 3. Algorithm For particle simulation *DONE***
What is it? Bodies with a single point shape?
I've already done a dozen experiments with the latest svn updates,
everything looks excellent so far. I'm really impressed with Zhang Fan's
effort. Your assistance is also appreciated. Good work guys!
I see in the quote the issue of falling through other bodies, it is relevant
to the fluid discussion as well. It would probably prove valuable to have
friction in air as well simply to get a terminal velocity.
I'm working on a fluid solution that would intergate nicely with solids,
this still involves changing the behavior of a collision between two bodies.
From what I've gathered, implementing a rudementary dynamic viscosity for
netwonian fluids based on friction (or a separate attribute for viscosity
where 0.0 is vacuum and 1.0 is a solid) wouldn't be that hard.
/Peter
On 2008-08-15 (Fri) 15:33, [EMAIL PROTECTED] wrote:
Peter Gebauer [EMAIL PROTECTED]:
Hi again!
Should have waited with my previous post, but here's a few things I don't
understand:
1) if the mass of a static body is under 1.0 it behaves as a semi-solid,
is this intentional? (i.e other bodies fall into the static body and with
mass reaching 0.0 they fall right through)
In test3.py, set the static body mass to 0.1, as an example.
This is due to the fact, that the current collision algorithm is not a CCD
method. Thus the collision detection highly depends on the step time, size
and speed of a body. Other systems, which do not implement a CCD, suffer from
the same issue. Zhang Fan wrote a lot about that in pgShapeObject.c.
In order to get rid of that, you have to choose matching step times, sizes
and the speed for bodies according to your simulation needs - at least as
long as there is no CCD algorithm implemented :-).
2) is there a way to get simulated bouncing? If there was a way to describe
how much energy the object retains (in new direction) after collision, a
float between 0.0 and 1.0 (0-100% energy retained, 0.01 would be a rock and
0.5 would be more of a tennis ball)?
Simulated bouncing is implemented already. The collision energy, and how it
is applied on the colliding bodies, depends on the restitution set for them.
So, whether you will receive an elastic or inelastic collision, depends on
that factor. A quick search for Coefficient of restitution and
elastic collisions will provide you tons of explanations and even some
values for different materials.
Attached you'll find a small bouncing test script.
3) can we add bouyancy? :) Body 1 is called floater and Body 2 is called
water, if floater is inside water it should, depending on it'
displacement, either pop back up or sink to the bottom. We would
be able to calculate this with the already existing shape, mass and friction
attributes, but it would probably require a new boolean attribute, maybe
solid?
Here's how I'd do it.
* create a World with relatively high damping, the gravity vector points to
the top (e.g. world.gravity = 0, -3).
* place body into that world with a certain damping, mass, etc.
* have fun watching the simulation.
Limiting the world's area would be left to the user. As you can have multiple
worlds, which behave completely different, you could e.g. split the screen
into sky and sea, being two different worlds. If the body reaches a
certain point, you could remove it from sea and add it to sky
(which reminds of adding remove_* methods, so wait 'til the end of the
weekend before doing that ;-).
Simulating a varying density of the world would require a slightly
different approach for worlds. Currently the world does not know anything
about its size and such, that however would be necessary, I think.
Regards
Marcus
# The python file is under test
import pygame
import physics
from pygame.locals import *
def render_body(body,surface,color):
l = body.get_points()
pygame.draw.polygon(surface,color,l)
def render_world(world,surface,color):
for body in world.bodies:
render_body(body,surface,color)
def init_world():
w = physics.World()
w.gravity = 0, 2
body1 = physics.Body()
body1.shape = physics.RectShape(30, 28, 0)
body1.position = 400, 40
body1.rotation = i
body1.restitution = 0.9
body1.mass = 20
w.add_body(body1)
body2 = physics.Body()
body2.shape = physics.RectShape (760, 20, 0)
body2.position = 400, 600
body2.restitution = 1.0
body2.mass = 1e100
body2.static = True
w.add_body(body2)
return w
def main():
this function is called when the program starts.
it initializes everything it needs, then runs in
a loop until the function returns.
#Initialize Everything
pygame.init()
screen = pygame.display.set_mode((800, 800))
pygame.display.set_caption('physics test
Re: [pygame] Physics module status note
Hi! Hm, I've been experimenting a bit now and I wonder about the body.rotation, it's using radians. Wouldn't it make more sense to use degrees in the API for all angle values? On 2008-08-14 (Thu) 21:35, Marcus von Appen wrote: On, Thu Aug 14, 2008, Peter Gebauer wrote: [...] Too early for a wishlist? :) No, but do not expect it to be implemented within the next days ;-). We'd be happy to discuss and put your wishes on the TODO list. Regards Marcus
Re: [pygame] Physics module status note, more things...
Nice reply Marcus! In order to get rid of that, you have to choose matching step times, sizes and the speed for bodies according to your simulation needs - at least as long as there is no CCD algorithm implemented :-). Right. Simulated bouncing is implemented already. The collision energy, and how it is applied on the colliding bodies, depends on the restitution set for them. All these fancy english words. :) Here's how I'd do it. * create a World with relatively high damping, the gravity vector points to the top (e.g. world.gravity = 0, -3). * place body into that world with a certain damping, mass, etc. * have fun watching the simulation. The wold would need more than just a size, it would need a position as well, but it'd be very difficult to do body transitions between the worlds anyway. I think it'd be easier to change the behavior of a body that is inside another body. Of course, the fluid body wouldn't be fluid, it would simply apply an force (opposite to gravity) based on the displaced mass, but that would be enough to simulate an ocean surface or pockets of contained fluids. As I see it there would be three things to consider: the inverse of gravity, displaced mass and friction. I'm not sure about friction, because it would involve surface area calculations, but some estimation ;) of it will do. I don't have a clue about the math involved to calculate the force, but I could give it a stab. Simulating a varying density of the world would require a slightly different approach for worlds. Currently the world does not know anything about its size and such, that however would be necessary, I think. I still think doing it per body is easy enough and would have more use cases. It would be a rough estimation of water, but it'd work for what this library is intended to do, One final question: is it possible to lock joint rotation (no rotation)? /Peter
Re: [pygame] Physics module status note
as I think, there are some more people interested in the status of the physics module (especially Peter :-), Zhang Fan works on, here's a short note about its current state. What has been accomplished so far? * World support is fully implemented * Body support is fully implemented * Joint support is fully implemented including recently added revolute joints * Shape support is implemented with AABB collision detection and rectangular shape support Woohoo! Naturally, I've been following the SVN updates closely so I knew this already ;), but it's a great opportunity for the rest of the community to try it. I'm anxious to find out what others think about it. Too early for a wishlist? :) /Peter
Re: [pygame] The gsoc physics module, bug fixing?
Hi Zhang Fan! Updated from SVN and tested the new Python joint test, very cool indeed. Nice to see the project grow into a working module. Just wanted to let you know I appreciate your work! Looking forward to making a test/example game using it. :) /Peter On 2008-07-09 (Wed) 20:48, 帆 张 wrote: Hi Peter, Thanks for your careful attention to my works :-) I use OpenGL just for testing physics algorithms in C because this's no need for python wrapper, I can focus more on finishing algorithms first. Of course, finally, this testing method will be abandoned, which means glut is no need to link. Currently I start with some works about python wrapping, and I finished some codes and extended some basic functions for python wrapping. The python test file test1.py is being under test, and there are some bugs in python wrapping. I plan to publish my work to the community when these basic works have been done. Best wishes Zhang Fan Peter Gebauer [EMAIL PROTECTED] 写道： Hi guys! I noticed a lot has happened, but very little communication here, is everything going alright? :) There's a new test1.py suggesting there would be Python side testing available, but I keep getting ImportError: ./build/lib.linux-x86_64-2.5/physics.so: undefined symbol: glutBitmap9By15 when trying to import the physics module. Is it necessary to link glut (or whatever is needed) to test? Or should I just hold my horses and settle down for a while longer? /Peter On 2008-06-29 (Sun) 15:30, Marcus von Appen wrote: On, Sun Jun 29, 2008, Peter Gebauer wrote: Hi Zhang and others! [Python wrapper issues] The wrapper implementation is not really started yet, so it's a bit early. In order to keep argument parsing flexible, I'd recommend using METH_VARARGS and PyArg_ParseTuple() instead of the _0, ... macros. This let's one easily enhance anything without the need to change too much code. Additionally you can let the parser handle argument checking without the need to deal with ex- or implicit object conversions. Regards Marcus - 雅虎邮箱，您的终生邮箱！
Re: [pygame] The gsoc physics module, bug fixing?
Hi Marcus! Yep, it seems to work fine. Perhaps you could explain why vectors are represented as complex? When trying to get position, how does one get the horizontal and vertical coordinates from the complex? /Peter On 2008-07-20 (Sun) 18:11, Marcus von Appen wrote: On, Thu Jul 10, 2008, Peter Gebauer wrote: Hi Zhang and Marcus! Thanks for your careful attention to my works :-) I follow your repos updates on a daily basis, it's fun to watch it grow and become a Python module. Perhaps tests can have a separate build target and not link glut/gl to the physics.so file? Just a short notice, that anything should be fine again in rev. 1523. The OpenGL stuff was removed. Regards Marcus
Re: [pygame] The gsoc physics module, bug fixing?
Hi Zhang and Marcus! Thanks for your careful attention to my works :-) I follow your repos updates on a daily basis, it's fun to watch it grow and become a Python module. Perhaps tests can have a separate build target and not link glut/gl to the physics.so file? /Peter
Re: [pygame] The gsoc physics module, bug fixing?
Hi guys! I noticed a lot has happened, but very little communication here, is everything going alright? :) There's a new test1.py suggesting there would be Python side testing available, but I keep getting ImportError: ./build/lib.linux-x86_64-2.5/physics.so: undefined symbol: glutBitmap9By15 when trying to import the physics module. Is it necessary to link glut (or whatever is needed) to test? Or should I just hold my horses and settle down for a while longer? /Peter On 2008-06-29 (Sun) 15:30, Marcus von Appen wrote: On, Sun Jun 29, 2008, Peter Gebauer wrote: Hi Zhang and others! [Python wrapper issues] The wrapper implementation is not really started yet, so it's a bit early. In order to keep argument parsing flexible, I'd recommend using METH_VARARGS and PyArg_ParseTuple() instead of the _0, ... macros. This let's one easily enhance anything without the need to change too much code. Additionally you can let the parser handle argument checking without the need to deal with ex- or implicit object conversions. Regards Marcus
Re: [pygame] The gsoc physics module, bug fixing?
Hi Zhang and others!
Is it too early to test for bugs? I don't know what method you are using for
development, mine is to test every new thing I write and make sure it works
before I proceed. Depending on your aproach you may not want bug reports
already?
Anyway, after calling world.update(1.0) any following function call will
yield this error:
TypeError: a float is required
Fatal Python error: (pygame parachute) Segmentation Fault
Aborted
Unfortunately, Debian testing has some serious issues with it's python-dbg
package on 64-bit, it thinks it's missing Py_InitModule4_64, so I cannot
debug further using gdb, but I know this error from before.
The problem line is in pgWorldObject.c:
static PyObject* _world_update(pgWorldObject* world,PyObject* pyfloat)
{
double dt = PyFloat_AsDouble(pyfloat); -- problem line
pyfloat is tuple instance, you have METH_VARARGS there which indicates that
the second argument will be a tuple containing the arguments from the Python
call. What you want though is the METH_O, just pass ONE object to the C
call.
So:
{ update, (PyCFunction) _world_update, METH_VARARGS, },
changes to
{ update, (PyCFunction) _world_update, METH_O, },
and the function _world_update should look something like:
static PyObject* _world_update(pgWorldObject* world, PyObject* pyfloat)
{
if (!PyFloat_Check(pyfloat)) {
PyErr_SetString(PyExc_TypeError, World update requires a float);
return NULL;
}
double dt = PyFloat_AsDouble(pyfloat);
PG_Update(world,dt);
Py_RETURN_NONE;
}
That will make a safe and correct call to update using one float. Your other
alternative, if you want more than one argument, is to stick with
METH_VARARGS and do do this:
static PyObject* _world_update(pgWorldObject *world, PyObject *args)
{
PyFloatObject *farg;
if (!PyArg_ParseTuple(args, f, farg))
return NULL; // fail if the argument isn't a float
However, if you're only looking for a single float argument, it makes no
sense for Python to first create a tuple argument list just so you can parse
out one single argument.
I don't know if you want patches of the files, commits to svn or keep
explaining the problems in emails like this, whatever works best and most
efficiently for you.
I'm really looking forward to test some more!
Best regards, Peter
Re: [pygame] The gsoc physics module, bug fixing?
Hi Marcus! OK, I'll hold with the Python API testing. Tell me when. :) /Peter On 2008-06-29 (Sun) 15:30, Marcus von Appen wrote: On, Sun Jun 29, 2008, Peter Gebauer wrote: Hi Zhang and others! [Python wrapper issues] The wrapper implementation is not really started yet, so it's a bit early. In order to keep argument parsing flexible, I'd recommend using METH_VARARGS and PyArg_ParseTuple() instead of the _0, ... macros. This let's one easily enhance anything without the need to change too much code. Additionally you can let the parser handle argument checking without the need to deal with ex- or implicit object conversions. Regards Marcus
Re: [pygame] The gsoc project physics engine.(about warnings)
Hi there, Zhang! I think what Brian meant is that we should get rid off all warnings now so we can find warnings that may be of concern easier. Also, I keep nagging :) but I'd really like to see name changes of the types to follow the PEP. I also found a spelling error on line 152 in rev 1390 which generates a compile error. It's much easier if the code is warning free and PEP-correct even though the interface and implementations aren't complete, it will be better for testing as-is and you won't have the tedious task of correcting hundreds of occurences later. /Peter On 2008-06-23 (Mon) 13:49, 帆 张 wrote: Hi, Thank you for your attention. In fact, these warnings are because of forward types' declarations. When I compile these codes with my VC solution, there are no such warnings, However, with GCC compiler, These warnings tell us such types may be not defined yet. So, the warnings won't cause errors and troubles. Best wishes Zhang Fan Brian Fisher [EMAIL PROTECTED] 写道： On Sun, Jun 22, 2008 at 4:21 AM, Peter Gebauer [EMAIL PROTECTED] wrote: Yeah, SVN tried merging with the sources I changed, that was the prob. But I'm definately getting warnings. Yeah, everybody gets the warnings - they were looked over to check for obvious errors, and are now mostly casting and unused variables. It would be nice for them to be gone so that if new warnings crop up the new ones get more attention in case they represent a real error - 雅虎邮箱，您的终生邮箱！
Re: [pygame] The gsoc project physics engine.
Something must be wrong on your side with that. Anything fine here. Yeah, SVN tried merging with the sources I changed, that was the prob. But I'm definately getting warnings. For the unix way of building software. The Python setup seems to work fine though. As for testing, I have no problems making a world and adding a body to it. /Peter
Re: [pygame] The gsoc project physics engine.
Hi Richard! We've gone through the details already, pymunk is not a Python extension, but both Zhang and I seem to have had the same idea and share design goals currently outside the scope of pymunk. /Peter On 2008-06-21 (Sat) 11:43, Richard Jones wrote: On Thu, 19 Jun 2008, Peter Gebauer wrote: I read Zhang Fan's post regarding his gsoc project, I've been looking to do something similar, a Python extension for an already existing library. So far I've extended Chipmunk partially over a few days of prototyping, but there's no point in having two projects doing the same thing You might well think that... http://code.google.com/p/pymunk/ Richard
Re: [pygame] The gsoc project physics engine.
Hey there! Who currently has write access to the SVN repos? I checked out and tested 1382 just now and aside from failing compile it also yielded plenty of warnings. Do you want me to help clean up? For instance, there was SVN versioning diffs saved to the repos, that's easy to avoid, just make a trial build before checking in. I could also get rid of the warnings. Everything looks good so far, although I haven't tested anything thuroughly yet. Just one suggestion: use uppercase for the types. A question regarding the build, so setup.py is used, what is the makefile and Makefile files for? /Peter
Re: [pygame] The gsoc project physics engine.
Hi again! I've tried compiling what you've submitted so far, it fails with many errors. For instance, what's with the double typedef's? Are you still just prototyping? Also, I'm writing cmake build scripts to test your code, is anybody else interrested in this or should I use whatever PyGame is using? What is the preferred way of building? /Peter Hi, In fact, just as I said before, all data structures of this engine are based on python basic type data structures. 2d vector type is just same as complex type in concept and C implementation, so I just use Python complex type and add some functions for advanced vector usages. I think maybe it's not a bad idea to treat physics 2d vector space as complex number space. But I also separate the main code from vector code, replacing it with a distinct vector type will be easy, maybe it will support it after the first stable release. Best Wishes Zhang Fan
Re: [pygame] The gsoc project physics engine.
Hi Nirav! As you can see from Zhang's post there's a difference between making soft bindings using ctypes and hard bindings using the Python C API. While ctypes is convenient to use and easy to modify since only Python code is involved, it lacks the ability to let the programmer to extend Python using the underlying C API directly. It also lacks the ability to intergrate easy with other Python extensions. It's also a matter of speed, in particular when it comes to iterations, like for collision testing and drawing many objects. If this can all be done in C we are better off. My plan was to build a Python extension for 2D physics that could be intergrated easily with PyGame, which is also a Python extension. Since two people have the same plan I thought we'd join up. :) /Peter On 2008-06-19 (Thu) 07:47, Nirav Patel wrote: I may be missing something, but aren't there already python bindings for Chipmunk? http://code.google.com/p/pymunk/ I've only experienced it as http://wiki.laptop.org/go/Pymunx although they use Box2d now: http://elements.linuxuser.at/ Nirav On Thu, Jun 19, 2008 at 12:23 AM, Peter Gebauer [EMAIL PROTECTED] wrote: Hi! I read Zhang Fan's post regarding his gsoc project, I've been looking to do something similar, a Python extension for an already existing library. So far I've extended Chipmunk partially over a few days of prototyping, but there's no point in having two projects doing the same thing, I'd like to know a bit bout the plans of the physics module for PyGame. (if you're reading this, Zhang) I could also help out with some testing/patching for the C Python stuff. /Peter
[pygame] Re: 回复 ： [pygame] The gsoc project physics engine.
Hello! Yes, I've been looking continously at your source codes, I saw you were getting your Python C structs together yesterday, nice. My first advice would be this: all types/classes must start with capital case letter. I saw in your documentation that your prototype API used lowercase, I think we should try sticking with the Python style guide http://www.python.org/dev/peps/pep-0008/ which is sort of how PyGame looks too, i.e CamelCase for types and function_underscore_rule for functions and methods, hehe. Just a small thing, but it's easier to change now than later. I'll continue to browse the source code as you commit it and as soon as I'm able to build a physics module I'll start testing stuff in Python to see that it behaves as expected. If you can, try getting the Python module code ready and make dummy functions for the entire API, raise NotImplementedError if you want for unimplemented functions, that is PyErr_SetString(PyExc_NotImplementedError, this isn't implemented yet) or similar, as long as I can build and import stuff in Python I can make a test suite. Since I'm not a math and my C knowledge is limited I'll try to assist with what little insight I have into the Python C API and Python as a language. /Peter On 2008-06-19 (Thu) 12:17, 帆 张 wrote: Hi , Thank you very much, I'd like to see your advices and get help from you. I also want to tell the difference between chipmunk(and Pymunk) and this project, this one is not separated with python, all of its basic data structures are based on python data structures, which means it can be integrated in python seamlessly . Also some classes are targeted to integrate physics updating and pygame sprite rendering, which means user can write their physics games more easily. API defines and my working progress are on my yahoo blog: http://i.cn.yahoo.com/zhangfanfox/blog/ , and current working code is on a branch of pygame svn: svn://seul.org/svn/pygame/branches/physics Best wishes Zhang Fan Peter Gebauer [EMAIL PROTECTED] 写道： Hi! I read Zhang Fan's post regarding his gsoc project, I've been looking to do something similar, a Python extension for an already existing library. So far I've extended Chipmunk partially over a few days of prototyping, but there's no point in having two projects doing the same thing, I'd like to know a bit bout the plans of the physics module for PyGame. (if you're reading this, Zhang) I could also help out with some testing/patching for the C Python stuff. /Peter - 雅虎邮箱，您的终生邮箱！
[pygame] The gsoc project physics engine.
Hi! I read Zhang Fan's post regarding his gsoc project, I've been looking to do something similar, a Python extension for an already existing library. So far I've extended Chipmunk partially over a few days of prototyping, but there's no point in having two projects doing the same thing, I'd like to know a bit bout the plans of the physics module for PyGame. (if you're reading this, Zhang) I could also help out with some testing/patching for the C Python stuff. /Peter
