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

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

#261

Post by drudru11 » Sat, Sep 21, 2019, 9:46 PM UTC

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…

Wow - disabling the caches is an extreme measure. I get it though. After doing that, you can (probably) do cycle counting on routines again. Just like the 80s or earlier.

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

#262

Post by yellowapple » Sat, Sep 21, 2019, 9:50 PM UTC

jackjeff wrote: post #184

oppositelock wrote: post #166

Earlier quoted context omitted.

I used to work on realtime graphics code which was used in flight simulators for the FAA and USAF, then moved into the games industry and led the design of a couple of game engines, to give you an idea where I'm coming from. The military grade flight sims actually had contract requirements like, "you may never miss a single frame in a week of usage", etc, so solving this problem was critical. When working on code suc…

> C++ is as complex as you want to make it I second that. I always find the attitude of “C++ is bad so I’m going to stick to C” really bizarre. You can use C++ as a better C. - use type inference and references instead of pointers. Writing C style code with these features makes it more readable. - Don’t like OO programming. Stick to struct with all members public. It’s going to be a lot better than doing the same thi…

> use exceptions instead of return code for errors

I happen to have the exact opposite opinion. Exception handling tends to feel too "magical" (read: non-deterministic, hard to behaviorally predict, etc.) relative to just returning an error code.

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

#263

Post by jdmoreira » Sat, Sep 21, 2019, 9:54 PM UTC

ru999gol wrote: post #216

Scarbutt wrote: post #38

Earlier quoted context omitted.

Handmadehero started as C but transition to C++ AFAICT ?

I think he is the perfect example of why I don't care what those C (or minimalist subset C++) programmers have to say. When you actually see how he works, how much time he spends debugging his messy code. They are all sooooooo far away from what I would describe as remotely good, clean code. And all so full of themselves too of course. I liked Handmadehero for this reason, he is so arrogant and certain about how to p…

wow. You must be a prolific game programmer like Casey Muratori, right?

You understand that he is an extremely successful programmer in his field and has the respect of thousands of programmers world wide?

Maybe you can share some of your accomplishments with us.

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

#264

Post by srbby » Sat, Sep 21, 2019, 9:55 PM UTC

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.

>Writing super secure code is usually not a requirement for gamedev

Many consoles have been "jailbroken" by making buggy games load specially crafted savegames that ended up in code execution.

That also extends to players downloading innocent-looking maps, savegames, models. etc that exploit bugs and end up in code execution too.

Also if you have an online game then you can have RCE bugs, especially if players are expected to be able to connect to 3rd party servers.

(Not saying I necessarily disagree with you, just a counterpoint)

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

#265

Post by yellowapple » Sat, Sep 21, 2019, 10:05 PM UTC

zemo wrote: post #100

facorreia wrote: post #54

Earlier quoted context omitted.

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

not sure that cpu affinity is trivially solveable to avoid mutex contention here, since game entities can often mutate one another when they interact. how do you determine which entities are computed by which cores to minimize the cost of synchronizing the work between the cores?

One strategy might be to correlate CPU affinity with spatial proximity. That is: two entities that are close together are more likely to mutate one another than two entities far apart, so the two close together should be on the same CPU/core/thread and the other should be on a different thread (probably with other entities closer to it).

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

#266

Post by llogiq » Sat, Sep 21, 2019, 10:06 PM UTC

fluffything wrote: post #128

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…

+1. We have a large Rust code base, and we forbid Vec and the other collections. Instead, we have different types of global arenas, bump allocators, etc. that you can use. These all pre-allocate memory once at start up, and... that's it. When you have well defined allocation patterns, allocating a new "object" is just a "last += 1;` and once you are done you deallocate thousands of objects by just doing `last -= size…

What arena types do you use?

If you need to store pointers and want to conserve a bit of memory, perhaps my compact_arena crate can help you.

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

#267

Post by axaxs » Sat, Sep 21, 2019, 10:07 PM UTC

jdmoreira wrote: post #230

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 just want to say that no, you don’t need to free the resources. It's very possible to use a fix amount of heap memory during the whole lifecycle of your game. In fact I think that’s what people should aim for in 90% of the cases.

You can do the same thing in GC'd languages, though.

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

#268

Post by lightedman » Sat, Sep 21, 2019, 10:07 PM UTC

einpoklum wrote: post #248

seamyb88 wrote: post #165

Earlier quoted context omitted.

Some people just like writing code. You can't say that C's features are insufficient, when you can implement the vast majority of C++ features in native C, and all of 'em with tooling. What's wrong with having direct control of only the features you need? What's wrong with code generation? Not to trample on C++, I like it (albeit less than C). I would definitely create C++ if it didn't exist.

> when you can implement the vast majority of C++ features in native C No, you absolutely cannot, even in principle. C++ is not "C with classes" and some syntactic sugar like it started out. That's not been the case for many years already. Also, even the features you can implement - you won't; you don't have the person-years for that. You will have to, need to, use libraries. For those you need to compare the librari…

"No, you absolutely cannot, even in principle."

Which is why it has been done for my 2D Second Life clone?

Some of us can very easily implement C++ stuff in native C.

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

#269

Post by yellowapple » Sat, Sep 21, 2019, 10:08 PM UTC

eropple wrote: post #189

tomp wrote: post #177

Earlier quoted context omitted.

I disagree. As a user, I want to be able to run weird software without having it impact the rest of my system. Browsers and mobile OSs get this much more right than desktop OSs.

This does not meaningfully follow. What you "want" is orthogonal to the responsibility of the vendors of software. The OS should protect where it can. So should software, lest your networked game nuke, say, the parts of your home directory to which it has permissions because without those permissions it can't do something it needs to. This is just defense-in-depth. It's super basic stuff and HN is literally the only…

I suspect GP's point is that a networked game should be limited in access to only parts of one's home directory relevant for that game (that is: the game's own save data or configuration files or what have you). It is absolutely the job of the operating system to provide that sort of sandboxing/isolation.

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

#270

Post by cozzyd » Sat, Sep 21, 2019, 10:09 PM UTC

weberc2 wrote: post #188

rdbell wrote: post #176

Earlier quoted context omitted.

I'd be willing to wager that C programmers would be more comfortable working with a Golang codebase than Golang programmers would be working with a C codebase. There may be more "C programmers" by number but a Golang codebase is going to be more accessible to a wider pool of applicants.

In my experience it takes a few days for a moderate programmer to come up to speed on Go, whereas it takes several months for C. You need to hire C programmers for a C position, you can hire any programmers for a Go position.

If they don't already know C though, how well will they cope with manual memory management?