2 ms·

I think that best thing to do is look at 1) the libraries you'll be using, 2) what your team is proficient at, 3) what's worked for other groups, 4) optimizatio

by thras 17y ago

I think that best thing to do is look at 1) the libraries you'll be using, 2) what your team is proficient at, 3) what's worked for other groups, 4) optimization potential. If you think that Ruby/Lisp is your answer to the above points, go for it. But I have the feeling that it won't be for many people.

derefr 17y ago
I didn't say I wanted to use Ruby or Lisp--I was simply denying the parent's point that one would have to "write the graphics libraries from scratch." Besides, isn't the advice for optimizing every other kind of project: 1. Start in a high-level language 2. Port any bits that profile as slow to a low-level language, and then interface them into your HLL code Why, all of the sudden, when you're coding a game, is it a better idea to start in the low-level language? Because your team "knows it?" by that argument, all games would still be being developed in assembler, because the most senior members of the team would have more experience with that than any new-fangled language like C++.
- olliesaunders 17y ago
  Last time I heard, assembly wasn't considered out of bounds for high performance game programming by any means.
  - imok20 17y ago
    Last you heard must have been a while ago. Even the engines aren't being written in assembly. Writing in x86 yields slower and less optimized code than letting gcc -o3 etc compile your C code in x86. It simply gets too complex to manage in assembly.
    - zokier 17y ago
      offtopic: gcc -Os is probably even faster than -O3.
      - imok20 17y ago
        That's not true in the case of C – just reported in the case of Ruby. And only in some cases.
- miloshh 17y ago
  That advice never works. The problem is data structures. If your high-level prototype uses complex data structures of e.g. Python, you will not be able to access them from C++. You will need to rewrite the whole thing anyway. The only way you might get away with this approach is if your application is essentially a number of separate scripts that communicate through files. Then you can rewrite the key scripts in C++. But that is never the case for games.
  - lutorm 17y ago
    Part of Civ IV (mostly gui stuff) is in python. They seem to be able to communicate with the C++ core fine.
    - miloshh 17y ago
      But I assume they did not write the game in Python and the optimize parts in C++. Quite the opposite - they wrote it in C++ and then found that some part (e.g. GUI) is growing in complexity while not being crucial for performance, at which point it is a good decision to use a scripting language for it. That is a pretty common approach, but what was suggested above (writing first in HLL and then rewriting parts in C++) is, to my knowledge, never done in practice.
  - silentbicycle 17y ago
    While rather similar to Python, Lua has a simple stack-based C API that makes this far less of a problem. OTOH, Lua was designed for embedded use from the start, and its stand-alone interpreter comes second.
- olliesaunders 17y ago
  Wait, according to http://news.ycombinator.com/item?id=888748 http://news.ycombinator.com/item?id=888748: "There is not a simple set of “hotspots” to optimize!" and also "Will gladly sacrifice 10% of our performance for 10% higher productivity [...] We never use assembly language."
- thras 17y ago
  Now, although C++ is a perfectly fine "HLL" language, I'll grant you that other languages are easier to program in. But patchwork programming can be bad advice some of or maybe most of the time. Besides the issues of programming in a language different from what your libraries were written in (and more importantly, designed for), there are serious issues with the patchwork-performance code philosophy. The biggest is that the "routines" that you need to make fast often operate on data. You'll have a container of some sort in your "slow" language, and you'll want to do something with that container in the "fast" language. Do you expose the container's memory to the fast language (hard!)? Do you copy (slow!)? Do you use the more efficient containers in your fast language and expose them to the slow language (insane!)? When exposing complex objects between languages, you'll have similar considerations to make. You can't look at C++/Python or C++/Ruby programming and assume that you'll simply have to make the same sort of engineering considerations as you would for C/Assembly. It's an entirely different kettle of worms. Assembly is concerned with telling a computer directly how to handle memory addresses. C, for all intents and purposes, is just a simple abstraction for doing that. On the other hand, higher level languages present a lot of abstractions for doing a lot of things. And mixing those abstractions leads to serious complexity.
jacquesm 17y ago
There's a role for lisp (and prolog) in gaming, but not on the outside. As an embedded core to sort out a bunch of logic they definitely have their place.

by thras 17y ago

derefr 17y ago

I didn't say I wanted to use Ruby or Lisp--I was simply denying the parent's point that one would have to "write the graphics libraries from scratch." Besides, isn't the advice for optimizing every other kind of project: 1. Start in a high-level language 2. Port any bits that profile as slow to a low-level language, and then interface them into your HLL code Why, all of the sudden, when you're coding a game, is it a better idea to start in the low-level language? Because your team "knows it?" by that argument, all games would still be being developed in assembler, because the most senior members of the team would have more experience with that than any new-fangled language like C++.

olliesaunders 17y ago
Last time I heard, assembly wasn't considered out of bounds for high performance game programming by any means.
- imok20 17y ago
  Last you heard must have been a while ago. Even the engines aren't being written in assembly. Writing in x86 yields slower and less optimized code than letting gcc -o3 etc compile your C code in x86. It simply gets too complex to manage in assembly.
  - zokier 17y ago
    offtopic: gcc -Os is probably even faster than -O3.
    - imok20 17y ago
      That's not true in the case of C – just reported in the case of Ruby. And only in some cases.
miloshh 17y ago
That advice never works. The problem is data structures. If your high-level prototype uses complex data structures of e.g. Python, you will not be able to access them from C++. You will need to rewrite the whole thing anyway. The only way you might get away with this approach is if your application is essentially a number of separate scripts that communicate through files. Then you can rewrite the key scripts in C++. But that is never the case for games.
- lutorm 17y ago
  Part of Civ IV (mostly gui stuff) is in python. They seem to be able to communicate with the C++ core fine.
  - miloshh 17y ago
    But I assume they did not write the game in Python and the optimize parts in C++. Quite the opposite - they wrote it in C++ and then found that some part (e.g. GUI) is growing in complexity while not being crucial for performance, at which point it is a good decision to use a scripting language for it. That is a pretty common approach, but what was suggested above (writing first in HLL and then rewriting parts in C++) is, to my knowledge, never done in practice.
- silentbicycle 17y ago
  While rather similar to Python, Lua has a simple stack-based C API that makes this far less of a problem. OTOH, Lua was designed for embedded use from the start, and its stand-alone interpreter comes second.
olliesaunders 17y ago
Wait, according to http://news.ycombinator.com/item?id=888748 http://news.ycombinator.com/item?id=888748: "There is not a simple set of “hotspots” to optimize!" and also "Will gladly sacrifice 10% of our performance for 10% higher productivity [...] We never use assembly language."
thras 17y ago
Now, although C++ is a perfectly fine "HLL" language, I'll grant you that other languages are easier to program in. But patchwork programming can be bad advice some of or maybe most of the time. Besides the issues of programming in a language different from what your libraries were written in (and more importantly, designed for), there are serious issues with the patchwork-performance code philosophy. The biggest is that the "routines" that you need to make fast often operate on data. You'll have a container of some sort in your "slow" language, and you'll want to do something with that container in the "fast" language. Do you expose the container's memory to the fast language (hard!)? Do you copy (slow!)? Do you use the more efficient containers in your fast language and expose them to the slow language (insane!)? When exposing complex objects between languages, you'll have similar considerations to make. You can't look at C++/Python or C++/Ruby programming and assume that you'll simply have to make the same sort of engineering considerations as you would for C/Assembly. It's an entirely different kettle of worms. Assembly is concerned with telling a computer directly how to handle memory addresses. C, for all intents and purposes, is just a simple abstraction for doing that. On the other hand, higher level languages present a lot of abstractions for doing a lot of things. And mixing those abstractions leads to serious complexity.

jacquesm 17y ago

There's a role for lisp (and prolog) in gaming, but not on the outside. As an embedded core to sort out a bunch of logic they definitely have their place.