Why I Write Games in C • Hacker News Board

Re: Why I Write Games in C

#191

Post by pcwalton » Sat, Jan 09, 2016, 6:22 PM UTC

Tistel wrote: post #151

C++ compile and link time. I once worked on a PS3 game that had a 50 minute turnaround time (change code -> compile -> link -> load). No scripting either. The horror. It was because the company had home brewed a bunch of "optimizations" into the build process. On the up side it will force you to learn to live edit the game with the debugger to tweak and adjust. If its C++ and the programmers know the engineering KISS…

> I like the simplicity of C too. You can have a good mental model right down the CPU of what is going on.

Not really, with compilers as sophisticated as they are and the spec as liberal with undefined behavior as it is. The C virtual machine that the spec defines is every bit as complex as any other virtual machine.

> But these days given how fast CPUs are and how much more productive you can be in a high level language (python is 10x more productive than C++, apparently) I think a garbage collected high level language is the way to go.

I totally agree. In fact, I wouldn't use C even for projects where a GC isn't suitable, just because we have alternatives now and it's so difficult to write programs free of basic memory management mistakes we've been making since the 80s.

Re: Why I Write Games in C

#192

Post by pcwalton » Sat, Jan 09, 2016, 6:26 PM UTC

kodr wrote: post #7

RaitoBezarius wrote: post #3

What about Rust?

my thought. is there enough support for OpenGL? I know you can use stuff from C in Rust, so it could be a solution.

> my thought. is there enough support for OpenGL? I know you can use stuff from C in Rust, so it could be a solution.

glium is arguably the best idiomatic OpenGL binding in any language anywhere.

I program in OpenGL with Rust every day as part of my job these days.

Re: Why I Write Games in C

#193

Post by pcwalton » Sat, Jan 09, 2016, 6:29 PM UTC

AndyKelley wrote: post #17

RaitoBezarius wrote: post #3

What about Rust?

I like Rust, but sometimes it is pretty difficult to convince the compiler that one's code is safe. And this does not mean that the compiler is preventing unsafety; there are many safe programs that the compiler rejects. Also, the OP said that compile time was a priority, and compiling Rust code is closer to C++ speed than C.

> And this does not mean that the compiler is preventing unsafety; there are many safe programs that the compiler rejects.

Two nits:

1. The compiler does prevent safety problems. It just happens to rule out some safe programs while doing so. (Although I think this is a bit of a misconception, because with the aliasing rules being used for optimization many things that the Rust compiler rejects that people think are safe are actually not.)

2. You can describe any type system this way. That doesn't mean we don't like type systems.

Re: Why I Write Games in C

#194

Post by djur » Sat, Jan 09, 2016, 6:30 PM UTC

strangecasts wrote: post #98

jeremyjh wrote: post #91

Earlier quoted context omitted.

>I would say the same for C, honestly. Really? SDL is quite poor??? It has bindings in pretty much every language and I would guess is the most popular game library in existence, written in pure C. It is not a game engine but is an excellent library to build one with. It is so popular for this purpose that it has its own COLUMN in the Wikipdia table of game engines: https://en.wikipedia.org/wiki/List_of_game_engines

Another nice library is SFML[1], which has bindings for C and several other languages (including OCaml). [1]: http://www.sfml-dev.org/

SFML is actually a good case of what I was talking about. It's a C++ library with a C binding. I found that (and C++ libraries with no C binding at all) to be more common than native C libraries.

Re: Why I Write Games in C

#195

Post by loup-vaillant » Sat, Jan 09, 2016, 6:32 PM UTC

[deleted] wrote: post #190

loup-vaillant wrote: post #164

Earlier quoted context omitted.

> code that deal with geometry data shouldn't really be any different for games Counter-example: http://jonathanwhiting.com/games/knossu/ (Highly recommended if you have 20 minutes to spare.) The geometry of this game is unlike any I have seen so far. There is common logic with that of a Doom-like ray caster, but I'd argue not much. The time spent rewriting the generic parts of a ray caster probably pales in comparis…

[deleted]

Ah, now you've spoiled it! Somehow I have the feeling this game is even more effective when you think of it as a retro game, until you discover by yourself that this world is… not right.

Re: Why I Write Games in C

#196

Post by djur » Sat, Jan 09, 2016, 6:35 PM UTC

jeremyjh wrote: post #91

djur wrote: post #5

> I would like to use [Go], but there are big roadblocks that prevent me. The stop-the-world garbage collection is a big pain for games, stopping the world is something you can't really afford to do. GC pauses in Go should not be a serious issue for games like the ones featured on the OP's site. The same general techniques used for high-performance manual memory management work fine in garbage-collected languages --…

>I would say the same for C, honestly. Really? SDL is quite poor??? It has bindings in pretty much every language and I would guess is the most popular game library in existence, written in pure C. It is not a game engine but is an excellent library to build one with. It is so popular for this purpose that it has its own COLUMN in the Wikipdia table of game engines: https://en.wikipedia.org/wiki/List_of_game_engines

SDL and Allegro are great, but there isn't a very robust software ecosystem around them. You can put together something great with SDL, chipmunk2d, and enet, but there's not a lot of options. It's really nothing compared to what's available in the C++, Java, and JavaScript worlds.

Re: Why I Write Games in C

#197

Post by pandaman » Sat, Jan 09, 2016, 6:36 PM UTC

crafn wrote: post #172

je42 wrote: post #155

Earlier quoted context omitted.

- Compile times with templates are on my system under 10 seconds. - I missed your vector and unordered_map discussion. - "more complex" is not a useful metric to compare the language systems. Similar, I can easily say, that C pointer arithmetic is creates more complex situations when verifying that code is safe to use.

Compile times are not a problem in small codebases. Try to compile a 100kloc codebase using templates generously. Even your link times will easily grow over 10 seconds. Maybe even a minute. And 100kloc is still a pretty small codebase in terms of AAA development. It's true that complexity somewhat depends on the context. Complexity of a language is a useful metric when talking about mental overhead of the programmer…

So how much faster is C over C++ compilation on a AAA game codebase, can you tell me?

I, personally, cannot since I've never seen a AAA game in C. However, I've never seen a AAA game compiling under 10 seconds. Or under a minute. Just linking with a console SDK libs is about a minute if you have a fast machine.

Re: Why I Write Games in C

#198

Post by crafn » Sat, Jan 09, 2016, 6:36 PM UTC

je42 wrote: post #186

crafn wrote: post #172

Earlier quoted context omitted.

Compile times are not a problem in small codebases. Try to compile a 100kloc codebase using templates generously. Even your link times will easily grow over 10 seconds. Maybe even a minute. And 100kloc is still a pretty small codebase in terms of AAA development. It's true that complexity somewhat depends on the context. Complexity of a language is a useful metric when talking about mental overhead of the programmer…

Yes. your link times will grow. But link times are not depended on choice of language. It depends on how big your set of object files is. Depending on your platform you can optimize your build. I.e. - use dynamic link libraries - use create static libraries - carefully manage your dependencies. i.e. only include what you actually need. - hot reload game logic (where quick iteration is more important) - compile cache.…

There's a lot of tricks you can do to optimize build times, and I've tried most of them in my previous game engine. Got ~90kloc recompilation time from 15min to something like a few minutes, although that required rewriting a bunch of code to not use templates. And removing boost. Multiple days' work.

But the point is, that I'd like a language that is fast to compile by default. C seems pretty promising, as doing a full unity build of my 25kloc codebase takes something like 3 seconds. Not sure how much of that is actually compilation, and how much IO. I'm expecting the project to grow to something like 100-200kloc, and hopefully never have to spend time figuring out why the compilation takes too long, and instead use that time to do something productive.

Re: Why I Write Games in C

#199

Post by jbeja » Sat, Jan 09, 2016, 6:38 PM UTC

alekratz wrote: post #154

jbeja wrote: post #147

Earlier quoted context omitted.

As good advice as this is, waiting 10 or 20 for compilation is just sad.

Have you never had a project larger than 10 files?

I use Clojure which have a repl base workflow, I never need to compile anything to test my code and the feedback is instant.

Re: Why I Write Games in C

#200

Post by kibwen » Sat, Jan 09, 2016, 6:51 PM UTC

jb1991 wrote: post #105

>Even more than that I care about the speed of the compiler. I am not a zen master of focus, and waiting 10+ seconds is wasteful, yes, but more importantly it breaks my flow. I flick over to Twitter and suddenly 5+ minutes are gone. Quick suggestion, has really helped me: take that 10 or 20 seconds waiting for compilation, and stare out a window. This gives your eyes much needed break from focusing on a computer moni…

There are also browser extensions available to help with this, such as by forcing you to wait 30 seconds before a page on a given time-wasting site loads. Helps to break the instant gratification mechanisms that lead to destructive distraction.