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

481–490 of 556 posts

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

#481

Post by rcxdude »

Pombal wrote: post #470
jcelerier wrote: post #416

Earlier quoted context omitted.

> Even std::unique_ptr has runtime costs in release builds that a raw pointer does not. O RLY ? https://gcc.godbolt.org/z/QhbUjI

Yes, really. It's fine for simple types but for more complex types in more complex situations, you pay the price. Unique pointers carry around not just the type but also a default deleter, if you provide one. That deleter has to be copied around, checked for nullptr before execution and set to nullptr when ownership changes. For even more examples of this have a look at this talk when it comes out: https://cppcon2019…

Only if the deleter you define has any state, which is very rare and in that case you would need to copy that data around anyway...

(for example: https://gcc.godbolt.org/z/mU7hub)

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

#482

Post by omaranto »

weberc2 wrote: post #328
omaranto wrote: post #308

Earlier quoted context omitted.

Does Go really let you use closures, arrays, slices and maps when you disable the garbage collector? If so, does that just leak memory?

Yes, the idea is that you must invoke the GC when you’re not in a critical section. Alternatively you can just avoid allocations using arenas or similar. (You can use arrays and slices without the GC).

To make sure I understand, is this an accurate expansion of your comment?

Yes it would leak, to avoid leaking you could invoke the GC when you’re not in a critical section. Alternatively, if you don't use maps and instead structure all your data into arrays, slices and structs, you can just avoid allocations using arenas or similar. (You can use arrays and slices without the GC, but maps require it).

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

#483

Post by PavlovsCat »

zemo wrote: post #400
PavlovsCat wrote: post #390

Earlier quoted context omitted.

> what I find so deeply frustrating is that the argument that GC can't work in a game engine is never qualified The program having a say in how the GC behaves would be one requirement IMO. > you could run a GC on every single frame and use less than 3% of your frame budget on the GC pause Could I? In what languages?

not sure about other managed runtimes but in Go you can disable the automated GC scheduling and schedule it yourself. The GC runs in sub-millisecond time. https://blog.golang.org/ismmkeynote the point isn't "Go is good enough", because I don't know if it is because the requirements are not stated particularly clearly. If the GC took zero time, duh, it would work and people could use it, it would save them some error…

The question is control; not just total latency, but when exactly it occurs.

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

#484

Post by weberc2 »

omaranto wrote: post #482
weberc2 wrote: post #328

Earlier quoted context omitted.

Yes, the idea is that you must invoke the GC when you’re not in a critical section. Alternatively you can just avoid allocations using arenas or similar. (You can use arrays and slices without the GC).

To make sure I understand, is this an accurate expansion of your comment? Yes it would leak, to avoid leaking you could invoke the GC when you’re not in a critical section. Alternatively, if you don't use maps and instead structure all your data into arrays, slices and structs, you can just avoid allocations using arenas or similar. (You can use arrays and slices without the GC, but maps require it).

Yes, that is correct. Anything that allocates on the heap requires GC or it will leak memory. Go doesn’t have formal semantics about what allocates on the heap and what allocates on the stack, but it’s more or less intuitive and the toolchain can tell you where your allocations are so you can optimize them away. If you’re putting effort into minimizing allocations, you can probably even leave the GC on and the pause times will likely be well under 1ms.

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

#485

Post by georgeecollins »

EdwardDiego wrote: post #410
georgeecollins wrote: post #284

Earlier quoted context omitted.

>> The reality is you still have to free resources, Not exactly. Here is how the early PC 3D games I worked on did that: They would have a fixed size data buffer initialized for each particular thing you needed a lot of, such as physics info, polygons, path data, in sort of a ring buffer. A game object would have a pointer to each segment of that data it used. If you removed a game object you would mark the segment t…

> So there were like 256 possible projectiles in Battlezone(1998) Just have to say, loved that game to bits.

I think that, the thing I know for sure was there was 1,024 total physics objects, which was tanks and pilots active in the world at any time. So if you built a bunch of APCs and launched them all at a target at the same time, at some point you wouldn't be able to spawn soldiers. No one seemed to mind because in those days the bar was lower.

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

#486

Post by weberc2 »

gameswithgo wrote: post #350
weberc2 wrote: post #335

Earlier quoted context omitted.

What is Unity’s STW time? Is it optimized for latency? If not, you’re using the wrong collector. The pain point it solves is time spent debugging memory issues and generally a slower pace of development, but of course if you’re using a collector optimized for throughout, you’ll have a bad time. Further, a low-latency GC will pay off more for people who haven’t been using C or C++ for 10 years than those who have.

It is very nice to say that, in theory, a GC could work very well for performance demanding games. But until someone builds that GC, in an environment where everything else is suitable for games also, it is academic. We can't actually build a game with a theoretical ecosystem.

Of course, this is a theoretical conversation. My point is that you don’t refute the claim, “low latency GCs are suitable for game dev” with “I used a high latency GC and had a bad time”. Nor do you conclude that GCs inherently introduce latency issues based on a bad experience with a high latency GC. There is neither theory nor experiment that supports the claim that GCs are inherently unsuitable for game dev.

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

#487

Post by mcdevilkiller »

greggman2 wrote: post #363
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…

There's probably 500+ successful GC based games on the Steam store another 100000 to a million hobby games doing just fine with GC. I started game programming on the Atari 800, Apple 2, TRS-80. Wrote NES games with 2k of ram. I wrote games in C throughout the 90s including games on 3DO and PS1 and at the arcade. I was a GC hater forever and I'm not saying you can ignore it but the fact that Unity runs in C# with GC a…

And a very important one, Minecraft, atleast the Java version. It doesn't matter until you are running a couple hundred mods with lots of blocks and textures, when the max memory allocated gets saturated and it stutters like hell.

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

#488

Post by skohan »

lone_haxx0r wrote: post #398
Bekwnn wrote: post #258

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

The thing I hate about them is the backwards declaration syntax. var x:i32 = 5; ugh, it makes no sense.

You'd be surprised how fast you get used to it.

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

#489

Post by notacoward »

notacoward wrote: post #468
nightcracker wrote: post #456

Earlier quoted context omitted.

While you might test your hard real-time requirements with caches disabled, there's still reason to run the code with caches afterwards. E.g. errors that didn't match a branch or input scenario during testing which would go over budget without cache, but with cache might prevent a crash. Another could be power consumption, latency optimization, or improvement of accuracy. E.g. some signal analysis doesn't work at all…

You could be right on some of those. That didn't seem to be the prevailing attitude when I worked in that area, but as I said that was a long time ago - and it was in only a few specific sub-domains as well.

Forgot to mention: cache misses can be more expensive than uncached accesses, so testing with caches off and then turning them on in production can be a disaster if you hit a cache-busting access pattern. Always run what you tested.

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

#490

Post by kungito »

exDM69 wrote: post #438
sgtnoodle wrote: post #431

Earlier quoted context omitted.

Kerbal Space Program is a lot of fun, but for me it freezes for half a second every 10 seconds... due to garbage collection. Drives me crazy.

Even on a fast PC, Kerbal Space Program audio is choppy because of GC pauses. It's successful in spite of that, but that doesn't make it any better.

But maybe it had to do with them being able to use a higher level library, not worry about gc, and focus on other things
Post reply on HN