http://blog.gmane.org/gmane.comp.python.pygame hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.python.pygame/23904 <pre>I recorded a short podcast for hacker public radio talking about the awesome midi functions in pygame. I don't think i did it justice. Someone who really knows what they are talking about should do another one and submit it to the site. :D http://hackerpublicradio.org/eps.php?id=0991 </pre> bgryderclock-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org 2012-05-23T03:33:48 http://comments.gmane.org/gmane.comp.python.pygame/23899 <pre>The following code: import pygame, numpy pygame.mixer.pre_init(frequency=96000,size=-16,channels=1) pygame.init() a = numpy.random.randn(96000) sound = pygame.sndarray.make_sound(a) print sound.get_length() yields a print-out of 4.0, suggesting that the specified duration of 96000 samples at a 96000kHz sampling rate was somehow quadrupled somewhere along the way. Any idea what I'm missing here? Or is this a bug? </pre> Mike Lawrence 2012-05-21T17:54:37 http://comments.gmane.org/gmane.comp.python.pygame/23891 <pre>One of my students was doing pixel perfect collisions with Sprites and found what may be a bug. pygame.mask.from_surface seemed to return an empty mask when everything on a surface is opaque. In this situation rectangle collisions made more sense but I am still curious why pygame.mask.from_surface is behaving this way. I quickly dug through the source and nothing popped out as the cause. </pre> Nicholas Seward 2012-05-14T14:12:01 http://comments.gmane.org/gmane.comp.python.pygame/23887 <pre>Before I go and file a bug against Ubuntu, can somebody confirm I'm not being stupid. For my input boxes, the cursor position depends on a monospaced font. This means I check the length of a rendered letter ("e") using the font, and then set the cursor position as a multiple of this length. This worked fine before, but in Ubuntu 12.04, it no longer seems to be monospaced. Getting the length of the character "e" on my system gives me 9 pixels, but it seems that some characters, such as "h", are 10 pixels, which starts offsetting my cursor position and messing up my input box. The line I use to load the font is: pygame.font.SysFont("FreeMono, Monospace", 16) That should definitely return a monospaced font, right? And, the line used for getting the width is: mono_font.render("e", False, (0,0,0)).get_size()[0] Is this a bug, or am I doing something stupid? </pre> Sam Bull 2012-05-14T10:25:00 http://comments.gmane.org/gmane.comp.python.pygame/23884 <pre>Hello, I've been fighting the great fight against spam on the pygame.org wiki, but there's at least 2 accounts that seem to be doing automated changes: spainadmon and Ronald Derren. The Derren account is being particularly nasty these past few days. I've gone from direct editing to reverts, but it's hard to keep up. I could whip up an automated removal tool of my own but that wouldn't really fix the problem, and it just seems ungentlemanly to do the same as the attackers (even though I have better intentions). Can prevention tools be added to the site? Captcha's, IP blocks, anything? I hate to see the site just plowed under by the BadGuys. I feel for the webmaster(s), this isn't meant as a knock. The attackers always have the advantage and I know it never ends. Regards, Winter (W. Fielder on the pygame wiki recent changes) </pre> Winter 2012-05-11T21:32:45 http://comments.gmane.org/gmane.comp.python.pygame/23883 <pre>Hi, I am using pygame.mask.from_surface(Surface, color, threshold = (0,0,0,255)) to convert a surface into a 2D binary mask. I expected the default threshold (0,0,0) of this function to have it match only that the exact color specified (ie within 0 values of the color). However, it seems that it instead matches NO pixels. To get the behaviour I expected I needed to specify a threshold of (1, 1, 1, 255) Is this a bug, or are my expectations wrong? Regards, Peter Finlayson </pre> Peter Finlayson 2012-05-11T08:38:30 http://comments.gmane.org/gmane.comp.python.pygame/23881 <pre>Hi, Recently, I did some benchmarking on the various ways to do Rect collision detections using Pygame. I mentioned some of this on the IRC channel a couple weeks ago, and they said that some of you on this list may be interested. In the past, I have always stored the location of my sprites in a ((x, y), (w, h)) tuple, in a .rect attribute, because I knew Pygame would automatically convert these to Rects as needed. It occured to me that it may be more efficient to instead store them as actual Rects, so I decided to do some testing. I got some surprising results, so I did more testing, and here's what I found when colliding a single item against 100 items (with 100 000 interations): a rect and a list of tuples 1.12 seconds, 5.9x a rect and a list of objects containg tuples 3.19 seconds, 16.9x a rect and a list of rects 0.19 seconds, 1.0x a rect and a list of subclassed rects 1.00 seconds, 5.3x a rect and a list of objects containing rects 2.19 seconds, 11.6x a sprite and a group of sprites 1.70 seconds, 9.0x a sprite and an ordered group of sprites 1.55 seconds, 8.2x The fastest way to do collisions was to do a Rect.collidelistall(). The surprising thing to me was how much slower my chosen method was (Storing tuple in the .rect attributes of my classes). Up to twenty times slower on some tests. Other things I found interesting: Using the collisions offered by the Sprite class is convenient, but quite slow. Subclassing the Rect and using that for your own sprites causes quite a loss of speed (5x slower). The extra lookup to extract the .rect attribute from an object is quite expensive in Python. Creating a (pos, size) tuple is marginally slower than creating a Rect, but the advantages of the Rect far outweigh that cost. Conclusions: Well, testing shows I was doing things The Wrong Way (tm) :) A lot of this is probably familiar to those of you who are familiar with Pygame internals, but the scale of the difference was a shock to me. The relative advantage of the list of Rects improves even more as you add more objects to collide with. At 200 objects, it was 20x times faster the my original method. There is also the issue of /relevance/. Collision probably aren't the biggest slice of your game's time, but if you are aiming for 60 FPS, my method was eating up 3.2 milliseconds each frame. That's a significant proportion of the 16ms budget. I have attached the code that produced these results. Regards, Peter Finlayson </pre> Peter Finlayson 2012-05-10T14:13:31 http://comments.gmane.org/gmane.comp.python.pygame/23877 <pre>I wrote a small clock program that I might use if it turns out well, but I am having a small issue where the top of the arcs that grow over time shifts when I would like it to stay still. Does anyone know how to achieve this? </pre> Silver 2012-05-09T03:30:35 http://comments.gmane.org/gmane.comp.python.pygame/23871 <pre>Hello, I'm a researcher using pygame to measure sensory processing in children. I want to use sndarray to play out a numpy array I have created, containing a sound stimulus. But I can't seem to get any sound at all. I'm not an expert programmer so I would welcome any advice. I'm using Windows 7, with python 2.7, and the array will play out fine (as float) if I use pyaudiere. A simplified version of my code is below - interestingly I also get no sound when I run the example which someone has kindly posted as a comment on the sndarray doc page. I am baffled! Many thanks Caroline from numpy import * import pygame SRATE=44100 # sample rate in Hz DURATION=1 # duration in sec # an array of floating-point random numbers noise= array(random.randn(SRATE*DURATION)) pygame.mixer.pre_init(SRATE, 16, 1,4096) pygame.init() # make it int16, scale it for 16 bit mysound=int16(noise.copy()*2**15) snd=pygame.sndarray.make_sound(mysound) snd.play() pygame.time.wait(DURATION*1000) </pre> Witton, Caroline 2012-05-04T09:13:08 http://comments.gmane.org/gmane.comp.python.pygame/23870 <pre>Contest starts next week. Don't forget. :) </pre> Jake b 2012-04-30T19:15:42 http://comments.gmane.org/gmane.comp.python.pygame/23868 <pre>In fact it s not for professional stuff or whatever but i am à huuuuge fan of python and of old school techniques such as raycasting. I have already wrote a wolfenstein clone in c using le libx. Textures and some.effects were implemented without any lag ( i can give the code if anyone is interested). So now i'd like to write à more advanced wolf/doom like using an OO approach. So i though Python of course cause it's soon sexy blablabla but maybe not adapted. So now my question is, can i write the game logic entirely in python and write the rendering part in C with OpenGL calls? Thank you in advance! ----- Reply message ----- De : "Weeble" &lt;clockworksaint&lt; at &gt;gmail.com&gt; Pour : &lt;pygame-users&lt; at &gt;seul.org&gt; Objet : [pygame] raycasting engine performances (numpy array) Date : ven., avr. 27, 2012 08:36 On Thu, Apr 26, 2012 at 1:49 PM, Nathan Biagini &lt;nathan.open&lt; at &gt;gmail.com&gt; wrote: I see a moderate speed-up when replacing: asf[x][y] = 255 with: asf[x,y] = 255 Which avoids doing two layers of Python indexing for each pixel. Still, it doesn't make it fast enough to be smooth. I see a much bigger speed-up if I replace that loop with: asf[x,start:end] = 255 This shifts the whole loop into C code with no Python interpreter to slow it down. The only problem is figuring out how to express the texturing as something numpy can do do efficiently. I think it may well be possible, but I'm not enough of a numpy expert to know off the top of my head. I totally agree with Greg: only do this if it's for your own education and amusement. Raycasting on the CPU is always going to be way slower than a GPU can do, even if you can get the Python interpreter out of all the slow bits (whether that's by way of numpy, PyPy or just plain writing some C). </pre> nathan.open< at >gmail.com 2012-04-27T08:41:32 http://comments.gmane.org/gmane.comp.python.pygame/23865 <pre>Hi. I have recently started to write a ray casting engine with Pygame and i'm at the very early stage of the engine but i already have performance issues. I use the surfarray module to do all the drawing (actually, i only want to draw lines) but i have issues about performances. When i come closer to a wall (when the lines i draw become bigger), it starts to be a bit laggy. So i think it's all about the draw_verline function that just iters vertically in the array and set the pixels, i dunno if i can do more "optimized" as a drawing line function... Here is the code so far : http://pastebin.com/GzZ3dEu8 If i totally remove the surfarray implementation i go with simple surfaces and using the draw.line function, is super fluent and there is no lag even if the line are big. But i can't stuck with drawing line this way because it will cause problems when i will try to implement textured walls. If anyone has an idea. Thanks in advance : ) </pre> Nathan Biagini 2012-04-26T12:49:39 http://comments.gmane.org/gmane.comp.python.pygame/23861 <pre>Hello everyone, I've been for some days trying to develop a "canabalt"-like game ( http://www.canabalt.com/), saving distances... I've got the way to manage scroll, buildings appearances, distance between them, etc. Where I'm getting stucked is making the jump movement, and I left this for the last thing to do. What I'm trying to do is a basic jump movement where the more time you're pushing the button the more time you're jumping, with a limit of course. The player is always on the same "x" coordinate, so he only has to change the "y" in the way we want. So, the way I learned to manage all of this is with a "player" class and some methods to define actions (jump, prone, animation,...). Well, at this point I'm getting frustrated trying to do this with this tools. The only thing I achieve is jumping with the "player" MEANWHILE the key is pressed. And here is the thing: I cannot find the way to make the "player" jump with A TOUCH of a key. Thanks for your time (and sorry for my English! xD) </pre> NesKy 2012-04-20T20:58:20 http://comments.gmane.org/gmane.comp.python.pygame/23859 <pre>In case anybody cares, I have an unofficial Mac binary for pygame 1.9.1 that uses python.org's 64-bit Python (Mac OS X 10.6 and later). I don't intend to serve it officially because the unit tests had 3 errors and 2 failures (see appended log). But it may be useful to somebody (it certainly meets my needs, which is only to play sound files). You can get it here: &lt;http://www.astro.washington.edu/users/rowen/python/&gt; The png tests are especially puzzling to me because: - The installer could not find Apple's libpng in /usr/X11 even though I added those include and lib dirs as required and that must have worked because pygame's installer found libfreetype there. - So I installed my own libpng, which seemed to build just fine and pygame seemed happy to use it. </pre> Russell E. Owen 2012-04-12T19:34:50 http://comments.gmane.org/gmane.comp.python.pygame/23856 <pre>Hey all, how's it goin? So I recently returned to the bay area after a year out of the country, and coming back to the job market here, it is completely batsh*t insane. There are a lot of python opportunities as well. So I was wondering ... is anybody in the bay area on this list looking for work? Do we have any policy as far as advertising jobs on this list? Is there a python jobs list? There are also a number of game companies here looking for people to do some test automation for c++ game apps. I've talked to a couple already. My cpp skills weren't up to the level they were looking at, but I thought of us here as well as the SDL mailing list. </pre> Sean Felipe Wolfe 2012-04-07T18:11:14 http://comments.gmane.org/gmane.comp.python.pygame/23839 <pre>Hi all, (Sorry for the long message, but I like to give them an historical context; you can jump directly to the question below if you want) ---- Historical context ---- As I told in an old thread (about 3D rendering in pygame), I started writing games/programs in a Sinclair ZX Spectrum with a fixed 256x192 screen resolution. Very simple resolution choice: just 256x192. After that, worked on PCs where you could just select between my beloved mode 13h (MCGA 320x200x256, paletted) and VGA 640x480x16 colours (SVGA VESA modes were not really very used then). You had really not more resolutions to select (maybe mode-x such as 320x240), so you selected just 1 resolution (for speed = 320x200, for detail = 640x480) and you created your game according to this resolution. Very simple: you draw sprites and menues and backgrounds and position them with that resolution in your mind, and everything fits. After that, it came a lot of years where the maximum system resolution for PCs was 1024x768 and you could create a game in either 640x480, 800x600 or 1024x768 (tipycally, 640x480) and it looked "good" in that display, either windowed or fullscreen. But, again, for 2D games, you usually selected and used a single resolution. ---- End historical context ---- And the question: I have problems to determine the best way to "create" game graphics and to "design" the game engine to allow the player to change the game resolution, or just to fit my game in the "available display". Nowadays you have a very large variety of possible displays: from simple PC's with 17" 1024x768 to 22.5" FullHD monitors, to tablets that range from 640x400 to 1280x800, not forgetting that the displays can be either 4:3, or 16:9, or 16:10... Selecting a concrete resolution (640x480 or 800x600 typically) can annoy the user because it can be too small in window mode or too "big" (low-res, really) in fullscreen mode... so I think that we need to adapt the game in real time to the resolution that the user wants to use. Very easy in 3D games, but ... not in 2D games. So, my doubts: - Game graphics (pixel-art, not vector or 3d graphics): What's the best way to create the graphics? Do them "high-res", try to ask always for the highest resolution and downscale if not (losing quality)? Do them "mid-res" and upscale / downscale depending on the resolution? Create them in 2 or 3 different sizes to minimize quality losing in scaling? - Game engine: when creating the scoreboard, menues, inventories, position items in the screen, define sprite-speeds ... should I use "percentages" instead of pixels? ( % ). Should I, instead, work in a "base resolution" (640x480) and scale all (pixel-speed for sprites, on-screen text and scoreboards positions, etc) according to the relation base-resolution / real-resolution? And what about the ratio (16:9 &lt;-&gt; 4:3) change (it's not just an "scaling" problem)? How do you think I should be handling all this? </pre> Santiago Romero 2012-04-05T16:24:11 http://comments.gmane.org/gmane.comp.python.pygame/23829 <pre>I was wondering if there was much interest in extending OpenGL support in Pygame. One of the things I am implementing in my toolkit is OpenGL support. To do this, I am effectively creating the surface class and draw module in OpenGL. I am using Pygame's API to create the interface for it, so that it can be simply dropped into the same places and behaves in the same way as vanilla Pygame. If this is something of interest to other people, I'm wondering whether there might be some interest in integrating this code into Pygame (sometime after GSoC). This would (I'm envisaging) allow users to create a game using Pygame's standard sprite and draw module, and be able to run it under OpenGL by simply adding the OPENGL flag. As opposed to having to recreate all of the drawing code. Even for developing 3D games, I think this would make it a lot easier for developers to create the 2D elements of a game, such as the HUD. Thanks, Sam Bull </pre> Sam Bull 2012-04-05T15:08:08 http://comments.gmane.org/gmane.comp.python.pygame/23824 <pre>Hi Here is a (hopefully) useful state machine frame work I have been working on: https://bitbucket.org/dr0id/symplehfsm Game logic is based on state machine in many cases. This is to make it really easy to design and implement such behaviors. Any feedback welcome. ~DR0ID </pre> DR0ID 2012-04-04T20:51:15 http://comments.gmane.org/gmane.comp.python.pygame/23822 <pre>Hello, n0nick (Sagie Maoz) tried to post to the mailing list, but for some reason the mails didn't make it through. He wanted feedback on the GSOC proposal: http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/n0nick/28002 What do you think? I pasted the project description part below: ------------- Project description The project consists of two parts: (1) redesigning the sprite models and (2) implementing a basic scene/state system support. Sprites work The parts of Pygame that currently handle the Sprite objects, while very fundamental for any use of the library, are reportedly not as generic and as feature-full as they should be. The project would revolve around redesigning and rewriting the core code of the Sprite class to fit the needs described by the community, and to add some system-wide functionality. Research is required in order to decide on an optimal design pattern for sprites and sprite groups, that would make use of inheritance and would result in a solid generalized base set of classes. This design should also allow users the flexibility of extending and customizing sprites behavior. Deliverables: - The sprite and sprite group classes rewritten in a more generalized manner. - Features that are currently only implemented in some types of sprites (i.e. grouping and collision detecting) rewritten as generic features, provided for all sprite types. - New general features for sprites that were (and will be) suggested by the community; - Easier positioning methods (ability to use a position tuple instead of rects), - Anchor points, - An improved layering system, - Smarter dirty rendering (detecting changes in sprites to automatically mark them as dirty), - Aggregated sprites object implementing the sprite interface, - Other features suggested and found in research. Scene and state system work Pygame currently does not offer any higher level entity that organizes visual objects by game state and logic. This could be done by implementing a Scene module that would represent a distinct section of the game. As such, it would contain all related sprites encapsulated in this section, and would allow running common actions on them, such as rendering and logic updating (through a Composite or similar pattern). A scene would also define some events, such as “scene start” and “scene end”. These events would be fired by a new external Director module that would define the game workflow and the relation between scenes. Research is needed here to decide on a particular design that would be both simple to grasp and maintain, and also memory efficient. Deliverables: - A stable set of classes implementing the Director/Scene workflow. - Documentation explaining the internal design and the way to use it. </pre> René Dudfield 2012-04-04T17:43:17 http://comments.gmane.org/gmane.comp.python.pygame/23820 <pre>Hi, i'd like to know if i can, with pygame, reset the display stuffs. I mean, i start with a certain resolution and i'd like to set the fullscreen after a certain condition is raised, but i don't know how to do that? Is that possible? Thanks. </pre> Nathan Biagini 2012-04-04T14:28:58 http://comments.gmane.org/gmane.comp.python.pygame/23815 <pre>At long last, I'm announcing the next release of my GUI toolkit. This release has seen a lot of refactoring and redesigning, making the project a lot more consistent and easier to use. A few new widgets have also been added. A couple of the new widgets have been submitted by Micheal Rochester. This is also the first release to see some actual documentation. You can check out the documentation at http://program.sambull.org/sgc/ If you'd prefer an offline devhelp version, there is a separate download on Launchpad. If you'd like to try it out, download the release code. As long as you have Python 2 and Pygame installed, you should be able to run the example file immediately. To use it in your own projects, simply copy the 'sgc' sub-folder into the top-level of your project or add it's parent folder to your PYTHONPATH so that Python can import it in the normal way. So, if you're interested, please check it out at: https://launchpad.net/simplegc Finally, the limitations of this beta release, that I would advise you stay away from: No Python 3 support yet. Using custom images is not documented or properly tested. OpenGL support is not working in this release (it's just barely working on my machine, with some extra code). There's an issue with transparency, so (0,0,0) means transparency in this release, if you find things are invisible try changing the colour (perhaps (0,0,1)). There's no developer documentation to help write your own widgets. </pre> Sam Bull 2012-04-02T19:07:48 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.python.pygame