5 ms·

First let me say that I really don't want to be mean here: I'll try to do constructive criticism. I've worked professionally in the video-game industry and I m

First let me say that I really don't want to be mean here: I'll try to do constructive criticism. I've worked professionally in the video-game industry and I must say that I'm a bit disappointed by all these blogs / videos trying to promote tools and/or languages by using very poorly conceived games. Take ChromaShift for example: it's terribly bad. We're in 2013 and the thing draws less "pixels" and yet is slower than any 2D scroller from the 80s running on a C64. Sure, it was done in 48 hours and kudos for that... But back in the nineties we'd enter 48 hours or 24 hours "demo" competition and come up with stuff incredibly better looking than that. The author of ChromaShift made a talk about the "Component Entity System" he's using. And that's where the "suspension of disbelief" simply doesn't work for me: everytime he shows the game, it's freakin' ugly and slow as molasses. Then comes the disappointment: if you want to run at a reasonable framerate you, of course, need to perform quite some logic in about 16 milliseconds (the author correctly mentions it in its talk). And... Drumrolls: simply "iterating" over a seq made of a hundred elements in Clojure apparently takes more time than that. Not to mention that if you create objects at every frame then at one point the GC shall have to kick in and your real-time performance will suddenly drop (the author says that in the talk I watched about CES/Chromashift). But why oh why use a language that is very arguable not meant to write video games in (Clojure) to... write a game in it as an example of what can be done!? (or as an example of how powerful an IDE supposedly is!?) The "problem" is that they're talking about that "CES" as it was the one way to create games. But how many games written in Clojure have been shipped? Heck, how many games written in Clojure are even playable? There are, today, lots of people writing games (either professionals or amateurs) and selling them (or giving them away for free). And not a single one of these game is using that "Component Entity System". And hardly any of them is using Clojure (there may be one or two exceptions but that's about it). And every single of these real games (even the simplest smartphone game) is looking better and is more responsive than the poor examples we see in Clojure talks. So how are we, Clojure believers (I'm a big Clojure fan and investing lots of time and energy learning it), supposed to take any of this seriously? Once again, I don't want to be mean: these guys are typically good programmers but, to be honest, they don't know anything about game programming and that is a bit saddening. EDIT: I won't even start talking about the "quality" of the "text editor" part of Light Table. I like the concept of LT but I do wan't a client/server mode where I can plug in vim or Emacs (or Sublime Text 2 or whatever) as my text editor. Otherwise I'm never going to take LT seriously.

dman 14y ago
+1. I faced this writing software in Python that was meant to be fast and interactive and collected data about just how few operations you can do in 16 ms. A blog post containing timing information for common operations in Python is available at http://blog.enthought.com/general/what-is-your-python-budget/ http://blog.enthought.com/general/what-is-your-python-budget... . (Disclaimer: I am the author of the blog post). Some things surprised me when I first did the timing - 1) Turns out that a function call plus an empty loop over a million items is ~16 ms in Python. 2) Turns out that on a pretty high end machine you get about 174k function calls in 16 ms. On a Core 2 duo laptop you get about 80k function calls in 16 ms. (In both cases the function takes no parameters and has a no-op body) For getting timing information on your own machine you can run the code from https://github.com/deepankarsharma/cost-of-python https://github.com/deepankarsharma/cost-of-python
- skywalk 14y ago
  If you were planning to write a high performance game using python, most likely you wouldn't be using the vanilla cpython interpreter, but instead using cython (http://cython.org/ http://cython.org/) to write extensions in essentially C for all your high performance code. I think it's important to remember one of the core tenants of python is to first write in python, then optimize the bits where necessary in C by moving those calls into an extension - by using cython you get to move to C like speeds by just annotating your existing python code. Also - I think a fairly more common approach to using python in game development is to write the core in C++, then call out to python for scriptability purposes (e.g. configuring characters/levels) - rarely would one write a full game in python unless extensions were heavily used, for the reasons quoted above.
  - dman 14y ago
    I agree with everything you say but continually find cases where things have to be rewritten in Cython / using the CPython C-api or moving core logic to numpy. Knowing that you cant be interactive if your solution requires a) allocating more than 160k objects b) creating more than 22k numpy arrays c) entering a with context more than 3700 times d) doing a single for loop of over a million elements can save you time from the get go. I am not suggesting that you cant write fast interactive code in Python, I am saying you wont write fast code by accident.

dman 14y ago

+1. I faced this writing software in Python that was meant to be fast and interactive and collected data about just how few operations you can do in 16 ms. A blog post containing timing information for common operations in Python is available at http://blog.enthought.com/general/what-is-your-python-budget/ http://blog.enthought.com/general/what-is-your-python-budget... . (Disclaimer: I am the author of the blog post). Some things surprised me when I first did the timing - 1) Turns out that a function call plus an empty loop over a million items is ~16 ms in Python. 2) Turns out that on a pretty high end machine you get about 174k function calls in 16 ms. On a Core 2 duo laptop you get about 80k function calls in 16 ms. (In both cases the function takes no parameters and has a no-op body) For getting timing information on your own machine you can run the code from https://github.com/deepankarsharma/cost-of-python https://github.com/deepankarsharma/cost-of-python

skywalk 14y ago
If you were planning to write a high performance game using python, most likely you wouldn't be using the vanilla cpython interpreter, but instead using cython (http://cython.org/ http://cython.org/) to write extensions in essentially C for all your high performance code. I think it's important to remember one of the core tenants of python is to first write in python, then optimize the bits where necessary in C by moving those calls into an extension - by using cython you get to move to C like speeds by just annotating your existing python code. Also - I think a fairly more common approach to using python in game development is to write the core in C++, then call out to python for scriptability purposes (e.g. configuring characters/levels) - rarely would one write a full game in python unless extensions were heavily used, for the reasons quoted above.
- dman 14y ago
  I agree with everything you say but continually find cases where things have to be rewritten in Cython / using the CPython C-api or moving core logic to numpy. Knowing that you cant be interactive if your solution requires a) allocating more than 160k objects b) creating more than 22k numpy arrays c) entering a with context more than 3700 times d) doing a single for loop of over a million elements can save you time from the get go. I am not suggesting that you cant write fast interactive code in Python, I am saying you wont write fast code by accident.