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

351–360 of 556 posts

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

#351

Post by seba_dos1 »

Nobody? I write my games in C as well :P The only other reasonable choice would be Rust, but never got past "have to write bindings to my framework" stage with it so far.

Pretty much the only things I miss in C for gamedev are sensible string manipulation and lambdas/closures. Otherwise it works really well - I don't think I would be able to make my games so multiplatform (at the moment GNU/Linux, macOS, Windows, Android, Emscripten, Librem 5, Nokia N900, Pocket CHIP, Raspberry Pi, Steam Link, Nintendo Switch w/ devkitPro; more to come...) so easily with any other language.

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

#352

Post by gameswithgo »

zemo wrote: post #288
h0l0cube wrote: post #285

Earlier quoted context omitted.

I worked as a games programmer for 8 years in C/C++, and spent an accumulated 2 years just doing optimisation, during the time of 6th and 7th generation consoles. Freeing resources in a deterministic manner is important for the following reasons: FRAME RATE: having a GC collect at random frames makes for jerky rendering SPEED: Object pools allow reuse of objects without allocing/deallocing, and can be a cache-aligned…

you can turn off the gc in Go and run it manually. you can also write cache-aligned arrays of structs in Go if you want to. you can allocate a slab and pull from it if you want to. the existence of a GC doesn't preclude these possibilities.

The existence of a GC, even when it can be turned off, does preclude a great many other possibilities, in practice. One issue which is nearly universe, and extra bad in Go, is the extra cost of FFI with C libs, which is necessary in games to talk to opengl, or sdl2, or similar.

If you aren't going to use the GC, then you open up a lot of other performance opportunities by just using a language that didn't have one in the first place.

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

#353

Post by squeaky-clean »

coldtea wrote: post #331
detaro wrote: post #319

Earlier quoted context omitted.

What percentage of the market is A/V build to actual hard real-time standards, and not expected to run on devices that can't provide it (so no PCs with normal OSes, no smartphones)? For the vast majority, soft real-time is fine, since an occasional deadline-miss results in minor inconvenience, not property damage, injury or death. I assume some dedicated devices are more or less hard real time, due to running way sim…

> For the vast majority, soft real-time is fine, since an occasional deadline-miss results in minor inconvenience, not property damage, injury or death. A "minor inconvenience" like a recording session going wrong, a live show with stuttering audio, skipped frames in a live TV show, and so on?

Most professional recording studios are using consumer computer hardware that can't do hard realtime with software that doesn't support hard realtime.

People like deadmau5, Daft Punk, Lady Gaga all perform with Ableton Live and a laptop or desktop behind their rig. If it were anything more than a minor inconvenience, these people wouldn't use this.

It's very unlikely to have audio drop outs, a proper setup will basically never have them. But still if you have one audio dropout in your life, you're not dead, your audience isn't dead, a fire doesn't start, a medical device doesn't fail to pump, and so on.

And yes you can badly configure and system, but the point is you can't configure these to be 100% guaranteed, 99.99% is perfectly fine.

Edit: Sometimes people call these "firm" realtime systems. Implying the deadline cannot be missed for it to operate, but also that failure to meet deadlines doesn't result in something serious like death (e.g in a video game you can display frames slower than realtime and it kind of works but feels laggy, however you cannot also slow down the audio processing because you'll a lowered pitch, so you have to drop the audio.)

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

#354

Post by a_t48 »

drblast wrote: post #321
loeg wrote: post #318

Earlier quoted context omitted.

Why even define a malloc() in this environment if it always returns NULL?

So you crash immediately if someone tries to use it or a library gets added that does? Never experienced the malloc() thing but do throw exceptions and fail fast under conditions like these so they're caught in testing.

I think what he's asking to do is to make it a linker failure by not adding it to the standard lib at all. Compile fails are nicer than runtime fails.

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

#355

Post by Impossible »

GuB-42 wrote: post #278
Skunkleton wrote: post #251

Earlier quoted context omitted.

Its not just pauses either. Non-deterministic memory usage is a big deal too.

I have actually worked on a system where malloc() was forbidden. In fact it always returned null. Buffers were all statically allocated and stack usage was kept to a minimum (it was only a few kB anyways). The software was shipped with a memory map file so you know exactly what each memory address is used for. A lot of test procedures involved reading and writing at specific memory locations. It was for avionics BTW.…

Malloc was forbidden in a AAA title I worked on. Interestingly enough we also had two (!!!) embedded garbage collected scripting languages that could only allocate in small (32MB, 16 MB) arenas and would assert if they over allocated.

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

#356

Post by seanmcdirmid »

loeg wrote: post #318
GuB-42 wrote: post #278

Earlier quoted context omitted.

I have actually worked on a system where malloc() was forbidden. In fact it always returned null. Buffers were all statically allocated and stack usage was kept to a minimum (it was only a few kB anyways). The software was shipped with a memory map file so you know exactly what each memory address is used for. A lot of test procedures involved reading and writing at specific memory locations. It was for avionics BTW.…

Why even define a malloc() in this environment if it always returns NULL?

Because even if you don't use it directly, you might use some code that uses it. And even then, it might not ever be called given the way you are reusing the code, so...a dynamic check is the best way to ensure it never actually gets used.

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

#357

Post by seba_dos1 »

srbby wrote: post #264
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.

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

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

That's an argument for using C in gamedev, isn't it? ;)

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

#358

Post by notacoward »

PorterDuff wrote: post #316
notacoward wrote: post #241

Earlier quoted context omitted.

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

""soft" real-time (e.g. games, or audio/video) " Hah. Who sez that audio and video products have 'soft' real time? Go on now.

I didn't make up the terminology. It was already in common use at least thirty years ago when I was actively working in that domain. To simplify, it's basically about whether a missed deadline is considered fatal or recoverable. That difference leads to very different design choices. Perhaps some kinds of video software is hard real-time by that definition, but for sure a lot of it isn't. I'd apologize, but it was never meant to be pejorative in the first place and being on one side of the line is cause for neither pride nor shame. They're just different kinds of systems.

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

#360

Post by PezzaDev »

zem wrote: post #87
F-0X wrote: post #66

Earlier quoted context omitted.

>On the other hand, it is rapidly getting very complicated This seems to be the case for almost any "C replacement", and it will be (my prediction, at least) the reason they all fail. I feel I might be a bit of an outlier in this respect, but I have only ever enjoyed using languages which are small and simple - C, Go, Scheme. The times I've tried Rust, it's been nice to have code that cannot segfault, but I find it s…

you would probably like zig, if you haven't given it a look yet.

I feel zig is now experiencing feature creep now too sadly. Async and await and coroutines are being added to it, because it's the new-ish hotness I guess? Stopped paying attention to the language after that. I was hoping for a more streamlined language.
Post reply on HN