Re: [pygame] Pygame games run slowly :(
Toni, you make a good argument, but some of your points are a bit misleading. As for games not needing a lot of resources, your kind of off. Only reason ps3s have 512MB is that it doesn't have to worry about the many processes a computer OS requires. Plus the ram is top of the line (gddr3 / xdr) and isn't really comparable to normal computer ram. I agree that nothing beats efficient coding, but that can only go so far. Sooner or later, you still have to upgrade. I personally am a fan of simple games (#1 game is block dude.. anyone who had a ti83 or 89 should know what it is). But you can't expect game programmers to all stay low tech. Yes small mini computers and smart phones are becomming popular, but so are stronger laptops and computers. As for the slow game in question (http://www.pygame.org/project/596/) the game designer does say Thanks! And yes, framerate is definitely an issue on (dare I say) lower-end computers Btw, the latest budget computers have at least 2.X GHz CPUs. So yea.. it's time to upgrade.
Re: [pygame] how to remove spam comments in pygame wiki
Hi Brian, Brian Fisher wrote: On Wed, Jul 29, 2009 at 11:55 AM, jug j...@fantasymail.de mailto:j...@fantasymail.de wrote: Yeah, sorry. It uses simple text files with an own simple structure and markup. So, it's not as bad as I thought. But still bad. IMHO, bad enough to be replaced. It *is* something self-made, the html and css is *hardcoded* into the generator script and therefore it *is* impossible to change easily. Finally, the output *is* ugly and *invalid* (http://validator.w3.org/check?uri=http%3A%2F%2Fwww.pygame.org%2Fdocs%2Fref%2Fsurface.html). However, after some trial and error and some changes on the generator code, I got the docs integrated into the website (used code from svn, so docs are for pygame 1.9.0): http://pygameweb.no-ip.org/docs/ So, if no one is interested in a more professional documentation system, we should at least update the generator script to produce some more valid code, use a simple template for html and css and become a bit more configurable. Julian, good job on working with current documentation content to get a page working. However I have to say that I do not find this page: http://pygameweb.no-ip.org/docs/ to be any improvement at all over this page: http://www.pygame.org/docs/ I don't think the aesthetics or usability have been improved. But my real critique of it is that you dropped what I considered to be a highly effective and useful format for documentation - to have single page docs for a module, where the top half of the page is functions for the module that links down to the dull description later on the same page. The problem is that with your main page being a list of all modules and their functions together, it's hard to get a good overview of the modules compared to a list of each module with short descriptions. Likewise, once I've decided a module is for me, and choose to go to it's page to drill into it, I don't get a clear and simple overview of that module. I hope the doc pages are something you continue to improve from the perspective of easily getting overviews of things and getting a high level picture of what the library has to offer. And lest you think I'm biased, I didn't do a single thing to work on the current pygame website or doc system, and have no particular love of the current website. I just happen to have had a really great experience working with pygame's website doc pages over the years - it's always been a lovely experience to browse them for me because it's so easy to get a high level picture and find what I want. I find them to be far more usable and effective than python's own doc web pages, which are at times overwhelming and impossible to get a good high level view from (like say the urllib firends docs for instance - where you don't even know what classes or modules you want to use, and once you do have a guess at that, it's hard to find a useful function). Indeed, the docs at pygameweb are not better than the ones on pygame.org. I just had a look into the generator script and modified it to produce templates I can use with the rest of the website (so that the recent-releases and the menubar are still there). Then, its valid XHTML 1.0 Strict. Surely it needs more improvements. I'll try to get the index page clearer, for the rest, I don't know yet. Eg. http://pygameweb.no-ip.org/docs/surface.html ist not really easy to read, but I don't know exactly why. Feel free to help improving it.
Re: [pygame] Pygame games run slowly :(
Brian Song kirjoitti: Toni, you make a good argument, but some of your points are a bit misleading. As for games not needing a lot of resources, your kind of off. Only reason ps3s have 512MB is that it doesn't have to worry about the many processes a computer OS requires. Plus the ram is ok fair enough. like said it largely depends on the game, some take little memory, some easily want loads. simple games (#1 game is block dude.. anyone who had a ti83 or 89 should know what it is). But you can't expect game programmers to all stay low tech. Yes small mini computers and smart phones are becomming popular, but so are stronger laptops and computers. right. was thinking about how to mention something like 'of course i don't expect all game dev to stay low tech', sure it's great that the boundaries are pushed and we get the amazing new huge complex things that really use the power there is today. basically just didn't want there to be the impression that 1GHz wouldn't generally be enough to run pygame games, and the point about low power devices being there too. As for the slow game in question (http://www.pygame.org/project/596/) the game designer does say Thanks! And yes, framerate is definitely an issue on (dare I say) lower-end computers oops, seems that recalled the original post wrong and it indeed mentioned the name of a game with the prob. will test later today how it runs on this ~1Ghz celeron laptop, and perhaps how on a 1.3Ghz G4 mac, and perhaps even profile out of curiousity thanks for comments, and sorry for the inaccuracies. ~Toni
Re: [pygame] Pygame games run slowly :(
Toni Alatalo kirjoitti: As for the slow game in question (http://www.pygame.org/project/596/) the game designer does say Thanks! And yes, framerate is definitely an issue on (dare I say) lower-end computers runs on this ~1Ghz celeron laptop, and perhaps how on a 1.3Ghz G4 mac, and perhaps even profile out of curiousity Arderyst seemed like a nice game, tested a little now, will perhaps play more with my son some time later :) The old celeron laptop was actually a whopping 1.6GHz and the game is choppy there with all the (nice!) gfx options on, it event notes about it. Ran the py2exed version now and don't have profiling tools at hand so didn't go there yet, but read some of the source after had seen when it gets slow, and it seems to do particles and moving decoration objects so that they are not only written in pure py and iterated in pyindividually for every frame, but there is even a separate blit call for every particle: in play_level.py ln 849: def Particle_Tick(particles): for particle in particles: particle.blit(SCREEN, -CAMERA_X) particle.tick() .. with some logic and movement code in both those methods of the Particle class, and eventually a pygame blit. same seems to be the case with decorative falling objects, in play_level.py ln 1905 def blit_falling_bg_objs(THISFLIP): for fallingbgobj in FALLINGBGOBJARRAY: (...) lrect.center = (fallingbgobj[1] - CAMERA_X + math.sin(fallingbgobj[0])*fallingbgobj[3]*10, fallingbgobj[2]) SCREEN.blit(lsurf, lrect) I haven't examined this but have used sprite groups to draw many things with one py call, and would guess that such individual blitting might be a bottleneck. Dunno if using e.g. spritegroups there would actually help. If such blitting is indeed slow, Psyco won't help, didn't test that (yet). In our project I started to use Lepton for particles to have the movement code in native code, expected pure py to be too slow there. Also that falling object movement code seems like something you could do with numpy to have it efficiently: when you do same op for a lot of objects, just using individual data (the individual pos and move vel), you can do it with arrays. But the array approach is not perhaps easy at all for a beginning programmer to use. So it is like was said in an earlier thread on this list .. in c or other compiled langs you can write more 'stupid' (no insults meant here!) code and it's still fast enough, whereas for py to be efficient for heavy things you must do it cleverly. Dunno if it will be JITting ala Psyco or easier-than-c(++) compiled langs like shedskin (a py - c++ generator) or d (a friendlier c++) which will help. Or whether we should indeed use numpy for such stuff. ~Toni again, stopping these rants and explorations now.
Re: [pygame] Pygame games run slowly :(
Hi, Well the first optimization that can be done is to use a lambda function and a list comprehension which performs the for loop at C speed will likely bring a huge benefit: #we use wrappers because blit and tick only return none, which makes functional programming a bit harder... f=lambda y: y if y.tick() else y g=lambda z: z.blit(SCREEN, -CAMERA_X) particles =[lambda x: f(x) if g(x) else f(x) for x in particles] Et voila! C-speed execution, O(n) run-time. All it looses is readability, and there's the slight overhead of the two lambda functions... and yes, that else clause is needed in there. Of course for actual production code, I'd assume one would use far more descriptive variables than I did. This works because lambda functions can use if conditions as their expression, so the syntax for that is: lambda argument list: expression A if conditional else expression B Expression A is executed if the conditional is true, and expression B is executed if the conditional is false. So we use the conditional to perform an action, and that action will naturally return None(iirc about blit and tick), which causes expression B to be performed. Since expr A and B are the same, we just perform the conditional, and then do expr B. Unfortunately Python doesn't optimize that though. And in expr B, we use the same structure again, to return the particle to ensure our list has all of its processed particles. In a real compiler, that if else construction would be eliminated. :/ Isn't python awesome? -Tyler On Thu, Jul 30, 2009 at 6:53 AM, Toni Alatalo ant...@kyperjokki.fi wrote: Toni Alatalo kirjoitti: As for the slow game in question (http://www.pygame.org/project/596/) the game designer does say Thanks! And yes, framerate is definitely an issue on (dare I say) lower-end computers runs on this ~1Ghz celeron laptop, and perhaps how on a 1.3Ghz G4 mac, and perhaps even profile out of curiousity Arderyst seemed like a nice game, tested a little now, will perhaps play more with my son some time later :) The old celeron laptop was actually a whopping 1.6GHz and the game is choppy there with all the (nice!) gfx options on, it event notes about it. Ran the py2exed version now and don't have profiling tools at hand so didn't go there yet, but read some of the source after had seen when it gets slow, and it seems to do particles and moving decoration objects so that they are not only written in pure py and iterated in pyindividually for every frame, but there is even a separate blit call for every particle: in play_level.py ln 849: def Particle_Tick(particles): for particle in particles: particle.blit(SCREEN, -CAMERA_X) particle.tick() .. with some logic and movement code in both those methods of the Particle class, and eventually a pygame blit. same seems to be the case with decorative falling objects, in play_level.py ln 1905 def blit_falling_bg_objs(THISFLIP): for fallingbgobj in FALLINGBGOBJARRAY: (...) lrect.center = (fallingbgobj[1] - CAMERA_X + math.sin(fallingbgobj[0])*fallingbgobj[3]*10, fallingbgobj[2]) SCREEN.blit(lsurf, lrect) I haven't examined this but have used sprite groups to draw many things with one py call, and would guess that such individual blitting might be a bottleneck. Dunno if using e.g. spritegroups there would actually help. If such blitting is indeed slow, Psyco won't help, didn't test that (yet). In our project I started to use Lepton for particles to have the movement code in native code, expected pure py to be too slow there. Also that falling object movement code seems like something you could do with numpy to have it efficiently: when you do same op for a lot of objects, just using individual data (the individual pos and move vel), you can do it with arrays. But the array approach is not perhaps easy at all for a beginning programmer to use. So it is like was said in an earlier thread on this list .. in c or other compiled langs you can write more 'stupid' (no insults meant here!) code and it's still fast enough, whereas for py to be efficient for heavy things you must do it cleverly. Dunno if it will be JITting ala Psyco or easier-than-c(++) compiled langs like shedskin (a py - c++ generator) or d (a friendlier c++) which will help. Or whether we should indeed use numpy for such stuff. ~Toni again, stopping these rants and explorations now. -- Visit my blog at http://oddco.ca/zeroth/zblog
Re: [pygame] Pygame games run slowly :(
Tyler Laing wrote: Lambda/list comprehension executing speed. http://oddco.ca/zeroth/zblog Wow, does doing this really give such a significant speed up? That's awesome, thanks a lot Tyler. Fiona
Re: [pygame] Pygame games run slowly :(
Before I believe you actually optimized things, how does the timing of your new code compare to the original (timeit is your friend)? Since your lambdas add additional function call overhead, and the list comprehension adds the cost to build a list, I would not assume this is faster. -Casey On Jul 30, 2009, at 8:32 AM, Tyler Laing wrote: Hi, Well the first optimization that can be done is to use a lambda function and a list comprehension which performs the for loop at C speed will likely bring a huge benefit: #we use wrappers because blit and tick only return none, which makes functional programming a bit harder... f=lambda y: y if y.tick() else y g=lambda z: z.blit(SCREEN, -CAMERA_X) particles =[lambda x: f(x) if g(x) else f(x) for x in particles] Et voila! C-speed execution, O(n) run-time. All it looses is readability, and there's the slight overhead of the two lambda functions... and yes, that else clause is needed in there. Of course for actual production code, I'd assume one would use far more descriptive variables than I did. This works because lambda functions can use if conditions as their expression, so the syntax for that is: lambda argument list: expression A if conditional else expression B Expression A is executed if the conditional is true, and expression B is executed if the conditional is false. So we use the conditional to perform an action, and that action will naturally return None(iirc about blit and tick), which causes expression B to be performed. Since expr A and B are the same, we just perform the conditional, and then do expr B. Unfortunately Python doesn't optimize that though. And in expr B, we use the same structure again, to return the particle to ensure our list has all of its processed particles. In a real compiler, that if else construction would be eliminated. :/ Isn't python awesome? -Tyler On Thu, Jul 30, 2009 at 6:53 AM, Toni Alatalo ant...@kyperjokki.fi wrote: Toni Alatalo kirjoitti: As for the slow game in question (http://www.pygame.org/project/ 596/) the game designer does say Thanks! And yes, framerate is definitely an issue on (dare I say) lower-end computers runs on this ~1Ghz celeron laptop, and perhaps how on a 1.3Ghz G4 mac, and perhaps even profile out of curiousity Arderyst seemed like a nice game, tested a little now, will perhaps play more with my son some time later :) The old celeron laptop was actually a whopping 1.6GHz and the game is choppy there with all the (nice!) gfx options on, it event notes about it. Ran the py2exed version now and don't have profiling tools at hand so didn't go there yet, but read some of the source after had seen when it gets slow, and it seems to do particles and moving decoration objects so that they are not only written in pure py and iterated in pyindividually for every frame, but there is even a separate blit call for every particle: in play_level.py ln 849: def Particle_Tick(particles): for particle in particles: particle.blit(SCREEN, -CAMERA_X) particle.tick() .. with some logic and movement code in both those methods of the Particle class, and eventually a pygame blit. same seems to be the case with decorative falling objects, in play_level.py ln 1905 def blit_falling_bg_objs(THISFLIP): for fallingbgobj in FALLINGBGOBJARRAY: (...) lrect.center = (fallingbgobj[1] - CAMERA_X + math.sin(fallingbgobj[0])*fallingbgobj[3]*10, fallingbgobj[2]) SCREEN.blit(lsurf, lrect) I haven't examined this but have used sprite groups to draw many things with one py call, and would guess that such individual blitting might be a bottleneck. Dunno if using e.g. spritegroups there would actually help. If such blitting is indeed slow, Psyco won't help, didn't test that (yet). In our project I started to use Lepton for particles to have the movement code in native code, expected pure py to be too slow there. Also that falling object movement code seems like something you could do with numpy to have it efficiently: when you do same op for a lot of objects, just using individual data (the individual pos and move vel), you can do it with arrays. But the array approach is not perhaps easy at all for a beginning programmer to use. So it is like was said in an earlier thread on this list .. in c or other compiled langs you can write more 'stupid' (no insults meant here!) code and it's still fast enough, whereas for py to be efficient for heavy things you must do it cleverly. Dunno if it will be JITting ala Psyco or easier-than-c(++) compiled langs like shedskin (a py - c++ generator) or d (a friendlier c++) which will help. Or whether we should indeed use numpy for such stuff. ~Toni again, stopping these rants and explorations now. -- Visit my blog at http://oddco.ca/zeroth/zblog
Re: [pygame] Pygame games run slowly :(
I haven't actually profiled it yet. This was a bit of mental exercise in the morning. I would certainly check if it is faster. Generally list comprehensions will offer 2 to 50x speed improvement from my own experience, and yes, I did that with profiling. So the costs of building a list and the lambda functions are rather small, and are significantly faster than executing a block of python code in a python-speed loop. Unfortunately, if Python did real compile-time optimizations, then those lambda functions would be treated as inline, and the if conditionals optimized out. That would be really optimized. Python doesn't do either of these with the bytecode. (Just checked module dis, it doesn't but the lambda form is three bytecode operations smaller). The problem is that Python's iteration is really really slow. Eliminate the bottle-neck by using C's optimized loops and we can now focus on the bottle neck of the blit and tick functions. -Tyler On Thu, Jul 30, 2009 at 8:46 AM, Casey Duncan ca...@pandora.com wrote: Before I believe you actually optimized things, how does the timing of your new code compare to the original (timeit is your friend)? Since your lambdas add additional function call overhead, and the list comprehension adds the cost to build a list, I would not assume this is faster. -Casey On Jul 30, 2009, at 8:32 AM, Tyler Laing wrote: Hi, Well the first optimization that can be done is to use a lambda function and a list comprehension which performs the for loop at C speed will likely bring a huge benefit: #we use wrappers because blit and tick only return none, which makes functional programming a bit harder... f=lambda y: y if y.tick() else y g=lambda z: z.blit(SCREEN, -CAMERA_X) particles =[lambda x: f(x) if g(x) else f(x) for x in particles] Et voila! C-speed execution, O(n) run-time. All it looses is readability, and there's the slight overhead of the two lambda functions... and yes, that else clause is needed in there. Of course for actual production code, I'd assume one would use far more descriptive variables than I did. This works because lambda functions can use if conditions as their expression, so the syntax for that is: lambda argument list: expression A if conditional else expression B Expression A is executed if the conditional is true, and expression B is executed if the conditional is false. So we use the conditional to perform an action, and that action will naturally return None(iirc about blit and tick), which causes expression B to be performed. Since expr A and B are the same, we just perform the conditional, and then do expr B. Unfortunately Python doesn't optimize that though. And in expr B, we use the same structure again, to return the particle to ensure our list has all of its processed particles. In a real compiler, that if else construction would be eliminated. :/ Isn't python awesome? -Tyler On Thu, Jul 30, 2009 at 6:53 AM, Toni Alatalo ant...@kyperjokki.fi wrote: Toni Alatalo kirjoitti: As for the slow game in question (http://www.pygame.org/project/596/) the game designer does say Thanks! And yes, framerate is definitely an issue on (dare I say) lower-end computers runs on this ~1Ghz celeron laptop, and perhaps how on a 1.3Ghz G4 mac, and perhaps even profile out of curiousity Arderyst seemed like a nice game, tested a little now, will perhaps play more with my son some time later :) The old celeron laptop was actually a whopping 1.6GHz and the game is choppy there with all the (nice!) gfx options on, it event notes about it. Ran the py2exed version now and don't have profiling tools at hand so didn't go there yet, but read some of the source after had seen when it gets slow, and it seems to do particles and moving decoration objects so that they are not only written in pure py and iterated in pyindividually for every frame, but there is even a separate blit call for every particle: in play_level.py ln 849: def Particle_Tick(particles): for particle in particles: particle.blit(SCREEN, -CAMERA_X) particle.tick() .. with some logic and movement code in both those methods of the Particle class, and eventually a pygame blit. same seems to be the case with decorative falling objects, in play_level.py ln 1905 def blit_falling_bg_objs(THISFLIP): for fallingbgobj in FALLINGBGOBJARRAY: (...) lrect.center = (fallingbgobj[1] - CAMERA_X + math.sin(fallingbgobj[0])*fallingbgobj[3]*10, fallingbgobj[2]) SCREEN.blit(lsurf, lrect) I haven't examined this but have used sprite groups to draw many things with one py call, and would guess that such individual blitting might be a bottleneck. Dunno if using e.g. spritegroups there would actually help. If such blitting is indeed slow, Psyco won't help, didn't test that (yet). In our project I started to use Lepton for particles to have the movement code in native code, expected pure py to be too slow there. Also
Re: [pygame] how to remove spam comments in pygame wiki
It's harder to read because the page is narrower.
[pygame] Improving pygame web docs
jug wrote: http://pygameweb.no-ip.org/docs/surface.html ist not really easy to read, but I don't know exactly why. It looks all right to me, except for one thing: Every link to the docs for a method embedded in the text seems to be followed by a comment in small print, e.g. in the paragraph about Surface.convert, ...arguments can be used, similar to the pygame.Surface - [pygame object for representing images] call... IMO these embedded comments are pointless and distracting and make the text hard to read. Just make the method name into a link and leave it at that. Also a minor suggestion would be to leave some space between the heading for a method and its call prototypes, and between the prototypes and the following text, e.g. instead of Surface.convert - change the pixel format of an image Surface.convert(Surface): return Surface Surface.convert(depth, flags=0): return Surface Surface.convert(masks, flags=0): return Surface Surface.convert(): return Surface Creates a new copy of the Surface with the pixel format changed. The new pixel format can... space it out slightly: Surface.convert - change the pixel format of an image Surface.convert(Surface): return Surface Surface.convert(depth, flags=0): return Surface Surface.convert(masks, flags=0): return Surface Surface.convert(): return Surface Creates a new copy of the Surface with the pixel format changed. The new pixel format can... Also generally leave space between paragraphs if you're not going to indent the first line of each paragraph. Otherwise the text tends to look like one huge paragraph, which is not good for reading. -- Greg
Re: [pygame] Improving pygame web docs
The background is too busy, IMHO And I agree with what greg wrote... Otherwise, looking good :) On Thu, Jul 30, 2009 at 7:55 PM, Greg Ewing greg.ew...@canterbury.ac.nzwrote: jug wrote: http://pygameweb.no-ip.org/docs/surface.html ist not really easy to read, but I don't know exactly why. It looks all right to me, except for one thing: Every link to the docs for a method embedded in the text seems to be followed by a comment in small print, e.g. in the paragraph about Surface.convert, ...arguments can be used, similar to the pygame.Surface - [pygame object for representing images] call... IMO these embedded comments are pointless and distracting and make the text hard to read. Just make the method name into a link and leave it at that. Also a minor suggestion would be to leave some space between the heading for a method and its call prototypes, and between the prototypes and the following text, e.g. instead of Surface.convert - change the pixel format of an image Surface.convert(Surface): return Surface Surface.convert(depth, flags=0): return Surface Surface.convert(masks, flags=0): return Surface Surface.convert(): return Surface Creates a new copy of the Surface with the pixel format changed. The new pixel format can... space it out slightly: Surface.convert - change the pixel format of an image Surface.convert(Surface): return Surface Surface.convert(depth, flags=0): return Surface Surface.convert(masks, flags=0): return Surface Surface.convert(): return Surface Creates a new copy of the Surface with the pixel format changed. The new pixel format can... Also generally leave space between paragraphs if you're not going to indent the first line of each paragraph. Otherwise the text tends to look like one huge paragraph, which is not good for reading. -- Greg
