Why I Write Games in C (yes, C) • Hacker News Board

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

#151

Post by tomp » Sat, Sep 21, 2019, 7:03 PM UTC

zemo wrote: post #98

stephc_int13 wrote: post #74

Earlier quoted context omitted.

I know this subject quite well and I will later publish a detailed article. The real run-time cost of memory management done well in a modern game engine written without OOP features is extremely low. We usually use a few very simple specialized memory allocators, you'd probably be surprised by how simple memory management can be. The trick is to not use the same allocator when the lifetime is different. Some resourc…

as an example point, the Go garbage collector clears heaps of 18gb in sub-millisecond latencies. If I'm understanding the problem at hand (maybe I'm not!), given an engine running at a target framerate of 144 frames per second, you're working with a latency budget of about 7ms per frame. Do you always use all 7ms, or do you sometimes sleep or spin until the next frame to await user input? We can also look at it from…

"Clearing an 18GB heap" that's full of 100MB objects that are 99% dead is different than clearing an 18GB heap of 1KB objects that are 30% (not co-allocated, but randomly distributed across the whole heap).

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

#152

Post by BearOso » Sat, Sep 21, 2019, 7:05 PM UTC

benhoyt wrote: post #59

zemo wrote: 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…

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,…

People don’t write games in GC languages, so GC language developers don’t optimize for games, so people don’t write games in GC languages. It’s just a vicious cycle. It never breaks because for big projects there is too much financial risk.

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

#153

Post by kllrnohj » Sat, Sep 21, 2019, 7:06 PM UTC

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 anything that can run C but which cannot run C++?

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

#154

Post by overgard » Sat, Sep 21, 2019, 7:06 PM UTC

kjeetgill wrote: post #137

overgard wrote: post #52

Earlier quoted context omitted.

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 a…

The thing is, even with the raw pointer the hard part is resolving ownership questions, not resolving the type. The tricky questions in C are: am I responsible for freeing it or is the library? If I send it into this function call am I transferring ownership? Type deffing doesn't make any of that easier or harder to figure out. Whether the thing is a handle or a pointer doesn't really complicate things, if that makes sense.

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

#155

Post by talkingtab » Sat, Sep 21, 2019, 7:07 PM UTC

stephc_int13 wrote: post #74

zemo wrote: 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 know this subject quite well and I will later publish a detailed article. The real run-time cost of memory management done well in a modern game engine written without OOP features is extremely low. We usually use a few very simple specialized memory allocators, you'd probably be surprised by how simple memory management can be. The trick is to not use the same allocator when the lifetime is different. Some resourc…

I buy this - specialized memory allocators, after all I've used mbufs. So which languages would be good or recommended for coercing types when using memory allocators?

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

#156

Post by CameronBarre » Sat, Sep 21, 2019, 7:09 PM UTC

If it works for you and acts as a means to your end, you've won the game!

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

#157

Post by tomp » Sat, Sep 21, 2019, 7:10 PM UTC

eropple wrote: post #111

stephc_int13 wrote: post #63

Earlier quoted context omitted.

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.

It's a requirement if you do network I/O whether you realize it or not.

If a bug in a game's network IO crashes/takes over the whole OS, the security vulnerability is in the OS, not in the game.

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

#158

Post by surfsvammel » Sat, Sep 21, 2019, 7:13 PM UTC

Isn’t Rust an alternative? I don’t know Rust well enough, but wouldn’t that fit the bill?

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

#159

Post by reidrac » Sat, Sep 21, 2019, 7:14 PM UTC

cwyers wrote: post #44

stephc_int13 wrote: post #21

The author's opinion is uncommon but not unique. A few examples: https://handmadehero.org/ https://ourmachinery.com/post/physical-design/ Simple libs widely used in game dev circles: https://github.com/nothings/stb This one is a full game engine with tools made for educational purpose: https://www.raylib.com/ I do write games and game engine code and tools in C++ without using any of the OOP features. I know quite a…

> 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…

Not sure that's a good point. The CVE list for almost any programming language can get you to the conclusion that you can shoot yourself in the feet despite not being as tricky as C.

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

#160

Post by TazeTSchnitzel » Sat, Sep 21, 2019, 7:16 PM UTC

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 would be nice to make things for the web, but it feels like a terrifyingly fast moving enviroment.

> The author should look into Emscripten. It is widely used in the games industry that aims for the web.

Emscripten is wonderful. If you are slightly careful, a standard C SDL2 OpenGL application can, with a few small changes, run directly in the browser — any modern browser — with WebGL, and your single codebase can target both just by having different targets in your Makefile. I've done it for my own hobby game project. :D

It is a bit constraining as a target. Only WebGL 1.0 is supported by all major browsers, which limits you to OpenGL ES 2.0. And unfortunately, in my experience OpenGL calls in Emscripten (translated to WebGL) are much slower than native ones. But if you're content with not trying to do a max-fidelity AAA experience, it's manageable. Particularly compelling to me is the possibility of letting someone try out your game immediately on your site with no download, or even jump into a multiplayer game with a friend with just a click on a link.