Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I write games in C (yes, C) (2016)

jonathanwhiting.com

Post reply on HN
Print view View original

121–130 of 288 posts

Re: I write games in C (yes, C) (2016)

#121

Post by direwolf20 »

win311fwg wrote: post #93
Melonai wrote: post #87

Earlier quoted context omitted.

At least with regards your second point, Google, DuckDuckGo, all other search engines. I always have to add "golang" because otherwise it just fucks up. I have to say that googling for "C", is a lot more dire, and because the LLVM people called their frontend "clang" I can't even use that, otherwise only clang stuff pops up. And even then, once I did manage to convince the search engine that I'm looking for the progr…

> because the LLVM people called their frontend "clang" I can't even use that Said frontend is for the C programming language. Isn't that perfectly appropriate? I did a web search for "golang" and the first result was a download page for a Go compiler, so there is precedent.

What's the first result for "clang"? How about in private browsing?

Re: I write games in C (yes, C) (2016)

#123

Post by rustyhancock »

levodelellis wrote: post #73
torlok wrote: post #20

I write mostly like I would in C, but use C++ features as needed. It ends up looking similar to Rust if you squint. All these "I write games in C" people complain about C++ features, and then end up reimplementing virtual interfaces manually with struct headers or massive switch statements, just to feel better about themselves. Writing games in C is not harder, you just have to implement modern language features by h…

I measured once and to my surprise templates aren't (directly) the reason for long compile times. It's function bodies in headers, and obviously templates are in headers and they call other templated functions/classes which explodes code generation and time. But if it's only a few lines and doesn't call other templated functions it's likely fine. I wrote about it here https://bolinlang.com/wheres-my-compile-time Afte…

Another option can be if you have a core set of headers your project will use (and is stable) just precompiling them.

Re: I write games in C (yes, C) (2016)

#124

Post by teo_zero »

uecker wrote: post #110
teo_zero wrote: post #95

Earlier quoted context omitted.

I agree on the former two (std::string and smart pointers) because they can't be nicely implemented without some help from the language itself. The latter two (hash maps and vectors), though, are just compound data types that can be built on top of standard C. All it would need is to agree on a new common library, more modern than the one designed in the 70s.

why not std::string?

You can surely create a std::string-like type in C, call it "newstring", and write functions that accept and return newstrings, and re-implement the whole standard library to work with newstrings, from printf() onwards. But you'll never have the comfort of newstring literals. The nice syntax with quotes is tied to zero-terminated strings. Of course you can litter your code with preprocessor macros, but it's inelegant and brittle.

Re: I write games in C (yes, C) (2016)

#125

Post by 9rx »

direwolf20 wrote: post #57
p0w3n3d wrote: post #40

C has very low entry level, providing that you have some knowledge about memory management. When, as a Java developer, I had to quickly deliver some exchange connector using given .h and .so, I chose C, because C++ had too high entry level. If C is a sharp knife, C++ is a rotating pell post full of sharp knives. You can cut yourself even if you think you're safe. But I find string management in C awful and would like…

That's the neat thing about C++. You don't have to use any of it that you don't want to.

[flagged]

Re: I write games in C (yes, C) (2016)

#126

Post by uecker »

jsheard wrote: post #101
levodelellis wrote: post #98

Earlier quoted context omitted.

[flagged]

I agree it shouldn't really matter if there's no C++ features in play, but I suppose third party headers could bite you if they use #ifdef __cplusplus to guard optional C++ extensions on top of their basic C interface. In that case the compiler could be dealing with dramatically more complex code when you build in C++ mode.

Maybe it is similar for the same compiler (but one should check, I suspect C could still be faster), but then there are much more C compilers. For example, TCC is a lot faster than GCC.

Re: I write games in C (yes, C) (2016)

#127

Post by ninkendo »

teo_zero wrote: post #95
ninkendo wrote: post #55

Earlier quoted context omitted.

C's string handling is so abominably terrible that sometimes all people really need is "C with std::string". Oh, and smart pointers too. And hash maps. Vectors too while we're at it. I think that's it.

I agree on the former two (std::string and smart pointers) because they can't be nicely implemented without some help from the language itself. The latter two (hash maps and vectors), though, are just compound data types that can be built on top of standard C. All it would need is to agree on a new common library, more modern than the one designed in the 70s.

I think a vec is important for the same reason a string is… because being able to properly get the length, and standardized ways to push/pop from them that don’t require manual bounds checking and calls to realloc.

Hash maps are mostly only important because everyone ought to standardize on a way of hashing keys.

But I suppose they can both be “bring your own”… to me it’s more that these types are so fundamental and so “table stakes” that having one base implementation of them guaranteed by the language’s standard lib is important.

Re: I write games in C (yes, C) (2016)

#128

Post by trueno »

akoluthic wrote: post #23

It's not unheard of, but you have to be a little crazy to do this in 2026. I developed Chrysalis entirely in C (with GLFW3 and FMOD for audio): https://store.steampowered.com/app/1594210/Chrysalis/

I've been working religiously for like 2 years on the jedi academy codebase which is c & c++. It's Ravensofts variant of the idtech3 engine and it's insane how fragile the games combat is to precision and timing changes, I can't get away with adding much without destroying the lightsaber combat qualities. There are certain spots where I can't even add an incrementing i++ counter lmao it presents just enough of a slowdown or shifts something around that I haven't been able to track down that bleeds into the rest of the gameplay, but I am also sticking with the ancient compilers from 22 years ago so as to preserve the fpu characteristics of the game. There are some modern attempts at using this codebase with modern tooling but they've kind of bastardized/refactored all of it and it just feels different/unbalanced wrong. idtech3 is such an incredibly foray into c it's really something else and carmack and team really sent it back in the day.

Re: I write games in C (yes, C) (2016)

#129

Post by wasmperson »

uecker wrote: post #113
randomtoast wrote: post #47

Earlier quoted context omitted.

I’ve seen this play out a lot. People say they “write games in C” and then quietly rebuild half of C++ anyway with vtables in structs or giant switch statements, just without the compiler helping. That’s fine if it makes you happier, but it’s not obviously simpler or safer. Also, C++ compile times are mostly a self-inflicted wound via templates and metaprogramming, not some inherent tax you pay for having virtual fun…

I think it is simpler and "the compiler not helping" == "things are more transparent". int a = 3; foo(a); // What value has a ? There are various things one does not have to worry about when using C instead of C++. But the brain needs some time to get used to it.

I think I get what you're trying to say, but you may have picked a bad example, here:

  #define foo(a) a = 12

Re: I write games in C (yes, C) (2016)

#130

Post by teunispeters »

I like C. You can take away all memory management (yes, including some of the unsafe glibc calls that have hidden memory management) and everything can be so smooth and clean. Since rules like MISRA require up-front allocation - if any is in use - this can be tightly controlled.

Very useful if you don't want (or need) surprises anywhere. Or if you want all the surprises (exceptions, errors, etc) all better tied to the hardware that provides such.

It's also fairly easy to write unit tests for everything.

Post reply on HN