Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: If C++ is so bad, what should game developers use?

news.ycombinator.com

Post reply on HN
Print view View original

31–40 of 127 posts

Re: Ask HN: If C++ is so bad, what should game developers use?

#31

Post by olliesaunders »

derefr wrote: post #25
thras wrote: post #21

Earlier quoted context omitted.

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.

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…

Last time I heard, assembly wasn't considered out of bounds for high performance game programming by any means.

Re: Ask HN: If C++ is so bad, what should game developers use?

#33

Post by scott_s »

thras wrote: post #9

I'm with you. Whatever you use, don't choose C++. Sure, everyone on your programming team knows C++ already. Yeah, your libraries are all written in it. And successful games have used it again and again. But if it's not one of the "cool" languages, you shouldn't be using it. Modern game developers should code in Ruby/Lisp. By the time you've finished coding all of your graphics libraries from scratch, Moore's law wil…

Moore's Law will probably have negligible impact on sequential performance in the future.

Re: Ask HN: If C++ is so bad, what should game developers use?

#35

Post by miloshh »

derefr wrote: post #25
thras wrote: post #21

Earlier quoted context omitted.

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.

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…

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.

Re: Ask HN: If C++ is so bad, what should game developers use?

#36

Post by petewarden »

ComputerGuru wrote: post #6

Don't let them scare you away... C++ is fine if you use what you need and take the time to actually understand the tools you're using.

I second that. Having spent almost a decade writing commercial C++ code, I recognize everything horrific about the language as documented in the FQA.

The thing is, it doesn't matter. The fact that it's the leading language in your domain is much more important than its abstract quality. Availability of libraries, co-workers who understand it, examples of how to solve common domain problems in the language, these all outweigh the pitfalls and ugliness of the syntax.

Don't be seduced by the language wars. It's like spending days optimising a function that only takes 10% of your run time. Unless you're interested in the learning exercise (which I'm not knocking if you have time) pick one of the dominant languages in your domain, and spend your time worrying about everything else.

Re: Ask HN: If C++ is so bad, what should game developers use?

#37

Post by olliesaunders »

derefr wrote: post #25
thras wrote: post #21

Earlier quoted context omitted.

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.

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…

Wait, according to 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."

Re: Ask HN: If C++ is so bad, what should game developers use?

#38

Post by derefr »

thras wrote: post #24
derefr wrote: post #10

Earlier quoted context omitted.

Why is C++ suddenly "fine" when you have no other options? There could easily be a language with all the close-to-the-metal advantages and none of the baroque, redundant complexity of C++; why must we be content to use the same language as everyone else in the industry, rather that scratching this itch and building a newer, more productive one?

A lot of that "baroque, redundant complexity" comes from standards committee's refusal to make things easier on programmers at the cost of any smidgen of performance. And for certain tasks, like the highly competitive video game industry, uncompromising performance is exactly what the doctor ordered. You can always hire smarter programmers if you have to. On the other hand, it's hard to sell a game that runs or looks…

The complexity is "baroque" because, in modern times, we've invented ways around it. Type inference would kill half of the pain involved in C++ without sacrificing performance. Cleaning up the syntax enough that definitions could be found context-free would eliminate the need for declarations, and in most cases .h/hpp files.

The complexity is redundant because they included features of C that they should have deprecated in favor of the C++ equivalents. String literals should be (const) basic_strings, and there should be no way to access stdio's horribly-easy-to-buffer-overflow machinations now that there's iostream. For that matter, boost should be adopted at a much more formal level: the default syntax for pointer variable allocation should allocate smart pointers, and one should have to go out of their way to get a dumb one. None of these things sacrifices performance; they're just artefacts of the fact that C++ wants to pretend it's still 1970 and that it's being used for systems programming in a mélange with C.

Re: Ask HN: If C++ is so bad, what should game developers use?

#40

Post by thras »

derefr wrote: post #25
thras wrote: post #21

Earlier quoted context omitted.

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.

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…

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.

Post reply on HN