Re: [pygame] pygame performance limits
The short answer is you don't really have limits. Unless you're doing something slow / inefficient, that would be slow anway. Brute forcing / re-creating surface every frame / mixing different formats on your surfaces / etc. Biggest one I'd think is collision detection. You can make your algorithm more efficient / use quadtrees / or probably use a physics module. Depending on the game, that can be overkill. == But remember, 'premature optimization, is the root of all evil'. And when you optimize, use profiling. Because 99% of the slowdown can be in 1% of the code. And you will rarely know where it is, without profiling. This can be true even in simpler code. == If you do reach a slowdown, there's a huge amount of modules that you have access to. That causes the slower code to run c-code, and has been optimized by many people ie: PyOpenGL, pybox2d (physics), numpy (for arrays / 3d math / opengl), pygame, etc... So between optimizing your algorithms ( That you'd have to do in other languages anyway: Not re-allocating textures every frame, or other errors ), using c-code from other libraries, You don't run into much different speed issues than you do in pure c, for most games you'd work on. -- Jake
Re: [pygame] pygame performance limits
On Nov 23, 2011, at 10:35 AM, Nick Arnoeyts wrote: Yeah, I'm probably worrying prematurely. I'm very easily influenced by FUD and there are a lot of messages floating around that Python (and Ruby) are too slow for making games. Since I started programming thirty years ago, and probably for the thirty years before that, people have ALWAYS complained that high level languages are TOO SLOW and USE TOO MUCH MEMORY. Note that the definition of high level has changed over the years, but suffice it to say, pretty much every single programming language has been subjected to this complaint, from Python to Lisp, even FORTRAN. The exception to the rule: C, because it was originally designed to be a very thin layer on top of assembler. (C actually does add code, and slow down your program, to do fancy things like make array references work like you think they do.) There's also this false economy -- if you write your code in fewer characters, it'll run faster -- which eventually led to the obfuscated C contest. This is entirely false -- unless your compiler is absolute crap, it will optimize your programs just the same, whether they are 10 lines or 1. Indeed, if you spend a lot of time reducing your code to the bare minimum, it is more likely you will write incorrect code. This is so prevalent that Kernighan and Plauger, who were some of the first people to work on Unix and C, wrote a book called The Elements of Programming Style, where they repeatedly hammered the idea that clever code is a terrible idea. == Knuth later said, Premature Optimization is the root of all evil. == To a certain extent, C++ also is not regarded as big or slow, but that's ONLY IF you give up the good stuff that makes it powerful: you can still have object-oriented programming, but not certain powerful features of inheritance! So in reality, for most code, C++ is not much faster. The simple fact is this: For most high-level languages, you sacrifice some percentage of your CPU and your memory space, and in return, YOU SHIP COMPLETE PROGRAMS SOONER. You can find and fix bugs SOONER, and add new features (because your users get to mess around and figure out what the REALLY want) SOONER. Making user wait while you screw around with your clever optimizations, then deal with the bugs those introduced, is silly, especially because modern computers are, actually, THOUSANDS of times faster than those of even 10 years ago. And users don't care if your program takes 250 KB or 1MB, because you have have many times that amount of images and sounds. Now, of course, when you have a super-high-level language, like PyGame, and it's running in an interpreted language like Python, you will run out of power much sooner than you would in a language like C, especially on a phone computer. This, however, is no reason to stop using PyGame -- it's a reason to improve PyGame. Improvements require a lot of technical knowledge, skill, and effort, but they benefit MANY.
Re: [pygame] pygame performance limits
Now, of course, when you have a super-high-level language, like PyGame, and it's running in an interpreted language like Python, you will run out of power much sooner than you would in a language like C, especially on a phone computer. This, however, is no reason to stop using PyGame -- it's a reason to improve PyGame. Improvements require a lot of technical knowledge, skill, and effort, but they benefit MANY. Pygame is a library, not a language. ;) And much of it is written in C. I very much agree with everything you said, though. What's particularly interesting is, as Psyco and PyPy have shown, higher-level languages can be almost as fast as or sometimes even faster than lower-level languages.
Re: [pygame] pygame performance limits
On Nov 24, 2011, at 3:55 PM, Julian Marchant wrote: Now, of course, when you have a super-high-level language, like PyGame, and it's running in an interpreted language like Python, you will run out of power much sooner than you would in a language like C, especially on a phone computer. This, however, is no reason to stop using PyGame -- it's a reason to improve PyGame. Improvements require a lot of technical knowledge, skill, and effort, but they benefit MANY. Pygame is a library, not a language. ;) And much of it is written in C. I very much agree with everything you said, though. What's particularly interesting is, as Psyco and PyPy have shown, higher-level languages can be almost as fast as or sometimes even faster than lower-level languages. Oh, agreed. I have some pals that work on Haskell and whenever they beat C++ in a benchmark, they go drinking. Which is pretty darn often, actually. It's really about the work that is done on the compiler/interpreter/libraries. Of course, the MOST important thing is to choose a fast computer. The SECOND most important thing is to choose a fast algorithm. And the THIRD most important thing is to write clean, straightforward code, so that the compiler/interpreter can auto-optimize it for whichever hardware it's running on. Once you've done that, THEN you can decide if further performance improvements are necessary, and use diagnostic tools to find out where all your speed went.
Re: [pygame] pygame performance limits
You can't really compare the language C++ with the library Python. You could compare C++ / SDL with Python / Pygame, and probably C++ would be faster (but maybe by not as much as you think)... but it would certainly take a lot more time to write the code. As to what you can do with Pygame, well it is a 2D library that I find fast enough for most things. In some ways I think Pygame is a little 'old-school': Pygame does not do a lot for you, but it gets out of the way, and perhaps most importantly, it's small enough to fit in my mind but big enough to do what I want. Unless you develop as part of a team you need 3D, you are unlikely to choose a project that Pygame cannot handle in some way. Perhaps you could tell us more about what you wanted to write... that would make it easier to tell you if Pygame could do this for you. Chris On 23 November 2011 21:07, Nick Arnoeyts nickarnoe...@gmail.com wrote: Hey everyone I was wondering what the limits of pygame performance are. What is the absolute maximum kind of game that can be written with it, and what kinds of things are better done in pure C++ than python? This is probably a question that's asked periodically on the mailing list, so I apologize in advance. Yours truly Armor Nick
Re: [pygame] pygame performance limits
I'm actually not quite sure what I'm going to write yet. Either an RPG in the style of SNES-era Final Fantasy, or a visual novel (if you know Higurashi or Clannad). I'm not (yet) interested in 3D and I would certainly do something like that in C++. Pygame is probably fast enough for the graphics, but I was wondering how performance would be for AI and other calculations. yours truly armornick 2011/11/23 Chris Smith maximi...@gmail.com You can't really compare the language C++ with the library Python. You could compare C++ / SDL with Python / Pygame, and probably C++ would be faster (but maybe by not as much as you think)... but it would certainly take a lot more time to write the code. As to what you can do with Pygame, well it is a 2D library that I find fast enough for most things. In some ways I think Pygame is a little 'old-school': Pygame does not do a lot for you, but it gets out of the way, and perhaps most importantly, it's small enough to fit in my mind but big enough to do what I want. Unless you develop as part of a team you need 3D, you are unlikely to choose a project that Pygame cannot handle in some way. Perhaps you could tell us more about what you wanted to write... that would make it easier to tell you if Pygame could do this for you. Chris On 23 November 2011 21:07, Nick Arnoeyts nickarnoe...@gmail.com wrote: Hey everyone I was wondering what the limits of pygame performance are. What is the absolute maximum kind of game that can be written with it, and what kinds of things are better done in pure C++ than python? This is probably a question that's asked periodically on the mailing list, so I apologize in advance. Yours truly Armor Nick
Re: [pygame] pygame performance limits
You can use Renpy for graphic novels. SNES RPG's would be no problem. For AI and other things, python might be slow but you will probably be surprised how far you can go with it. It'll certainly be easier than going the C++ route (although I'm not a C++ fan, to be honest... I'd use Lisp if I needed the code to be faster). On 23 November 2011 21:47, Nick Arnoeyts nickarnoe...@gmail.com wrote: I'm actually not quite sure what I'm going to write yet. Either an RPG in the style of SNES-era Final Fantasy, or a visual novel (if you know Higurashi or Clannad). I'm not (yet) interested in 3D and I would certainly do something like that in C++. Pygame is probably fast enough for the graphics, but I was wondering how performance would be for AI and other calculations. yours truly armornick 2011/11/23 Chris Smith maximi...@gmail.com You can't really compare the language C++ with the library Python. You could compare C++ / SDL with Python / Pygame, and probably C++ would be faster (but maybe by not as much as you think)... but it would certainly take a lot more time to write the code. As to what you can do with Pygame, well it is a 2D library that I find fast enough for most things. In some ways I think Pygame is a little 'old-school': Pygame does not do a lot for you, but it gets out of the way, and perhaps most importantly, it's small enough to fit in my mind but big enough to do what I want. Unless you develop as part of a team you need 3D, you are unlikely to choose a project that Pygame cannot handle in some way. Perhaps you could tell us more about what you wanted to write... that would make it easier to tell you if Pygame could do this for you. Chris On 23 November 2011 21:07, Nick Arnoeyts nickarnoe...@gmail.com wrote: Hey everyone I was wondering what the limits of pygame performance are. What is the absolute maximum kind of game that can be written with it, and what kinds of things are better done in pure C++ than python? This is probably a question that's asked periodically on the mailing list, so I apologize in advance. Yours truly Armor Nick
Re: [pygame] pygame performance limits
Hi, Armor Nick. Some common bottlenecks I've encountered: rendering many images per frame brute force collision checking computationally intensive logic and AI real-time image transformation heavy usage of images with SRCALPHA 2D and 2.5D layering particles These are easy limits to hit early on especially in scrollers, platformers, and bullet hell type games, or when you start adding environment and GFX. But there are clever techniques that pygamers have developed to deal with them in the form of cookbook recipes, libraries, and modules. Many issues can be easily mitigated by selecting a culling technique or two to reduce the number of things processed each game loop. Some people popping into IRC lately seem easily frustrated by these challenges, wanting an inefficient workload to just perform well. I can understand the sentiment. But I personally get an immense amount of pleasure from conquering these challenges. :) When I started pygame three years ago I was told you can't do a scrolling action-RPG: it's too much work for the CPU. Since then, computers became a significantly faster and several people have produced reasonably impressive action-RPGs, as well as other genre. For some examples one only has to look among the top places at pyweek.org, where pygame competes with the likes of pyglet, cocos2d, and rabbyt, all of which have the proclaimed advantage of 3D acceleration. It's become clear to me that for most hobby games the only real limitation is the resourcefulness of the programmer. I personally haven't yet hit a wall with Python or pygame that forced me to look at another framework or a natively compiled language, and I've done a few relatively ambitious projects. That may seem like a biased representation of Python's and pygame's capabilities, but I assure you it's not. A few times a year my eyes wander to other game development libraries or engines, but I keep coming right back to pygame. Hope that perspective helps. Gumm On Wed, Nov 23, 2011 at 6:08 AM, Chris Smith maximi...@gmail.com wrote: You can use Renpy for graphic novels. SNES RPG's would be no problem. For AI and other things, python might be slow but you will probably be surprised how far you can go with it. It'll certainly be easier than going the C++ route (although I'm not a C++ fan, to be honest... I'd use Lisp if I needed the code to be faster). On 23 November 2011 21:47, Nick Arnoeyts nickarnoe...@gmail.com wrote: I'm actually not quite sure what I'm going to write yet. Either an RPG in the style of SNES-era Final Fantasy, or a visual novel (if you know Higurashi or Clannad). I'm not (yet) interested in 3D and I would certainly do something like that in C++. Pygame is probably fast enough for the graphics, but I was wondering how performance would be for AI and other calculations. yours truly armornick 2011/11/23 Chris Smith maximi...@gmail.com You can't really compare the language C++ with the library Python. You could compare C++ / SDL with Python / Pygame, and probably C++ would be faster (but maybe by not as much as you think)... but it would certainly take a lot more time to write the code. As to what you can do with Pygame, well it is a 2D library that I find fast enough for most things. In some ways I think Pygame is a little 'old-school': Pygame does not do a lot for you, but it gets out of the way, and perhaps most importantly, it's small enough to fit in my mind but big enough to do what I want. Unless you develop as part of a team you need 3D, you are unlikely to choose a project that Pygame cannot handle in some way. Perhaps you could tell us more about what you wanted to write... that would make it easier to tell you if Pygame could do this for you. Chris On 23 November 2011 21:07, Nick Arnoeyts nickarnoe...@gmail.com wrote: Hey everyone I was wondering what the limits of pygame performance are. What is the absolute maximum kind of game that can be written with it, and what kinds of things are better done in pure C++ than python? This is probably a question that's asked periodically on the mailing list, so I apologize in advance. Yours truly Armor Nick
Re: [pygame] pygame performance limits
Alright. Thanks for your reply everyone. I'm currently still working on a Ren'py project, but I'm probably going to try pygame once that's finished. I'm mostly making visual novels, though, so it's possible that I'm staying with ren'py until I reach its limits. yours truly armornick 2011/11/23 stabbingfinger stabbingfin...@gmail.com Hi, Armor Nick. Some common bottlenecks I've encountered: rendering many images per frame brute force collision checking computationally intensive logic and AI real-time image transformation heavy usage of images with SRCALPHA 2D and 2.5D layering particles These are easy limits to hit early on especially in scrollers, platformers, and bullet hell type games, or when you start adding environment and GFX. But there are clever techniques that pygamers have developed to deal with them in the form of cookbook recipes, libraries, and modules. Many issues can be easily mitigated by selecting a culling technique or two to reduce the number of things processed each game loop. Some people popping into IRC lately seem easily frustrated by these challenges, wanting an inefficient workload to just perform well. I can understand the sentiment. But I personally get an immense amount of pleasure from conquering these challenges. :) When I started pygame three years ago I was told you can't do a scrolling action-RPG: it's too much work for the CPU. Since then, computers became a significantly faster and several people have produced reasonably impressive action-RPGs, as well as other genre. For some examples one only has to look among the top places at pyweek.org, where pygame competes with the likes of pyglet, cocos2d, and rabbyt, all of which have the proclaimed advantage of 3D acceleration. It's become clear to me that for most hobby games the only real limitation is the resourcefulness of the programmer. I personally haven't yet hit a wall with Python or pygame that forced me to look at another framework or a natively compiled language, and I've done a few relatively ambitious projects. That may seem like a biased representation of Python's and pygame's capabilities, but I assure you it's not. A few times a year my eyes wander to other game development libraries or engines, but I keep coming right back to pygame. Hope that perspective helps. Gumm On Wed, Nov 23, 2011 at 6:08 AM, Chris Smith maximi...@gmail.com wrote: You can use Renpy for graphic novels. SNES RPG's would be no problem. For AI and other things, python might be slow but you will probably be surprised how far you can go with it. It'll certainly be easier than going the C++ route (although I'm not a C++ fan, to be honest... I'd use Lisp if I needed the code to be faster). On 23 November 2011 21:47, Nick Arnoeyts nickarnoe...@gmail.com wrote: I'm actually not quite sure what I'm going to write yet. Either an RPG in the style of SNES-era Final Fantasy, or a visual novel (if you know Higurashi or Clannad). I'm not (yet) interested in 3D and I would certainly do something like that in C++. Pygame is probably fast enough for the graphics, but I was wondering how performance would be for AI and other calculations. yours truly armornick 2011/11/23 Chris Smith maximi...@gmail.com You can't really compare the language C++ with the library Python. You could compare C++ / SDL with Python / Pygame, and probably C++ would be faster (but maybe by not as much as you think)... but it would certainly take a lot more time to write the code. As to what you can do with Pygame, well it is a 2D library that I find fast enough for most things. In some ways I think Pygame is a little 'old-school': Pygame does not do a lot for you, but it gets out of the way, and perhaps most importantly, it's small enough to fit in my mind but big enough to do what I want. Unless you develop as part of a team you need 3D, you are unlikely to choose a project that Pygame cannot handle in some way. Perhaps you could tell us more about what you wanted to write... that would make it easier to tell you if Pygame could do this for you. Chris On 23 November 2011 21:07, Nick Arnoeyts nickarnoe...@gmail.comwrote: Hey everyone I was wondering what the limits of pygame performance are. What is the absolute maximum kind of game that can be written with it, and what kinds of things are better done in pure C++ than python? This is probably a question that's asked periodically on the mailing list, so I apologize in advance. Yours truly Armor Nick
Re: [pygame] pygame performance limits
I don't know why you would be concerned about performance in a visual novel game. Aren't they pretty undemanding? I haven't played these games very much, but isn't it just a series of still images (no animations) and a simple GUI? You might want to look at a pyweek entry called Gregor Samsa. I know that team put some effort into optimizing things and wound up with a respectable framerate even on mobile devices running Android: http://www.pyweek.org/e/tihoas/ But again, I feel like performance is the least of your concerns if that's your kind of game. If there's some specific thing you're expecting to cause low performance, maybe you can ask about it specifically. Good luck! -Christopher On Wed, Nov 23, 2011 at 11:46 AM, Nick Arnoeyts nickarnoe...@gmail.comwrote: Alright. Thanks for your reply everyone. I'm currently still working on a Ren'py project, but I'm probably going to try pygame once that's finished. I'm mostly making visual novels, though, so it's possible that I'm staying with ren'py until I reach its limits. yours truly armornick 2011/11/23 stabbingfinger stabbingfin...@gmail.com Hi, Armor Nick. Some common bottlenecks I've encountered: rendering many images per frame brute force collision checking computationally intensive logic and AI real-time image transformation heavy usage of images with SRCALPHA 2D and 2.5D layering particles These are easy limits to hit early on especially in scrollers, platformers, and bullet hell type games, or when you start adding environment and GFX. But there are clever techniques that pygamers have developed to deal with them in the form of cookbook recipes, libraries, and modules. Many issues can be easily mitigated by selecting a culling technique or two to reduce the number of things processed each game loop. Some people popping into IRC lately seem easily frustrated by these challenges, wanting an inefficient workload to just perform well. I can understand the sentiment. But I personally get an immense amount of pleasure from conquering these challenges. :) When I started pygame three years ago I was told you can't do a scrolling action-RPG: it's too much work for the CPU. Since then, computers became a significantly faster and several people have produced reasonably impressive action-RPGs, as well as other genre. For some examples one only has to look among the top places at pyweek.org, where pygame competes with the likes of pyglet, cocos2d, and rabbyt, all of which have the proclaimed advantage of 3D acceleration. It's become clear to me that for most hobby games the only real limitation is the resourcefulness of the programmer. I personally haven't yet hit a wall with Python or pygame that forced me to look at another framework or a natively compiled language, and I've done a few relatively ambitious projects. That may seem like a biased representation of Python's and pygame's capabilities, but I assure you it's not. A few times a year my eyes wander to other game development libraries or engines, but I keep coming right back to pygame. Hope that perspective helps. Gumm On Wed, Nov 23, 2011 at 6:08 AM, Chris Smith maximi...@gmail.com wrote: You can use Renpy for graphic novels. SNES RPG's would be no problem. For AI and other things, python might be slow but you will probably be surprised how far you can go with it. It'll certainly be easier than going the C++ route (although I'm not a C++ fan, to be honest... I'd use Lisp if I needed the code to be faster). On 23 November 2011 21:47, Nick Arnoeyts nickarnoe...@gmail.com wrote: I'm actually not quite sure what I'm going to write yet. Either an RPG in the style of SNES-era Final Fantasy, or a visual novel (if you know Higurashi or Clannad). I'm not (yet) interested in 3D and I would certainly do something like that in C++. Pygame is probably fast enough for the graphics, but I was wondering how performance would be for AI and other calculations. yours truly armornick 2011/11/23 Chris Smith maximi...@gmail.com You can't really compare the language C++ with the library Python. You could compare C++ / SDL with Python / Pygame, and probably C++ would be faster (but maybe by not as much as you think)... but it would certainly take a lot more time to write the code. As to what you can do with Pygame, well it is a 2D library that I find fast enough for most things. In some ways I think Pygame is a little 'old-school': Pygame does not do a lot for you, but it gets out of the way, and perhaps most importantly, it's small enough to fit in my mind but big enough to do what I want. Unless you develop as part of a team you need 3D, you are unlikely to choose a project that Pygame cannot handle in some way. Perhaps you could tell us more about what you wanted to write... that would make it easier to tell you if Pygame could do this for you. Chris On 23 November 2011 21:07, Nick Arnoeyts
Re: [pygame] pygame performance limits
Yeah, I'm probably worrying prematurely. I'm very easily influenced by FUD and there are a lot of messages floating around that Python (and Ruby) are too slow for making games. yours truly armornick 2011/11/23 Christopher Night cosmologi...@gmail.com I don't know why you would be concerned about performance in a visual novel game. Aren't they pretty undemanding? I haven't played these games very much, but isn't it just a series of still images (no animations) and a simple GUI? You might want to look at a pyweek entry called Gregor Samsa. I know that team put some effort into optimizing things and wound up with a respectable framerate even on mobile devices running Android: http://www.pyweek.org/e/tihoas/ But again, I feel like performance is the least of your concerns if that's your kind of game. If there's some specific thing you're expecting to cause low performance, maybe you can ask about it specifically. Good luck! -Christopher On Wed, Nov 23, 2011 at 11:46 AM, Nick Arnoeyts nickarnoe...@gmail.comwrote: Alright. Thanks for your reply everyone. I'm currently still working on a Ren'py project, but I'm probably going to try pygame once that's finished. I'm mostly making visual novels, though, so it's possible that I'm staying with ren'py until I reach its limits. yours truly armornick 2011/11/23 stabbingfinger stabbingfin...@gmail.com Hi, Armor Nick. Some common bottlenecks I've encountered: rendering many images per frame brute force collision checking computationally intensive logic and AI real-time image transformation heavy usage of images with SRCALPHA 2D and 2.5D layering particles These are easy limits to hit early on especially in scrollers, platformers, and bullet hell type games, or when you start adding environment and GFX. But there are clever techniques that pygamers have developed to deal with them in the form of cookbook recipes, libraries, and modules. Many issues can be easily mitigated by selecting a culling technique or two to reduce the number of things processed each game loop. Some people popping into IRC lately seem easily frustrated by these challenges, wanting an inefficient workload to just perform well. I can understand the sentiment. But I personally get an immense amount of pleasure from conquering these challenges. :) When I started pygame three years ago I was told you can't do a scrolling action-RPG: it's too much work for the CPU. Since then, computers became a significantly faster and several people have produced reasonably impressive action-RPGs, as well as other genre. For some examples one only has to look among the top places at pyweek.org, where pygame competes with the likes of pyglet, cocos2d, and rabbyt, all of which have the proclaimed advantage of 3D acceleration. It's become clear to me that for most hobby games the only real limitation is the resourcefulness of the programmer. I personally haven't yet hit a wall with Python or pygame that forced me to look at another framework or a natively compiled language, and I've done a few relatively ambitious projects. That may seem like a biased representation of Python's and pygame's capabilities, but I assure you it's not. A few times a year my eyes wander to other game development libraries or engines, but I keep coming right back to pygame. Hope that perspective helps. Gumm On Wed, Nov 23, 2011 at 6:08 AM, Chris Smith maximi...@gmail.comwrote: You can use Renpy for graphic novels. SNES RPG's would be no problem. For AI and other things, python might be slow but you will probably be surprised how far you can go with it. It'll certainly be easier than going the C++ route (although I'm not a C++ fan, to be honest... I'd use Lisp if I needed the code to be faster). On 23 November 2011 21:47, Nick Arnoeyts nickarnoe...@gmail.comwrote: I'm actually not quite sure what I'm going to write yet. Either an RPG in the style of SNES-era Final Fantasy, or a visual novel (if you know Higurashi or Clannad). I'm not (yet) interested in 3D and I would certainly do something like that in C++. Pygame is probably fast enough for the graphics, but I was wondering how performance would be for AI and other calculations. yours truly armornick 2011/11/23 Chris Smith maximi...@gmail.com You can't really compare the language C++ with the library Python. You could compare C++ / SDL with Python / Pygame, and probably C++ would be faster (but maybe by not as much as you think)... but it would certainly take a lot more time to write the code. As to what you can do with Pygame, well it is a 2D library that I find fast enough for most things. In some ways I think Pygame is a little 'old-school': Pygame does not do a lot for you, but it gets out of the way, and perhaps most importantly, it's small enough to fit in my mind but big enough to do what I want. Unless you develop as part of a team you need 3D, you are unlikely
Re: [pygame] pygame performance limits
Whoever said that didn't do a good job distinguishing between casual games and huge professional games. Presumably they would also say that Flash is too slow for making games, but that doesn't stop people from making Flash games. My very rough estimate is that you can easily get Flash-level performance from python+Pygame, and with some work you can get better-than-Flash-level performance. You're unlikely to get C++-level performance without a lot of work, though. Python may be too slow to write Portal 3 or something, but I've never seen a Flash game that I thought python couldn't handle (if someone would write a good vector graphics library for it). -Christopher On Wed, Nov 23, 2011 at 1:35 PM, Nick Arnoeyts nickarnoe...@gmail.comwrote: Yeah, I'm probably worrying prematurely. I'm very easily influenced by FUD and there are a lot of messages floating around that Python (and Ruby) are too slow for making games. yours truly armornick 2011/11/23 Christopher Night cosmologi...@gmail.com I don't know why you would be concerned about performance in a visual novel game. Aren't they pretty undemanding? I haven't played these games very much, but isn't it just a series of still images (no animations) and a simple GUI? You might want to look at a pyweek entry called Gregor Samsa. I know that team put some effort into optimizing things and wound up with a respectable framerate even on mobile devices running Android: http://www.pyweek.org/e/tihoas/ But again, I feel like performance is the least of your concerns if that's your kind of game. If there's some specific thing you're expecting to cause low performance, maybe you can ask about it specifically. Good luck! -Christopher On Wed, Nov 23, 2011 at 11:46 AM, Nick Arnoeyts nickarnoe...@gmail.comwrote: Alright. Thanks for your reply everyone. I'm currently still working on a Ren'py project, but I'm probably going to try pygame once that's finished. I'm mostly making visual novels, though, so it's possible that I'm staying with ren'py until I reach its limits. yours truly armornick 2011/11/23 stabbingfinger stabbingfin...@gmail.com Hi, Armor Nick. Some common bottlenecks I've encountered: rendering many images per frame brute force collision checking computationally intensive logic and AI real-time image transformation heavy usage of images with SRCALPHA 2D and 2.5D layering particles These are easy limits to hit early on especially in scrollers, platformers, and bullet hell type games, or when you start adding environment and GFX. But there are clever techniques that pygamers have developed to deal with them in the form of cookbook recipes, libraries, and modules. Many issues can be easily mitigated by selecting a culling technique or two to reduce the number of things processed each game loop. Some people popping into IRC lately seem easily frustrated by these challenges, wanting an inefficient workload to just perform well. I can understand the sentiment. But I personally get an immense amount of pleasure from conquering these challenges. :) When I started pygame three years ago I was told you can't do a scrolling action-RPG: it's too much work for the CPU. Since then, computers became a significantly faster and several people have produced reasonably impressive action-RPGs, as well as other genre. For some examples one only has to look among the top places at pyweek.org, where pygame competes with the likes of pyglet, cocos2d, and rabbyt, all of which have the proclaimed advantage of 3D acceleration. It's become clear to me that for most hobby games the only real limitation is the resourcefulness of the programmer. I personally haven't yet hit a wall with Python or pygame that forced me to look at another framework or a natively compiled language, and I've done a few relatively ambitious projects. That may seem like a biased representation of Python's and pygame's capabilities, but I assure you it's not. A few times a year my eyes wander to other game development libraries or engines, but I keep coming right back to pygame. Hope that perspective helps. Gumm On Wed, Nov 23, 2011 at 6:08 AM, Chris Smith maximi...@gmail.comwrote: You can use Renpy for graphic novels. SNES RPG's would be no problem. For AI and other things, python might be slow but you will probably be surprised how far you can go with it. It'll certainly be easier than going the C++ route (although I'm not a C++ fan, to be honest... I'd use Lisp if I needed the code to be faster). On 23 November 2011 21:47, Nick Arnoeyts nickarnoe...@gmail.comwrote: I'm actually not quite sure what I'm going to write yet. Either an RPG in the style of SNES-era Final Fantasy, or a visual novel (if you know Higurashi or Clannad). I'm not (yet) interested in 3D and I would certainly do something like that in C++. Pygame is probably fast enough for the graphics, but I was wondering how performance
Re: [pygame] pygame performance limits
Hi, Also, you can do some pretty cool 3D stuff with opengl, since a lot of the hard work is done in shaders on the GPU. So using python is ok. Check out some of the awesome 3d stuff Ian Mallett has done: http://pygame.org/tags/geometrian These action 2d games are fairly intensive: http://pygame.org/project/596/ http://pygame.org/project/991/ On Wed, Nov 23, 2011 at 8:01 PM, Christopher Night cosmologi...@gmail.comwrote: Whoever said that didn't do a good job distinguishing between casual games and huge professional games. Presumably they would also say that Flash is too slow for making games, but that doesn't stop people from making Flash games. My very rough estimate is that you can easily get Flash-level performance from python+Pygame, and with some work you can get better-than-Flash-level performance. You're unlikely to get C++-level performance without a lot of work, though. Python may be too slow to write Portal 3 or something, but I've never seen a Flash game that I thought python couldn't handle (if someone would write a good vector graphics library for it). -Christopher On Wed, Nov 23, 2011 at 1:35 PM, Nick Arnoeyts nickarnoe...@gmail.comwrote: Yeah, I'm probably worrying prematurely. I'm very easily influenced by FUD and there are a lot of messages floating around that Python (and Ruby) are too slow for making games. yours truly armornick 2011/11/23 Christopher Night cosmologi...@gmail.com I don't know why you would be concerned about performance in a visual novel game. Aren't they pretty undemanding? I haven't played these games very much, but isn't it just a series of still images (no animations) and a simple GUI? You might want to look at a pyweek entry called Gregor Samsa. I know that team put some effort into optimizing things and wound up with a respectable framerate even on mobile devices running Android: http://www.pyweek.org/e/tihoas/ But again, I feel like performance is the least of your concerns if that's your kind of game. If there's some specific thing you're expecting to cause low performance, maybe you can ask about it specifically. Good luck! -Christopher On Wed, Nov 23, 2011 at 11:46 AM, Nick Arnoeyts nickarnoe...@gmail.comwrote: Alright. Thanks for your reply everyone. I'm currently still working on a Ren'py project, but I'm probably going to try pygame once that's finished. I'm mostly making visual novels, though, so it's possible that I'm staying with ren'py until I reach its limits. yours truly armornick 2011/11/23 stabbingfinger stabbingfin...@gmail.com Hi, Armor Nick. Some common bottlenecks I've encountered: rendering many images per frame brute force collision checking computationally intensive logic and AI real-time image transformation heavy usage of images with SRCALPHA 2D and 2.5D layering particles These are easy limits to hit early on especially in scrollers, platformers, and bullet hell type games, or when you start adding environment and GFX. But there are clever techniques that pygamers have developed to deal with them in the form of cookbook recipes, libraries, and modules. Many issues can be easily mitigated by selecting a culling technique or two to reduce the number of things processed each game loop. Some people popping into IRC lately seem easily frustrated by these challenges, wanting an inefficient workload to just perform well. I can understand the sentiment. But I personally get an immense amount of pleasure from conquering these challenges. :) When I started pygame three years ago I was told you can't do a scrolling action-RPG: it's too much work for the CPU. Since then, computers became a significantly faster and several people have produced reasonably impressive action-RPGs, as well as other genre. For some examples one only has to look among the top places at pyweek.org, where pygame competes with the likes of pyglet, cocos2d, and rabbyt, all of which have the proclaimed advantage of 3D acceleration. It's become clear to me that for most hobby games the only real limitation is the resourcefulness of the programmer. I personally haven't yet hit a wall with Python or pygame that forced me to look at another framework or a natively compiled language, and I've done a few relatively ambitious projects. That may seem like a biased representation of Python's and pygame's capabilities, but I assure you it's not. A few times a year my eyes wander to other game development libraries or engines, but I keep coming right back to pygame. Hope that perspective helps. Gumm On Wed, Nov 23, 2011 at 6:08 AM, Chris Smith maximi...@gmail.comwrote: You can use Renpy for graphic novels. SNES RPG's would be no problem. For AI and other things, python might be slow but you will probably be surprised how far you can go with it. It'll certainly be easier than going the C++ route (although I'm not a C++ fan, to be honest... I'd use
Re: [pygame] pygame performance limits
Smart use of threads for AI should reduce performance issues... On Wed, Nov 23, 2011 at 2:10 PM, René Dudfield ren...@gmail.com wrote: Hi, Also, you can do some pretty cool 3D stuff with opengl, since a lot of the hard work is done in shaders on the GPU. So using python is ok. Check out some of the awesome 3d stuff Ian Mallett has done: http://pygame.org/tags/geometrian These action 2d games are fairly intensive: http://pygame.org/project/596/ http://pygame.org/project/991/ On Wed, Nov 23, 2011 at 8:01 PM, Christopher Night cosmologi...@gmail.com wrote: Whoever said that didn't do a good job distinguishing between casual games and huge professional games. Presumably they would also say that Flash is too slow for making games, but that doesn't stop people from making Flash games. My very rough estimate is that you can easily get Flash-level performance from python+Pygame, and with some work you can get better-than-Flash-level performance. You're unlikely to get C++-level performance without a lot of work, though. Python may be too slow to write Portal 3 or something, but I've never seen a Flash game that I thought python couldn't handle (if someone would write a good vector graphics library for it). -Christopher On Wed, Nov 23, 2011 at 1:35 PM, Nick Arnoeyts nickarnoe...@gmail.com wrote: Yeah, I'm probably worrying prematurely. I'm very easily influenced by FUD and there are a lot of messages floating around that Python (and Ruby) are too slow for making games. yours truly armornick 2011/11/23 Christopher Night cosmologi...@gmail.com I don't know why you would be concerned about performance in a visual novel game. Aren't they pretty undemanding? I haven't played these games very much, but isn't it just a series of still images (no animations) and a simple GUI? You might want to look at a pyweek entry called Gregor Samsa. I know that team put some effort into optimizing things and wound up with a respectable framerate even on mobile devices running Android: http://www.pyweek.org/e/tihoas/ But again, I feel like performance is the least of your concerns if that's your kind of game. If there's some specific thing you're expecting to cause low performance, maybe you can ask about it specifically. Good luck! -Christopher On Wed, Nov 23, 2011 at 11:46 AM, Nick Arnoeyts nickarnoe...@gmail.com wrote: Alright. Thanks for your reply everyone. I'm currently still working on a Ren'py project, but I'm probably going to try pygame once that's finished. I'm mostly making visual novels, though, so it's possible that I'm staying with ren'py until I reach its limits. yours truly armornick 2011/11/23 stabbingfinger stabbingfin...@gmail.com Hi, Armor Nick. Some common bottlenecks I've encountered: rendering many images per frame brute force collision checking computationally intensive logic and AI real-time image transformation heavy usage of images with SRCALPHA 2D and 2.5D layering particles These are easy limits to hit early on especially in scrollers, platformers, and bullet hell type games, or when you start adding environment and GFX. But there are clever techniques that pygamers have developed to deal with them in the form of cookbook recipes, libraries, and modules. Many issues can be easily mitigated by selecting a culling technique or two to reduce the number of things processed each game loop. Some people popping into IRC lately seem easily frustrated by these challenges, wanting an inefficient workload to just perform well. I can understand the sentiment. But I personally get an immense amount of pleasure from conquering these challenges. :) When I started pygame three years ago I was told you can't do a scrolling action-RPG: it's too much work for the CPU. Since then, computers became a significantly faster and several people have produced reasonably impressive action-RPGs, as well as other genre. For some examples one only has to look among the top places at pyweek.org, where pygame competes with the likes of pyglet, cocos2d, and rabbyt, all of which have the proclaimed advantage of 3D acceleration. It's become clear to me that for most hobby games the only real limitation is the resourcefulness of the programmer. I personally haven't yet hit a wall with Python or pygame that forced me to look at another framework or a natively compiled language, and I've done a few relatively ambitious projects. That may seem like a biased representation of Python's and pygame's capabilities, but I assure you it's not. A few times a year my eyes wander to other game development libraries or engines, but I keep coming right back to pygame. Hope that perspective helps. Gumm On Wed, Nov 23, 2011 at 6:08 AM, Chris Smith maximi...@gmail.com wrote: You can use Renpy for graphic novels. SNES RPG's would be no problem. For AI and other things, python might be slow but you will
Re: [pygame] pygame performance limits
Ren'py actually requires more memory than you would think.* The ease of use and robust feautures outweigh this though. The most intensive things for a visual novel would be if you wanted to use some particle effects or something. Honestly the jedit editor it comes packaged with seens to tax old machine more than any of the actual games made with Renpy :p *as in, according to PyTom (the dev) you couldn't do a direct port of Renpy to the NDS. Most PCs from the past decade, or reasonably powered Android phone, or cracked Nook, etc can run at least the normal stuff fine. At least in my experiences. Noel On Nov 23, 2011, at 11:52 AM, Christopher Night cosmologi...@gmail.com wrote: I don't know why you would be concerned about performance in a visual novel game. Aren't they pretty undemanding? I haven't played these games very much, but isn't it just a series of still images (no animations) and a simple GUI? You might want to look at a pyweek entry called Gregor Samsa. I know that team put some effort into optimizing things and wound up with a respectable framerate even on mobile devices running Android: http://www.pyweek.org/e/tihoas/ But again, I feel like performance is the least of your concerns if that's your kind of game. If there's some specific thing you're expecting to cause low performance, maybe you can ask about it specifically. Good luck! -Christopher On Wed, Nov 23, 2011 at 11:46 AM, Nick Arnoeyts nickarnoe...@gmail.com wrote: Alright. Thanks for your reply everyone. I'm currently still working on a Ren'py project, but I'm probably going to try pygame once that's finished. I'm mostly making visual novels, though, so it's possible that I'm staying with ren'py until I reach its limits. yours truly armornick 2011/11/23 stabbingfinger stabbingfin...@gmail.com Hi, Armor Nick. Some common bottlenecks I've encountered: rendering many images per frame brute force collision checking computationally intensive logic and AI real-time image transformation heavy usage of images with SRCALPHA 2D and 2.5D layering particles These are easy limits to hit early on especially in scrollers, platformers, and bullet hell type games, or when you start adding environment and GFX. But there are clever techniques that pygamers have developed to deal with them in the form of cookbook recipes, libraries, and modules. Many issues can be easily mitigated by selecting a culling technique or two to reduce the number of things processed each game loop. Some people popping into IRC lately seem easily frustrated by these challenges, wanting an inefficient workload to just perform well. I can understand the sentiment. But I personally get an immense amount of pleasure from conquering these challenges. :) When I started pygame three years ago I was told you can't do a scrolling action-RPG: it's too much work for the CPU. Since then, computers became a significantly faster and several people have produced reasonably impressive action-RPGs, as well as other genre. For some examples one only has to look among the top places at pyweek.org , where pygame competes with the likes of pyglet, cocos2d, and rabbyt, all of which have the proclaimed advantage of 3D acceleration. It's become clear to me that for most hobby games the only real limitation is the resourcefulness of the programmer. I personally haven't yet hit a wall with Python or pygame that forced me to look at another framework or a natively compiled language, and I've done a few relatively ambitious projects. That may seem like a biased representation of Python's and pygame's capabilities, but I assure you it's not. A few times a year my eyes wander to other game development libraries or engines, but I keep coming right back to pygame. Hope that perspective helps. Gumm On Wed, Nov 23, 2011 at 6:08 AM, Chris Smith maximi...@gmail.com wrote: You can use Renpy for graphic novels. SNES RPG's would be no problem. For AI and other things, python might be slow but you will probably be surprised how far you can go with it. It'll certainly be easier than going the C++ route (although I'm not a C++ fan, to be honest... I'd use Lisp if I needed the code to be faster). On 23 November 2011 21:47, Nick Arnoeyts nickarnoe...@gmail.com wrote: I'm actually not quite sure what I'm going to write yet. Either an RPG in the style of SNES-era Final Fantasy, or a visual novel (if you know Higurashi or Clannad). I'm not (yet) interested in 3D and I would certainly do something like that in C++. Pygame is probably fast enough for the graphics, but I was wondering how performance would be for AI and other calculations. yours truly armornick 2011/11/23 Chris Smith maximi...@gmail.com You can't really compare the language C++ with the library Python. You could compare C++ / SDL with Python / Pygame, and probably C++ would be faster (but maybe by not as much
Re: [pygame] Pygame performance on Linux?
On 9/24/07, Greg Ewing [EMAIL PROTECTED] wrote: I have a Linux machine, with a CPU speed of supposedly 2.8GHz, on which pygame performance appears to be abysmal. Just doing display flips and nothing else, with an 800x6000 window, it can't get to 20fps. At I guess you mean 800x600? 10fps, it's using about 75% CPU. Should I be able to expect better than this? Yes, absolutely. Typically you don't get hardware accelerated graphics in windowed mode in X, but it should not be that slow anyway. Are you sure you are using the same video mode as your display uses [depth=0 to pygame.display.set_mode()]? Are you using double buffering (you don't have to for software rendering). Please post your code, it's difficult to diagnose the problem otherwise. Regards, Ulf
Re: [pygame] Pygame performance on Linux?
Greg Ewing wrote: I have a Linux machine, with a CPU speed of supposedly 2.8GHz, on which pygame performance appears to be abysmal. Just doing display flips and nothing else, with an 800x6000 window, it can't get to 20fps. At 10fps, it's using about 75% CPU. Sounds like you might not be running hardware acceleration. What video card are you using? If you have the antinspect xscreensaver try running it directly as antinspect -fps What frames per sec do you get? Hardware acceleration should give you around 50fps in the initial 600x480 window, and not a lot slower when the window is maximised (maybe 45fps). Cheers, - Miriam -- -=-=-=-=-=-=-- A life! Cool! Where can I download one of those from? -=-=-=-=-=-=-- Website: http://miriam-english.org Blog: http://www.livejournal.com/users/miriam_e/
Re: [pygame] Pygame performance on Linux?
That's *really* slow. What video card/driver/distribution do you use? I think something is wrong with your X setup. You should be able to do much more than that. On my really old P3 1 ghz laptop I get 112fps at 800x600 in a window. import pygame from pygame.locals import * screen = pygame.display.set_mode((800, 600)) clock = pygame.time.Clock() going = True while going: events = pygame.event.get() for e in events: if e.type in [KEYDOWN, QUIT, MOUSEBUTTONDOWN]: going = False clock.tick() pygame.display.flip() print clock.get_fps() On 9/24/07, Greg Ewing [EMAIL PROTECTED] wrote: I have a Linux machine, with a CPU speed of supposedly 2.8GHz, on which pygame performance appears to be abysmal. Just doing display flips and nothing else, with an 800x6000 window, it can't get to 20fps. At 10fps, it's using about 75% CPU. Should I be able to expect better than this? Under the same conditions, my dual 1.25GHz PPC does 20fps using only about 20% of its total CPU. -- Greg
Re: [pygame] Pygame performance on Linux?
I get 140 fps on a P4 1700 with Rene's script. I have an ATI Radeon 8500 with hardware acceleration. To know if you get hardware acceleration just run glxinfo command and see if you get somewhere direct rendering: Yes enrike René Dudfield(e)k dio: That's *really* slow. What video card/driver/distribution do you use? I think something is wrong with your X setup. You should be able to do much more than that. On my really old P3 1 ghz laptop I get 112fps at 800x600 in a window. import pygame from pygame.locals import * screen = pygame.display.set_mode((800, 600)) clock = pygame.time.Clock() going = True while going: events = pygame.event.get() for e in events: if e.type in [KEYDOWN, QUIT, MOUSEBUTTONDOWN]: going = False clock.tick() pygame.display.flip() print clock.get_fps() On 9/24/07, Greg Ewing [EMAIL PROTECTED] wrote: I have a Linux machine, with a CPU speed of supposedly 2.8GHz, on which pygame performance appears to be abysmal. Just doing display flips and nothing else, with an 800x6000 window, it can't get to 20fps. At 10fps, it's using about 75% CPU. Should I be able to expect better than this? Under the same conditions, my dual 1.25GHz PPC does 20fps using only about 20% of its total CPU. -- Greg
Re: [pygame] Pygame performance on Linux?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 altern wrote: I get 140 fps on a P4 1700 with Rene's script. I have an ATI Radeon 8500 with hardware acceleration. To know if you get hardware acceleration just run glxinfo command and see if you get somewhere direct rendering: Yes Does SDL use DRI, even for 2d graphics? My understanding was that DRI was only for 3d stuff like OpenGL. Ethan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG+B+IhRlgoLPrRPwRAm7qAKC2tVOORD0blFPkYpPfpQR1fk30dACggism 3yeCUhm7O8xvyCmeOi4/Prw= =39Af -END PGP SIGNATURE-
Re: [pygame] pygame performance
Wow, thanks everyone for the great information, I really appreciate it! It's nice to hear from some PyGame veterans! Thanks for all of the input and information guys! mark. On 10/18/06, Greg Ewing [EMAIL PROTECTED] wrote: Marcelo de Moraes Serpa wrote: I'm not into 3D yet either. But I really don't like slow rendering speeds on 2D games. Blitz has an incredible fast 2D rendering speed but the language is basic and I don't like basic! Most of the rendering work in 2D is blitting, which in pygame is done by C code inside SDL. So unless you're doing a lot of data crunching before you get around to blitting anything, the speed of executing Python code vs. Basic code will have very little to do with it. If Blitz renders a lot faster than pygame, it must be because it's using a much more efficient method of blitting than SDL does. That would be surprising, since I'd expect SDL's blitting code to be fairly well optimised. It's possible that Blitz is smarter about making use of hardware acceleration when it's available. Reportedly SDL will use hardware to do blitting under favourable circumstances, but I don't know what those circumstances are. -- Greg
Re: [pygame] pygame performance
hi marcelo performance depends very much on what you do. Using Opengl for the rendering speeds up the performance. Knowing about optimising python also helps. Check this out http://wiki.python.org/moin/PythonSpeed/PerformanceTips enrike Marcelo de Moraes Serpa escribió: Hello list! I used to use Blitz Basic to develop games some time ago. Now, I want to play with the wonderful world of game development again. I've found python to be a extremelly elegant, powerful and easy to use language, so, pygame seems to fit perfectly for what I'd like to do. However, I've seen some games made with pygame and found that their overall rendering speed is quite slow if you compare to other languages (Blitz Basic is actually quite fast). Maybe it was an isolated issue but I'd really like to know from more experinced developers on the performance of python/pygame. Thanks in advance, Marcelo.
Re: [pygame] pygame performance
So except if you want to code the next Unreal, you should haveeverything you need.Actually I want to code Quake 5 :D lol..That was just for the sake of curiosity. Thanks for the the info, it helps knowing how python works. Marcelo.On 10/18/06, Lionel Barret de Nazaris [EMAIL PROTECTED] wrote: Marcelo de Moraes Serpa wrote: Hello list! I used to use Blitz Basic to develop games some time ago. Now, I want to play with the wonderful world of game development again. I've found python to be a extremelly elegant, powerful and easy to use language, so, pygame seems to fit perfectly for what I'd like to do. However, I've seen some games made with pygame and found that their overall rendering speed is quite slow if you compare to other languages (Blitz Basic is actually quite fast). Maybe it was an isolated issue but I'd really like to know from more experinced developers on the performance of python/pygame. Thanks in advance, Marcelo.Mmm...i don't know much about blitz basic but AFAIK it is a static typed/ compiled language.Python is interpreted which make it slower (it cannot guess theexecution path as almost anything can be changed at runtime). For most app, the relative slowness in not important and largelycompensated by the productivity boost.Games are in the gray area. the many loops (rendering, collision, etc)imply many function calls which is slow in python. Complex 3D (like seen in commercial AAA games) is quite out of thequestion for now *but* simple games are very easy to do. With the helpof openGL it quite easy to get over 100 fps.So except if you want to code the next Unreal, you should have everything you need.
Re: [pygame] pygame performance
Yeah the performance of pyGame has always been a question for me, especially since I'm thinking of writing the entire game in straight python/pyGame. Not a 3d game of course but a simple 2d game, a side scroller or puzzle game, and PyGame seems like a nice way to keep things simple. So for me I'd love to hear about what kind of performance people have been able to achieve using straight PyGame, and whether or not it makes sense to try this... mark. On 10/18/06, Marcelo de Moraes Serpa [EMAIL PROTECTED] wrote: So except if you want to code the next Unreal, you should have everything you need. Actually I want to code Quake 5 :D lol.. That was just for the sake of curiosity. Thanks for the the info, it helps knowing how python works. Marcelo. On 10/18/06, Lionel Barret de Nazaris [EMAIL PROTECTED] wrote: Marcelo de Moraes Serpa wrote: Hello list! I used to use Blitz Basic to develop games some time ago. Now, I want to play with the wonderful world of game development again. I've found python to be a extremelly elegant, powerful and easy to use language, so, pygame seems to fit perfectly for what I'd like to do. However, I've seen some games made with pygame and found that their overall rendering speed is quite slow if you compare to other languages (Blitz Basic is actually quite fast). Maybe it was an isolated issue but I'd really like to know from more experinced developers on the performance of python/pygame. Thanks in advance, Marcelo. Mmm...i don't know much about blitz basic but AFAIK it is a static typed / compiled language. Python is interpreted which make it slower (it cannot guess the execution path as almost anything can be changed at runtime). For most app, the relative slowness in not important and largely compensated by the productivity boost. Games are in the gray area. the many loops (rendering, collision, etc) imply many function calls which is slow in python. Complex 3D (like seen in commercial AAA games) is quite out of the question for now *but* simple games are very easy to do. With the help of openGL it quite easy to get over 100 fps. So except if you want to code the next Unreal, you should have everything you need.
Re: [pygame] pygame performance
I'm not into 3D yet either. But I really don't like slow rendering speeds on 2D games. Blitz has an incredible fast 2D rendering speed but the language is basic and I don't like basic! On 10/18/06, Mark Mruss [EMAIL PROTECTED] wrote: Yeah the performance of pyGame has always been a question for me,especially since I'm thinking of writing the entire game in straightpython/pyGame.Not a 3d game of course but a simple 2d game, a sidescroller or puzzle game, and PyGame seems like a nice way to keep things simple.So for me I'd love to hear about what kind of performance people havebeen able to achieve using straight PyGame, and whether or not itmakes sense to try this...mark.On 10/18/06, Marcelo de Moraes Serpa [EMAIL PROTECTED] wrote: So except if you want to code the next Unreal, you should have everything you need. Actually I want to code Quake 5 :D lol.. That was just for the sake of curiosity. Thanks for the the info, it helps knowing how python works. Marcelo. On 10/18/06, Lionel Barret de Nazaris [EMAIL PROTECTED] wrote: Marcelo de Moraes Serpa wrote: Hello list! I used to use Blitz Basic to develop games some time ago. Now, I want to play with the wonderful world of game development again. I've found python to be a extremelly elegant, powerful and easy to use language, so, pygame seems to fit perfectly for what I'd like to do. However, I've seen some games made with pygame and found that their overall rendering speed is quite slow if you compare to other languages (Blitz Basic is actually quite fast). Maybe it was an isolated issue but I'd really like to know from more experinced developers on the performance of python/pygame. Thanks in advance, Marcelo. Mmm...i don't know much about blitz basic but AFAIK it is a static typed / compiled language. Python is interpreted which make it slower (it cannot guess the execution path as almost anything can be changed at runtime). For most app, the relative slowness in not important and largely compensated by the productivity boost. Games are in the gray area. the many loops (rendering, collision, etc) imply many function calls which is slow in python. Complex 3D (like seen in commercial AAA games) is quite out of the question for now *but* simple games are very easy to do. With the help of openGL it quite easy to get over 100 fps. So except if you want to code the next Unreal, you should have everything you need.
Re: [pygame] pygame performance
There's always ways to optimize things later. Write the code. If it's not fast enough, *profile* the code to see what's not fast, and take steps to optimize that part of the code. Sometimes using psyco is going to be enough, depending on which platforms you care about. Otherwise you could change the rendering strategy to use OpenGL (which is still the fastest way to do anything, even in 2D), or writing some of the tight loops in C or C++ (possibly via Pyrex). -bob On 10/18/06, Marcelo de Moraes Serpa [EMAIL PROTECTED] wrote: I'm not into 3D yet either. But I really don't like slow rendering speeds on 2D games. Blitz has an incredible fast 2D rendering speed but the language is basic and I don't like basic! On 10/18/06, Mark Mruss [EMAIL PROTECTED] wrote: Yeah the performance of pyGame has always been a question for me, especially since I'm thinking of writing the entire game in straight python/pyGame. Not a 3d game of course but a simple 2d game, a side scroller or puzzle game, and PyGame seems like a nice way to keep things simple. So for me I'd love to hear about what kind of performance people have been able to achieve using straight PyGame, and whether or not it makes sense to try this... mark. On 10/18/06, Marcelo de Moraes Serpa [EMAIL PROTECTED] wrote: So except if you want to code the next Unreal, you should have everything you need. Actually I want to code Quake 5 :D lol.. That was just for the sake of curiosity. Thanks for the the info, it helps knowing how python works. Marcelo. On 10/18/06, Lionel Barret de Nazaris [EMAIL PROTECTED] wrote: Marcelo de Moraes Serpa wrote: Hello list! I used to use Blitz Basic to develop games some time ago. Now, I want to play with the wonderful world of game development again. I've found python to be a extremelly elegant, powerful and easy to use language, so, pygame seems to fit perfectly for what I'd like to do. However, I've seen some games made with pygame and found that their overall rendering speed is quite slow if you compare to other languages (Blitz Basic is actually quite fast). Maybe it was an isolated issue but I'd really like to know from more experinced developers on the performance of python/pygame. Thanks in advance, Marcelo. Mmm...i don't know much about blitz basic but AFAIK it is a static typed / compiled language. Python is interpreted which make it slower (it cannot guess the execution path as almost anything can be changed at runtime). For most app, the relative slowness in not important and largely compensated by the productivity boost. Games are in the gray area. the many loops (rendering, collision, etc) imply many function calls which is slow in python. Complex 3D (like seen in commercial AAA games) is quite out of the question for now *but* simple games are very easy to do. With the help of openGL it quite easy to get over 100 fps. So except if you want to code the next Unreal, you should have everything you need.
Re: [pygame] pygame performance
Hi MarkMaybe this against all programmers rules but I wouldn't concern performing the game from the beginning. If you have written the game in a proper way its quite easy to optimize later on. I do it that way and was happy about it with one big reason: I didnt spend time on optimizing it when I had to change the (optimized) code later on (and that happend a lot). Its like you start writing a book and after every chapter you (I dont know the word in English) you optimize/style the written chapter. Later on you completly rewrite it because it wont fit anymore to the whole story. The time you spent styling the chapter is lost.All over its a question how (far) you plan and code your game.Just my 2 centsFaraiAm 18.10.2006 um 20:07 schrieb Marcelo de Moraes Serpa:I'm not into 3D yet either. But I really don't like slow rendering speeds on 2D games. Blitz has an incredible fast 2D rendering speed but the language is basic and I don't like basic! On 10/18/06, Mark Mruss [EMAIL PROTECTED] wrote: Yeah the performance of pyGame has always been a question for me,especially since I'm thinking of writing the entire game in straightpython/pyGame. Not a 3d game of course but a simple 2d game, a sidescroller or puzzle game, and PyGame seems like a nice way to keep things simple.So for me I'd love to hear about what kind of performance people havebeen able to achieve using straight PyGame, and whether or not itmakes sense to try this...mark.On 10/18/06, Marcelo de Moraes Serpa [EMAIL PROTECTED] wrote: So except if you want to code the next Unreal, you should have everything you need. Actually I want to code Quake 5 :D lol.. That was just for the sake of curiosity. Thanks for the the info, it helps knowing how python works. Marcelo. On 10/18/06, Lionel Barret de Nazaris [EMAIL PROTECTED] wrote: Marcelo de Moraes Serpa wrote: Hello list! I used to use Blitz Basic to develop games some time ago. Now, I wantto play with the wonderful world of game development again. I've found python to be a extremelly elegant, powerful and easy to use language, so, pygame seems to fit perfectly for what I'd like to do. However,I've seen some games made with pygame and found that their overall rendering speed is quite slow if you compare to other languages (Blitz Basic is actually quite fast). Maybe it was an isolated issue but I'dreally like to know from more experinced developers on the performance of python/pygame. Thanks in advance, Marcelo. Mmm...i don't know much about blitz basic but AFAIK it is a static typed / compiled language. Python is interpreted which make it slower (it cannot guess the execution path as almost anything can be changed at runtime). For most app, the relative slowness in not important and largely compensated by the productivity boost. Games are in the gray area. the many loops (rendering, collision, etc) imply many function calls which is slow in python. Complex 3D (like seen in commercial AAA games) is quite out of the question for now *but* simple games are very easy to do. With the help of openGL it quite easy to get over 100 fps. So except if you want to code the next Unreal, you should have everything you need.
Re: [pygame] pygame performance
Once everything is in place you first replace code that's slow with better algorithms. If you still need better performance, then you try other means. It usually is fast enough at this point, and you're done. In many cases you can beat (naive) C or C++ in speed simply because it's more natural to write good algorithms and use appropriate data structures in Python. psyco is an easy speed-up for some things with no changes to the code, but it only works on 32-bit x86 platforms with 4 byte stack alignment (basically everything but Mac OS X Intel). If you still need more optimization you start translating small pieces to a lower level language, but only the pieces that are proven to be a bottleneck by profiling. This is often not necessary. -bob On 10/18/06, Lionel Barret de Nazaris [EMAIL PROTECTED] wrote: In other words, you could consider python as the prototype code. it is not fast but it is easy to code and therefore to something working quickly. Once everything, and i mean everything, is in place (i.e you have overcome all obstacles), you replace part of the prototype code that need it by translating it to c++/Delphi/D (or using psyco)... The key words are overcoming obstacles. Much much easier than the traditionnal way bottom up from c++ to script. L. Bob Ippolito wrote: There's always ways to optimize things later. Write the code. If it's not fast enough, *profile* the code to see what's not fast, and take steps to optimize that part of the code. Sometimes using psyco is going to be enough, depending on which platforms you care about. Otherwise you could change the rendering strategy to use OpenGL (which is still the fastest way to do anything, even in 2D), or writing some of the tight loops in C or C++ (possibly via Pyrex). -bob On 10/18/06, Marcelo de Moraes Serpa [EMAIL PROTECTED] wrote: I'm not into 3D yet either. But I really don't like slow rendering speeds on 2D games. Blitz has an incredible fast 2D rendering speed but the language is basic and I don't like basic! On 10/18/06, Mark Mruss [EMAIL PROTECTED] wrote: Yeah the performance of pyGame has always been a question for me, especially since I'm thinking of writing the entire game in straight python/pyGame. Not a 3d game of course but a simple 2d game, a side scroller or puzzle game, and PyGame seems like a nice way to keep things simple. So for me I'd love to hear about what kind of performance people have been able to achieve using straight PyGame, and whether or not it makes sense to try this... mark. On 10/18/06, Marcelo de Moraes Serpa [EMAIL PROTECTED] wrote: So except if you want to code the next Unreal, you should have everything you need. Actually I want to code Quake 5 :D lol.. That was just for the sake of curiosity. Thanks for the the info, it helps knowing how python works. Marcelo. On 10/18/06, Lionel Barret de Nazaris [EMAIL PROTECTED] wrote: Marcelo de Moraes Serpa wrote: Hello list! I used to use Blitz Basic to develop games some time ago. Now, I want to play with the wonderful world of game development again. I've found python to be a extremelly elegant, powerful and easy to use language, so, pygame seems to fit perfectly for what I'd like to do. However, I've seen some games made with pygame and found that their overall rendering speed is quite slow if you compare to other languages (Blitz Basic is actually quite fast). Maybe it was an isolated issue but I'd really like to know from more experinced developers on the performance of python/pygame. Thanks in advance, Marcelo. Mmm...i don't know much about blitz basic but AFAIK it is a static typed / compiled language. Python is interpreted which make it slower (it cannot guess the execution path as almost anything can be changed at runtime). For most app, the relative slowness in not important and largely compensated by the productivity boost. Games are in the gray area. the many loops (rendering, collision, etc) imply many function calls which is slow in python. Complex 3D (like seen in commercial AAA games) is quite out of the question for now *but* simple games are very easy to do. With the help of openGL it quite easy to get over 100 fps. So except if you want to code the next Unreal, you should have everything you need.
Re: [pygame] pygame performance
I agree with Bob. * Python is a very easy language to prototype in and is quite fast. Very fast sometimes. And it is perfectly suitable for building large programs in. * Psyco (which I only discovered recently btw) can apparently give quite miraculous speedups in some cases. * When you have the system working reliably, look for the points of slowdown. The worst case is that you may have to write a C module to handle some specific hardware interactions - but with the way the OpenGL access from Python is going that's going to be a rare requirement. Jon Quoting Bob Ippolito [EMAIL PROTECTED]: There's always ways to optimize things later. Write the code. If it's not fast enough, *profile* the code to see what's not fast, and take steps to optimize that part of the code. Sometimes using psyco is going to be enough, depending on which platforms you care about. Otherwise you could change the rendering strategy to use OpenGL (which is still the fastest way to do anything, even in 2D), or writing some of the tight loops in C or C++ (possibly via Pyrex). -bob On 10/18/06, Marcelo de Moraes Serpa [EMAIL PROTECTED] wrote: I'm not into 3D yet either. But I really don't like slow rendering speeds on 2D games. Blitz has an incredible fast 2D rendering speed but the language is basic and I don't like basic! On 10/18/06, Mark Mruss [EMAIL PROTECTED] wrote: Yeah the performance of pyGame has always been a question for me, especially since I'm thinking of writing the entire game in straight python/pyGame. Not a 3d game of course but a simple 2d game, a side scroller or puzzle game, and PyGame seems like a nice way to keep things simple. So for me I'd love to hear about what kind of performance people have been able to achieve using straight PyGame, and whether or not it makes sense to try this... mark. On 10/18/06, Marcelo de Moraes Serpa [EMAIL PROTECTED] wrote: So except if you want to code the next Unreal, you should have everything you need. Actually I want to code Quake 5 :D lol.. That was just for the sake of curiosity. Thanks for the the info, it helps knowing how python works. Marcelo. On 10/18/06, Lionel Barret de Nazaris [EMAIL PROTECTED] wrote: Marcelo de Moraes Serpa wrote: Hello list! I used to use Blitz Basic to develop games some time ago. Now, I want to play with the wonderful world of game development again. I've found python to be a extremelly elegant, powerful and easy to use language, so, pygame seems to fit perfectly for what I'd like to do. However, I've seen some games made with pygame and found that their overall rendering speed is quite slow if you compare to other languages (Blitz Basic is actually quite fast). Maybe it was an isolated issue but I'd really like to know from more experinced developers on the performance of python/pygame. Thanks in advance, Marcelo. Mmm...i don't know much about blitz basic but AFAIK it is a static typed / compiled language. Python is interpreted which make it slower (it cannot guess the execution path as almost anything can be changed at runtime). For most app, the relative slowness in not important and largely compensated by the productivity boost. Games are in the gray area. the many loops (rendering, collision, etc) imply many function calls which is slow in python. Complex 3D (like seen in commercial AAA games) is quite out of the question for now *but* simple games are very easy to do. With the help of openGL it quite easy to get over 100 fps. So except if you want to code the next Unreal, you should have everything you need. Come and visit Web Prophets Website at http://www.webprophets.net.au
Re: [pygame] pygame performance
Lionel Barret de Nazaris wrote: Complex 3D (like seen in commercial AAA games) is quite out of the question for now *but* simple games are very easy to do. The trick is to find external libraries you can wrap to do most of the hard work, and just write the high level control code in Python. You might like to investigate something like Soya, which wraps SDL, OpenGL and ODE. It's quite likely you could build something like Unreal on top of it with very acceptable performance. http://home.gna.org/oomadness/en/soya/index.html -- Greg
Re: [pygame] pygame performance
Mark Mruss wrote: Not a 3d game of course but a simple 2d game, a side scroller or puzzle game, and PyGame seems like a nice way to keep things simple. So for me I'd love to hear about what kind of performance people have been able to achieve using straight PyGame, and whether or not it makes sense to try this... Quite a number of such games have been written, and they seem to work just fine. Check out the games on the Pygame web site, or the PyWeek competition entries. Many of them have arcade-type action that works very smoothly. Puzzle games are even easier, since speed isn't usually an issue at all. -- Greg
Re: [pygame] pygame performance
Marcelo de Moraes Serpa wrote: I'm not into 3D yet either. But I really don't like slow rendering speeds on 2D games. Blitz has an incredible fast 2D rendering speed but the language is basic and I don't like basic! Most of the rendering work in 2D is blitting, which in pygame is done by C code inside SDL. So unless you're doing a lot of data crunching before you get around to blitting anything, the speed of executing Python code vs. Basic code will have very little to do with it. If Blitz renders a lot faster than pygame, it must be because it's using a much more efficient method of blitting than SDL does. That would be surprising, since I'd expect SDL's blitting code to be fairly well optimised. It's possible that Blitz is smarter about making use of hardware acceleration when it's available. Reportedly SDL will use hardware to do blitting under favourable circumstances, but I don't know what those circumstances are. -- Greg
