Live data from Hacker News

Why I Write Games in C (yes, C)

jonathanwhiting.com

491–500 of 556 posts

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

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

The two most popular engines (Unity and Unreal) both have a GC for “front end” gameplay code. The trade-offs are real: manual resource management would be incredibly complex for large modern games (think open world, multiplayer), but GC spikes are a common issue in both engines.

The places where you generally don’t want a GC are with low level engine code, like the renderer - code that might execute hundreds or thousands of times a frame, where things like data locality become paramount. GC does you zero favors there.

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

#492
post #81

Earlier quoted context omitted.

I like rust, but for me, it is significantly more difficult to read and write. Same can be said about C++ with extreme STL code.. I prefer to read and write simple C like syntax. I would love it if I can get Rust concept of borrowing in C, or even simple operator overloading..

Ironic, the most complicated thing for me to understand when I started writing rust was borrowing and lifetimes. The rest of the common features of Rust isn't too complicated to understand.

Understanding the concepts is not the issue with me (as of now). It is the hard to read syntax (my personal opinion!). It puts a lot strain on my mind. Same is the case with C++ with extreme use of STL. I have difficulty in reading that, although with clear mind, I will eventually get the code, it is not fun.

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

#493
post #323

Earlier quoted context omitted.

It serves the huge purpose of doing 100% of the tracking work. Whats easier? Manually tracking all of your allocations and frees as well as worrying about double frees and pointer ownership or calling GC.Collect() during a load screen?

What's easier? Knowing that you can use all your memory again after you've explicitly freed the resources you used, or knowing that you can use all your memory again after a call to GC.Collect() does god-knows-what?

I think the garbage collector is easier over all, obviously.

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

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

As a gamedev i would LOVE to give the gc 1ms per frame if it would be hard bounded and allocs are guaranteed not to stall.

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

#498

Earlier quoted context omitted.

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…

Minecraft is the only Java based popular game I can think of. And damn did I love Subnautica.

The recent roguelite hit Slay the Spire (over a million copies sold on Steam) is also made in Java.

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

#500

Earlier quoted context omitted.

I actually have written software for video routers and character generators. We didn't consider them hard real time, though I wouldn't claim that such was standard industry usage. For example, if you're doing a take, you have to complete it during the blanking interval, but usually the hardware guarantees that. In the software, you want you take to happen in one particular vertical blanking interval (and yes, it real…

I work on an open-source music sequencer ( https://ossia.io ) and no later than two days ago I had a fair amount of mails with someone who wanted to know the best settings for his machine to not have any clicks during the show (which are the audio symptoms of "missed deadline"). I've met some users who did not care, but the overwhelming majority does, even for a single click in a 1-hour long concert.

If it's running in a consumer OS (not a RT one) and it counts on having enough CPU available to avoid missing the deadline, that's exactly what soft-realtime is.

Compare your “not a single click in an hour [for quality reason]” to a “not a single missed deadline in 30 years of the life expectancy of a plane, on a fleet of a few thousands planes [for safety reasons]”. That's the difference of requirements between hard and soft RT.

I did some soft real-time (video decoding) and I have a friend working on hard real-time (avionics) and we clearly didn't worked in the same world.

Post reply on HN