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

Why I Write Games in C (yes, C)

jonathanwhiting.com

Post reply on HN
Print view View original

251–260 of 556 posts

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

#251

Post by Skunkleton »

notacoward wrote: post #241
bcrescimanno wrote: post #70

Earlier quoted context omitted.

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…

> it was generally non-deterministic This is basically it. People who have never worked on actual real-time systems just never seem to get that in those environments determinism often matters more than raw performance. I don't know about "soft" real-time (e.g. games, or audio/video) but in "hard" real-time (e.g. avionics, industrial control) it's pretty routine to do things like disable caches and take a huge perform…

Its not just pauses either. Non-deterministic memory usage is a big deal too.

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

#252

Post by flatline »

einpoklum wrote: post #245
flatline wrote: post #205

Earlier quoted context omitted.

I think it’s safe to say for the general case that if you have millions of widely-shared smart pointers you are not following RAII principles. At that point you are left with poorly-implemented reference counting, with a ton of synchronization overhead.

Which RAII principle would you say would be broken in this scenario?

If the lifetime of your objects are not bound to any scope, I’d say you’re well out of the realm of any real benefit that RAII would provide over GC. This is a continual problem that arises with a shared ownership model. The specific principle this violates is encapsulation - there is still encapsulation at the level of the smart pointer, but not with its consumers.

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

#253

Post by Buge »

stephc_int13 wrote: post #63
cwyers wrote: post #44

Earlier quoted context omitted.

> there are simple ways to avoid shooting yourself in the feet with those A cursory look at the CVE list for any C software in the wild indicates that no, there are not simple ways to avoid shooting yourself in the feet with manual memory management in C. It's _incredibly hard_ even for "elite" programmers who have a lot of incentive to avoid these problems. The counterpoint is that people are probably going to spend…

Yeah, I am not talking about vulnerabilities. I am simply talking about ease of use and avoidance of leaks and crashes. Writing super secure code is usually not a requirement for gamedev, and I completely agree, this is hard and potentially harder in C than, say, in Rust.

Vulnerabilities can be used to cause crashes.

In fact, generally a memory safety vulnerability will initially manifest itself as a crash before a more advanced targeted exploit can be used against it.

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

#254

Post by mntmoss »

mlthoughts2018 wrote: post #227
Gene_Parmesan wrote: post #190

Earlier quoted context omitted.

Which is why you generally almost never use the standard malloc to do your piecemeal allocations. A fair number of codebases I've seen allocate their big memory pools at startup, and then have custom allocators which provide memory for (often little-'o') objects out of that pool. You really aren't continually asking the OS for memory on the heap. In fact, doing that is often a really bad idea in general because of th…

Doesn’t this just change semantics? Whatever custom handlers you wrote for manipulating that big chunk of memory are now the garbage collector. You’re just asking for finer grained control than what the native garbage collection implementation supports, but you are not omitting garbage collection. Ostensibly you could do the exact same thing in e.g. Python if you wanted, by disabling with the gc module and just writi…

The semantics matter. A lot of game engines use a mark-and-release per-frame allocation buffer. It is temporary throwaway data for that frame's computation. It does not get tracked or freed piecemeal - it gets blown away.

Garbage collection emulates the intent of this method with generational collection strategies, but it has to use a heuristic to do so. And you can optimize your code to behave very similarly within a GC, but the UI to the strategy is full of workarounds. It is more invasive to your code than applying an actual manual allocator.

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

#255

Post by Skunkleton »

littlestymaar wrote: post #220
xyproto wrote: post #193

Earlier quoted context omitted.

For a computer game, if you start out by allocating a large block of memory, then manage it yourself, I don't see how this would be a problem.

You're not using the GC at all then. Why use Go (and praise its GC) in that case?

For the joy of getting the round peg through the square hole of course.

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

#256

Post by therein »

mlthoughts2018 wrote: post #227
Gene_Parmesan wrote: post #190

Earlier quoted context omitted.

Which is why you generally almost never use the standard malloc to do your piecemeal allocations. A fair number of codebases I've seen allocate their big memory pools at startup, and then have custom allocators which provide memory for (often little-'o') objects out of that pool. You really aren't continually asking the OS for memory on the heap. In fact, doing that is often a really bad idea in general because of th…

Doesn’t this just change semantics? Whatever custom handlers you wrote for manipulating that big chunk of memory are now the garbage collector. You’re just asking for finer grained control than what the native garbage collection implementation supports, but you are not omitting garbage collection. Ostensibly you could do the exact same thing in e.g. Python if you wanted, by disabling with the gc module and just writi…

I mean, nobody is suggesting they leave the garbage around and not clean up after themselves.

But instead what you can do is to reuse the "slots" you are handing out from your allocator's memory arena for allocations of some specific type/kind/size/lifetime. If you are controlling how that arena is managed, you will find yourself coming across many opportunities to avoid doing things a general purpose GC/allocator would choose to do in favor of the needs dictated by your specific use case.

For instance you can choose to draw the frame and throw away all the resources you used to draw that frame in one go.

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

#257

Post by mlindner »

maxharris wrote: post #213
maxharris wrote: post #23

No mention of Rust?

So I dug some more, and it turns out that while he does have something to say about Rust, I'm not sure I'm convinced by his conclusion about safety: "Safety. Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows. I especially refuse to “rewrite it in Rust” - because no matter what, rewriting an entire program from scratch is always going to introdu…

Holy... Believe nothing that guy says. I'll just wait until he releases his first game with network connection and instantly gets a buffer overflow and his game becomes an entry for worms into people's systems.

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

#258

Post by Bekwnn »

I have similar frustrations using C++, but don't feel using C or even Rust would be an improvement, more of "side-grade" due to various tradeoffs those languages have for game development compared to C++.

I am excited about the development of both Zig and Jai since they both are trying to fill what I believe is a much needed role of a C-like language with a few more nice language features like better compile-time code, better compiler error messages, better error handling that doesn't use exceptions, and build scripts written natively in the languages, all while sticking to fast compile times and simplicity.

Games are a decently different domain than others, and there is a lot of valid complaining about C++. It's a known issue, we just need something that's clearly better, which so far I think those two languages are. I've chipped in a few dollars a month to support Zig and have been using it in my free time, but it still very much feels like the version 0.4.0 that it is.

This wait will probably be a few more painful years.

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

#259

Post by pyrale »

mlthoughts2018 wrote: post #227
Gene_Parmesan wrote: post #190

Earlier quoted context omitted.

Which is why you generally almost never use the standard malloc to do your piecemeal allocations. A fair number of codebases I've seen allocate their big memory pools at startup, and then have custom allocators which provide memory for (often little-'o') objects out of that pool. You really aren't continually asking the OS for memory on the heap. In fact, doing that is often a really bad idea in general because of th…

Doesn’t this just change semantics? Whatever custom handlers you wrote for manipulating that big chunk of memory are now the garbage collector. You’re just asking for finer grained control than what the native garbage collection implementation supports, but you are not omitting garbage collection. Ostensibly you could do the exact same thing in e.g. Python if you wanted, by disabling with the gc module and just writi…

You can do many things in many languages. You may realize in the process that doing useful things is made harder when your use case is not a common concern in the language.

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

#260

Post by Hokusai »

kllrnohj wrote: post #153
Hokusai wrote: post #57

Some points: > All my solo project games I've been making recently have been written in 'vanilla' C. The author is talking about solo projects, not big projects where dozens of teams may be collaborating. It is good that he makes the point at the beginning. > Nobody does this. This is just not true. There are solo projects developed in Python, Go, even Commodore 64 assembly. When you do something for fun, you can hav…

> > It can be made to run on just about anything. Usually this is relatively easy. It is hard to imagine a time when this won't be the case. > This is the big advantage of C. If doesn't run C, probably it just doesn't run at all. Is that really an advantage of C over C++? They have identical runtime requirements and typically share a common compiler (although one of those, MSVC, barely supports C). Is there actually…

> Is that really an advantage of C over C++?

You may find that not all C++ features are supported for the least popular processors or for old ones.

Standard C++ threads, for example, were not supported by GCC for Windows for a long time. I do not know what is the current status, thou.

Post reply on HN