[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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 <renesd@xxxxxxxxx> 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 <cosmologicon@xxxxxxxxx>
> 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 <nickarnoeyts@xxxxxxxxx>
>> 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 <cosmologicon@xxxxxxxxx>
>>>>
>>>> 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 <nickarnoeyts@xxxxxxxxx>
>>>> 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 <stabbingfinger@xxxxxxxxx>
>>>>>>
>>>>>> 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 <maximinus@xxxxxxxxx>
>>>>>> 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 <nickarnoeyts@xxxxxxxxx>
>>>>>>> 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 <maximinus@xxxxxxxxx>
>>>>>>>>>
>>>>>>>>> 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 <nickarnoeyts@xxxxxxxxx>
>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>



-- 
Ryan Hope, M.S.
CogWorks Lab
Department of Cognitive Science
Rensselaer Polytechnic Institute