Live data from Hacker News

Why I Write Games in C (yes, C)

jonathanwhiting.com

421–430 of 556 posts

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

#421
post #58

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

> I do write games and game engine code and tools in C++ without using any of the OOP features. Excuse my C/C++ ignorance, but why not simply use C?

I use string and stream, also most libraries (glew) and compilers (MinGW) that are updated use C++.

To avoid cache misses you can't use OOP, that's probably where this wave of going back to C is coming from:

For example here's how someone that knows how computers work writes Java games: http://www.javaonthebrain.com/java/warp/warp.java

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

#422
post #44

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

> there are simple ways to avoid shooting yourself in the feet with those A cursory look at the CVE list for any C software in the wild indicates that no, there are not simple ways to avoid shooting yourself in the feet with manual memory management in C. It's _incredibly hard_ even for "elite" programmers who have a lot of incentive to avoid these problems. The counterpoint is that people are probably going to spend…

> A cursory look at the CVE list for any C software in the wild

How can I see that list? I'm interested in comparing languages this way.

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

#423
post #395

Earlier quoted context omitted.

Go also has many disadvantages, compared to plain C.

Can't think of any. Do you have an example?

You can't call native libraries without going through cgo. So unless you don't want to have audio, draw text and have access to the graphic APIs, you'll need cgo, which is really slow due to Go's runtime. For game dev, that's a no go (pun intended).

Additionally, the Go compiler isn't trying really hard at optimizing your code, which makes it several times slower on a CPU-bound task. That's for a good reason: because for Go's usecase, compile-time is a priority over performances.

Saying that there is no drawbacks in Go is just irrational fandom…

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

#424
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.

Usually you wouldn't write the type, so `let x = 5;` In general, the C style type declarations complicate parsing quite a lot as well.

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

#425

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…

Care to provide some examples and explain how using more abstractions would have solved them?

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

#426
post #62

Earlier quoted context omitted.

Personally I interpreted the parent as pointing out that C does not offer strict typing.

Strict typing afaik isn't really a formally defined, imo. As you know C is statically typed and generally said to be "weakly typed" as well but you can make a strong argument that just about any language is "strong" or "weak" -ly typed based on a dozen or so characteristics. I think it makes more sense to treat it as a spectrum where some languages are "stronger" than others. Which is different than in the case of "s…

Oh come on, I was taught the difference between strong and weak typing with C (weak) and Pascal (strong) as the examples 30 years ago. You can cast a C entity to something else and NO ONE ELSE KNOWS.

Then THINGS happen.

BAD things.

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

#427

> [C++] is high performance, and it offers but features I don't want, and at a great complexity cost. 1. Complexity of implementation is not complexity of use. Example: Take std::array vs a plain C array. std::array is a few hundreds of lines of code. But - it's about as inutitive to use; has more convenience features; easier for the compiler to optimize; and doesn't let you should yourself in the foot that easily. 2…

From the article: "...I care about the speed of the compiler. I am not a zen master of focus, and waiting 10+ seconds is wasteful, yes, but more importantly it breaks my flow. I flick over to Twitter and suddenly 5+ minutes are gone."

5 minutes? Commendable, it's more like 2 hours in my case.

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

#428
post #135

Earlier quoted context omitted.

C++ is not a superset of C. There is valid C code not compilable with C++ compiler.

The point is to eschew the use of C features not supported by C++ in order to catch bugs. Just read up on the incompatibilities deliberately introduced by the C++ committee and you'll likely agree that these are good things. Implicit conversions to void*? No thank you. Tentative definitions? I don't need that so give me an error.

Yeah for example designated initializers. Such a useless feature... /s

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

#429
post #41
post #31

Earlier quoted context omitted.

Implying that typing does not prevent bugs is the strangest programming meme I’ve ever heard, and its proponents push it so hard that I wonder if there’s somewhere I can sign up to be paid for it. We rarely are able to directly compare the cost/benefit of strict typings vs loose typings, but with JS vs TS you get a pretty direct comparison, and it is absolutely unsurprising that TS is eating the JS world; it does pre…

I'm sure typing prevents some bugs. But if I'm looking at the bugs we find in the JS projects I work on, only a very few would have been avoided with typing. The vast majority of bugs are about unsound business logic, wrongly understood requirements, etc.

If you have a super duper type system you can use it to prevent lots of bugs in business logic, and you can use it to do a lot of work for you - as a solver. There are levels of value in typing - bug finding, but then also communicating what you are up to to other people using / reading the code (including you in < 6 weeks time!)

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

#430
post #378

Earlier quoted context omitted.

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.

> Because even if you don't use it directly, you might use some code that uses it. It seems extremely unlikely that any general purpose code you might adopt, which happens to invoke malloc() at all, would be fit for purpose in such a restricted environment without substantial modification; in which case you would just remove the malloc() calls as well. > And even then, it might not ever be called given the way you ar…

Spoken like someone who never had a 3rd party binary blob as a critical dependency.
Post reply on HN