Didn't even consider Rust...
Why I Write Games in C (yes, C)
211–220 of 556 posts
Re: Why I Write Games in C (yes, C)
#212> 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…
Not a game developer, but I used to write UI addons for World of Warcraft. WoW allows you to customize your UI heavily with these Lua plugins ("addons") and Lua is garbage collected. It's a reasonable incremental GC so it shouldn't be too bad in theory. But in practice it can be horrible. You end up writing all kinds of weird code just to avoid allocations in certain situations. And yeah, GC pauses due to having lots…
I’ve shipped C++ games and Unity games. I have never spent more time managing memory than in C#. You have to jump through twisted, painful hoops to avoid the GC.
Memory management is ultimately far simpler and easier in C++ than in C#.
Re: Why I Write Games in C (yes, C)
#213No 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 introduce more bugs than maintaining the C program ever would. I don’t care what language you rewrite it in."
From https://drewdevault.com/2019/03/25/Rust-is-not-a-good-C-repl...
(I think it's a bit mean to downvote me for not knowing that he addressed that point in a separate page of his. He didn't link to this Rust review at all!)
Re: Why I Write Games in C (yes, C)
#214Earlier 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…
> Go garbage collector clears heaps of 18gb in sub-millisecond latencies
At the expense of a lot of work from the GC. In production we had 30% of the usage coming from the GC alone…
But for game development the problem isn't going to be the GC anyway: cgo is just not adapted to this kind of tasks (and you cannot avoid cgo here).
Re: Why I Write Games in C (yes, C)
#215So... essentially "I know and like C". Which is great! But as you say, that's not particularly useful for anybody else.
Well, it is useful to know and like C.
Re: Why I Write Games in C (yes, C)
#216The 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…
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 properly write code, but when you actually see how he codes, what mess he produces and how long he spends live debugging it all the time. He constantly finds bugs in code he wrote earlier, etc. Yet he is so totally unable to find anything remotely wrong about the way he does things, and that there might have been some ideas invented in the last 30 years that could make him more productive.
I have zero respect for those types of programmers. I would quit any job instantly if I ever had to work with guys like this.
Re: Why I Write Games in C (yes, C)
#217Earlier quoted context omitted.
> It is also possible to allocate a large block of memory and then manage it yourself. At which point you're mostly just writing C in Go.
Actually you're not. I would very much prefer a stripped down version of Go used for these situations rather than throwing more C at it. The main benefits of using Go are not the garbage collection, its the tooling, the readability (and thus maintainability) of the code base, the large number of folks who are versatile in using it.
Readability is subjective.
Large user base? C is number 2. Go isn't even in the top 10.[1]
Tooling? C has decades of being one of the most commonly used languages, and a general culture of building on existing tools instead of jumping onto the latest hotness every few months. As a result, C has a very mature tool set.
Re: Why I Write Games in C (yes, C)
#218Earlier quoted context omitted.
Actually you're not. I would very much prefer a stripped down version of Go used for these situations rather than throwing more C at it. The main benefits of using Go are not the garbage collection, its the tooling, the readability (and thus maintainability) of the code base, the large number of folks who are versatile in using it.
Are you saying that there are more go developers than c developers? Is there a user survey that shows such things? I'm curious what the ratio is.
He's wrong: https://www.tiobe.com/tiobe-index/
Re: Why I Write Games in C (yes, C)
#219Earlier 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…
Go’s GC is low latency and it allows you to explicitly trigger a collection as well as prevent the collector from running for a time. I would wager that the developer time/frustration spent taming the GC would be more than made up for by the dramatic improvement in ergonomics everywhere else. Of course, the game dev libraries for Go would have to catch up before the comparison is valid.
Why is this downvoted? is it factually wrong? (I don't know Go so I'm asking)
Re: Why I Write Games in C (yes, C)
#220Earlier quoted context omitted.
Due the low throughput of Go's GC (which trades a lot of it in favor of short pause duration), you risk running out if memory if you have a lot of allocations and you don't run your GC enough times.
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?