Live data from Hacker News

Why I Write Games in C (yes, C)

jonathanwhiting.com

131–140 of 556 posts

Re: Why I Write Games in C (yes, C)

#131
post #31

Quote: "I want to produce less bugs, so I want strict typing, strong warning messages and static code analysis". Yeah, at strict typing you lost me buddy. Let's just go with somebody else reply, as in you like C and that's why you do your hobbies in. Nothing wrong with that in the end.

Implying that typing does not prevent bugs is the strangest programming meme I’ve ever heard, and its proponents push it so hard that I wonder if there’s somewhere I can sign up to be paid for it. We rarely are able to directly compare the cost/benefit of strict typings vs loose typings, but with JS vs TS you get a pretty direct comparison, and it is absolutely unsurprising that TS is eating the JS world; it does pre…

> TS is eating the JS world

Definitely another reason to stick to C. In C you don't have to change to another language or another framework, or yet another design principle, or whatever hype that is being followed by a horde of idiots that think they're incredibly smart.

C is still C. I love that so much. No endless discussions about type safety. And yes, with C I can shoot myself in the foot, which is great because I like sharp tools that can cut. Tell me of a cook who prefers a blunt knife. But at least, I'm the one doing it in contrast to web development where you use hundreds of amateur libraries that kill you in a snap, without you ever finding out what actually happened.

Re: Why I Write Games in C (yes, C)

#132
post #46

> The stop-the-world garbage collection is a big pain for games, stopping the world is something you can't really afford to do. I love this opinion from games programmers because they never qualify it and talk about what their latency budgets are and what they do in lieu of a garbage collector. They just hand wave and say "GC can't work". The reality is you still have to free resources, so it's not like the garbage c…

Disclaimer: I'm not a game developer; but, I've worked on a lot of projects with tight frame time requirements in my time at Netflix on the TVUI team. I also have no experience in Go so I can't comment on the specifics of that garbage collector vs. V8. I don't think it's necessarily that it "can't" work as much as it takes away a critical element of control from the game developers and the times you find yourself "at…

With JS the trick is to avoid creating new objects and instead have a pool of objects that are always referenced.

Re: Why I Write Games in C (yes, C)

#133
post #87
post #66

Earlier quoted context omitted.

>On the other hand, it is rapidly getting very complicated This seems to be the case for almost any "C replacement", and it will be (my prediction, at least) the reason they all fail. I feel I might be a bit of an outlier in this respect, but I have only ever enjoyed using languages which are small and simple - C, Go, Scheme. The times I've tried Rust, it's been nice to have code that cannot segfault, but I find it s…

you would probably like zig, if you haven't given it a look yet.

Zig is promising as a "better C" but is nowhere near a 1.0 release as far as I know.

Re: Why I Write Games in C (yes, C)

#134
post #59

Earlier quoted context omitted.

In particular I know that Go's GC is optimized for very low latency (rather than throughput), and is not a stop the world GC. So I'm wondering why it doesn't work for games? Are the pauses still too high for games, or is he missing something? Benchmarks or concrete results in Go would be great here. Edit: specifics from https://blog.golang.org/ismmkeynote - Go hugely improved GC latency from 300ms before version 1.5,…

maybe this is an ignorant question, but why do people always cite GC latencies in seconds? is there an implied reference machine where the latency is 300ms? I would expect it to vary a lot in the wild based on cpu frequency and cache/memory latency. is there some reason why this doesn't matter as much as I think it does?

How else is it going to be cited?

People understand seconds, and any other measurement would require specifying a lot of computer-specific stuff, and if you're going to do that, then you might as well fully specify the workload, too, to answer those questions before they come.

It isn't meant to be a precise answer, it's meant to put the GC performance broadly in context.

Re: Why I Write Games in C (yes, C)

#135
post #3

Write C code. Compile with C++ compiler. Catch lots of bugs at compile time.

C++ is not a superset of C. There is valid C code not compilable with C++ compiler.

The point is to eschew the use of C features not supported by C++ in order to catch bugs. Just read up on the incompatibilities deliberately introduced by the C++ committee and you'll likely agree that these are good things. Implicit conversions to void*? No thank you. Tentative definitions? I don't need that so give me an error.

Re: Why I Write Games in C (yes, C)

#136
post #5

So... essentially "I know and like C". Which is great! But as you say, that's not particularly useful for anybody else.

Well, he does say why he likes C better, so it is useful for others. The problem is that learning how to use C effectively is a lot harder than learning other/modern languages. Therefore, anybody who doesn't know how to use C is probably better of learning one of those other languages.

15 years ago, I spend some time modding with the Quake 3 engine which is written in C too and while I wouldn't categorize myself as 'knowing how to use C effectively' I sympathize with the author's opinion. I totally agree with Go being a revisited C and that C can enable simplicity.

The only part where my opinion is different is about Javascript. Yes, it is a dangerously fast-moving ecosystem, but I think it offers so much value in terms of cross-platform development that I think it is a mistake not to participate. After all, the browser APIs are quite stable and the biggest issue is the constantly changing trend about which libraries are going to be the next big thing.

Re: Why I Write Games in C (yes, C)

#137
post #37

Earlier quoted context omitted.

It's considered horrendous practice to typedef to a pointer of something. Not sure why this can be considered easy.

Citation needed on that, plenty of major libraries typedef pointers all the time.

I don't do much in C anymore and definitely never used a library that had a typedef'd pointer type. If I had to guess I'd imagine it's something like: variables that are pointers are syntactically different. Unless they're used "opaquly" I guess.

If I see a declaration like "Foobar baz;" I don't know which of "baz.boo", "baz->boo" or "baz[x]" are syntactically valid at a glance.

Dunno if that's a huge deal but it's all I came up with.

Re: Why I Write Games in C (yes, C)

#138
post #46

> The stop-the-world garbage collection is a big pain for games, stopping the world is something you can't really afford to do. I love this opinion from games programmers because they never qualify it and talk about what their latency budgets are and what they do in lieu of a garbage collector. They just hand wave and say "GC can't work". The reality is you still have to free resources, so it's not like the garbage c…

> I love this opinion from games programmers because they never qualify it and talk about what their latency budgets are and what they do in lieu of a garbage collector.

https://www.google.com/search?q=memory+management+site%3Agdc...

Re: Why I Write Games in C (yes, C)

#139

He didn't talk about Rust. I feel rust bridges the gap, it's just library support still sucks.

> and ideally I'd like to have the option of developing for consoles. So it's important that my programming language is portable, and that it has good portable library support.

Every console will have a C toolchain out of the box, we can't say the same for rust.

Re: Why I Write Games in C (yes, C)

#140
post #46

> The stop-the-world garbage collection is a big pain for games, stopping the world is something you can't really afford to do. I love this opinion from games programmers because they never qualify it and talk about what their latency budgets are and what they do in lieu of a garbage collector. They just hand wave and say "GC can't work". The reality is you still have to free resources, so it's not like the garbage c…

Indeed, and also what about the effect of multiple cores? You could have 7 cores working on game logic and one doing GC.

> Indeed, and also what about the effect of multiple cores? You could have 7 cores working on game logic and one doing GC.

Note that those independent cores all share common resources. L3 cache & memory bandwidth are both shared, and a GC workload slams both of those resources pretty heavily. So it's still going to have an impact even though it's running on its own core.

Post reply on HN