Live data from Hacker News

Why I Write Games in C (yes, C)

jonathanwhiting.com

271–280 of 556 posts

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

#271

Earlier quoted context omitted.

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?

Go has many advantages over C that are not related to GC.

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

#272

Earlier quoted context omitted.

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.

Sure. That's great. That also breaks down sometimes, too.

Defense in depth. Write good, sane, secure, fail-closed code when you want to ship that code to other people--or don't write code.

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

#273
post #132

Earlier quoted context omitted.

With JS the trick is to avoid creating new objects and instead have a pool of objects that are always referenced.

Definitely! Object pools are common in game dev too from what I know. We used them extensively to reduce the amount of GC we needed.

Speedrunners thank you for reusing objects! I'm certain that decisions like this are what lead to interesting teleportation techniques and item duplications. Games wouldn't be the same without these fun Easter eggs!

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

#274

> The strongest thing on my desired, but not required list is simplicity. I find looking up language features, and quirky 'clever' api's incredibly tiring. Indeed. Clever apis are a disease endemic to the JavaScript community. expect(me).to.puke.when(i.see.shit.like.this()); > The ideal language would be one I can memorize, and then never have to look things up. You can't memorize C. The idea that you can "hold C in…

I don't think C is as bad as you're making it out to be. It's a small language. There are some quirks, but I don't think it's any worse than c++. You can even easily become a standard zealot (just look any c forum).

Rewriting software sucks. We usually don't like solving the same problem more than once.

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

#275
post #20
post #3

Write C code. Compile with C++ compiler. Catch lots of bugs at compile time.

> Write C code. Compile with C++ compiler. What C only compiler were you thinking of? Most of the ones I can think of are toy compilers. If you're making a game, you're going to be using clang/MSVC/gcc. For catching bugs early, at least as important as the compiler are * Enabling additional compiler warnings and -Werror * Checking for memory leaks with valgrind * checking for Undefined Behavior with UBSan * Using mix…

All of those compiler families have separate C and C++ compilers. They’re saying to use g++ to compile your .c’s instead of gcc.

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

#276

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…

I don't know, he seems extremely productive to me. A lot of the time he spends in the debugger is more of him trying to figure out exactly what is happening with an api or memory usage rather than trying to figure out something he coded "wrong".

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

#277
I had never considered a "data-centric" approach to be anti OOP but from the article:

> I am not an OOP convert. I've spent most of my professional life working with classes and objects, but the more time I spend, the less I understand why you'd want to combine code and data so rigidly. I want to handle data as data and write the code that best fits a particular situation.

I've come around to the idea much more that data should be the privileged structure and code should be considered transformations of the data. In some sense, code should be light and interchangeable and let the data is the first class citizen.

Are OOP and "data-centric" approaches at odds with each other? Does OOP only have validity when the data is relatively "small" and can be abstracted away easily?

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

#278

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…

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. As you may have guessed, it was certified code with hard real time constraints. Exceeding the cycle time is equivalent to a crash, causing the watchdog to trigger a reset.

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

#279
post #129

Earlier quoted context omitted.

C is closer to the hardware in the sense that with any given C code, I can pretty much predict what the generated assembly will look like. You cannot say the same for, say, Python.

> pretty much Not really... Not only the generated assembly code heavily depends on the compiler (LLVM, gcc, Intel, MSVC...) and the optimization settings, you cannot be completely sure what the machine code generated by the assembler even looks like these days.

and you also won't be able to predict the timings of complex code as various "uncore" and on-core resource limitations bite

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

#280

I’m not sure why but programmers like to reject entire languages instead of just rejecting the features they don’t like. A lot of stuff in C++ is entirely avoidable. Protocol-oriented programming is extremely useful for games and I like Objective-C for that reason. (Objective-C doesn’t meet his mentioned goal of portability but this is an example where C++ could be used to gain “light” inheritance without having to o…

> Objective-C doesn’t meet his mentioned goal of portability

Clang implements it, last I checked, meaning that it should be (at least in theory) portable to every platform Clang supports, no?

Post reply on HN