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 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > >
-- Ryan Hope, M.S. CogWorks Lab Department of Cognitive Science Rensselaer Polytechnic Institute