[deleted]
I write games in C (yes, C) (2016)
171–180 of 288 posts
Re: I write games in C (yes, C) (2016)
#172I read this article years ago and haven't been able to find it since. It's a pleasant surprise to come across it here.
Re: I write games in C (yes, C) (2016)
#173> I like Go a lot. In many ways it is C revisited, taking into account what has be learnt in the long years since it was released. I would like to use it, but there are big roadblocks that prevent me. 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'm no Go fan, to be clear, but GC isn't the problem with Go. It has a pretty decent GC with…
The performance gains from bit-level control over memory come from managing the layout to ensure cache locality and do things like SIMD - and nowadays even GPU kernel offload. Enormous performance gains.
I agree that it really isn't about garbage collection pauses, but I haven't heard people focusing on "eliminating gc pause" when they talk about low level languages, but they spend a lot of time talking about SIMD, GPU kernels, and cache misses. If Go could add these features, it would be a performance monster.
Re: I write games in C (yes, C) (2016)
#174Plenty of people cycle on a fixie too. So what? C, especially modern C, does provide metaprogramming and abstraction facilities. In practice, you can even get things like the "defer" construct from other languages: https://lwn.net/Articles/934679/ The question isn't "Can I write a game in C?". Yes, of course you can, and it's not even that painful. The question is "Why would you?", and then "Why would you brag about…
> I don't read these sorts of article as technical position papers.
I do.
> People say, out loud, "I use C and not C++" to say something about themselves.
Just like you are telling us something about yourself right now.
> ISTM that certain circles there's this perception that C is somehow more hardcore.
That's not why we use it.
There are certainly many noobs who think C is hardcore. That just goes to show how low the bar has fallen since the masses rushed into computing.
Many of these people also think of changing their own oil or a flat tire as being a superpower. Some could not identify the business end of a screwdriver if their life depended on it. Their opinion on the relatively difficulty or impressiveness of anything is to be taken with a huge grain of salt.
There are many good reasons to use C. If nothing else it demonstrates that the user is a free thinker and not a fucking muppet. It's the sort of thing that attracts me and drives you away. That's valuable.
> Nobody's impressed by using it over a modern language.
1) The word "modern" is not a magic talisman that makes anything it's attached to automatically worthy.
2) "Nobody" does not mean what you apparently think it means. Free clue: others exist in the world beside yourself and your self-absorbed clique.
3) Nobody with a brain is impressed by whatever the midwits are doing. Anyone who can fog a mirror can follow the herd off the nearest cliff. It's the outliers who are impressive.
4) Technically anything since the 1500s is "modern." It's such a vague, useless word that serves no purpose other than "virtue" signalling.
C++ is fucking garbage. Always has been. Keeps getting worse and worse every year. Enjoy your PAGES full of indecipherable gibberish ("error diagnostics"), your miserably slow compile times, and your closet full of footguns and decades old sticks of sweating dynamite. Slowest language by far, other than the so very modern abomination that is Rust. You can keep it.
Re: I write games in C (yes, C) (2016)
#175I 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…
> then end up reimplementing virtual interfaces manually C++ dynamic dispatch (your "virtual interfaces") is achieved by welding a vtable onto every type and providing a pointer to that vtable for instances of the type. If in 90% of your code you deal with specific types like Goose or Swan or Duck or Seagull, and only 10% needs to work with the broad Bird category well, too bad, every Goose, Swan, Duck and Seagull ca…
C++ nudges you to think in terms of single elements. Operator overloading, ctors/dtors, references, etc. you pay that cost all over the place.
C programs tend to nudge you into thinking in terms of arrays of data.
For game development you generally want to think this way. The cost of vtables and all the cache misses doesn’t have to be paid. A game has to stream bytes. Many things at once. Rarely single elements at a time.
Re: I write games in C (yes, C) (2016)
#176In my core I'm the same. C is my language and served me well for decades. There's nothing inherently major wrong with it until you reach one of the two (or both). Working in a group of people on a C codebase tends to introduce pain on multiple levels unlike some other languages (yes, including C++). The other is that anything takes a long-ass time to do compared to modern alternatives, which might also be an issue if…
Why do you think working with a group of people on a C codebase introduces pain unlike other languages? Working with a group of people always causes pain, but I found the pain much less severe for C than for C++.
It depends on what you're building with the language too.
For eg. In very embedded contexts where we were not using any big data structures like struct of strings, not doing any memory allocations etc... C might be easier to reason about than C++. (No hidden code paths). Just allocate something on the stack, pass the pointer to a function to do the computation, done.
In any desktop apis (gui, web servers etc..), where you deal with collections of objects, need to spin up thread pools and rely on results from the future etc... The standard library data structures (vectors, maps etc...) alone makes C++ code a lot more easy to read and review than C. When raw pointers are forbidden, Ownership of memory becomes very clear. Granted my opinion of desktop development comes mostly from very few libraries (Qt vs. Gtk, gstreamer's C API vs. C++ wrapper, http libraries etc...), but there are some problem domains for which C is just insufficient.
Re: I write games in C (yes, C) (2016)
#177I 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…
Yeah, you could argue that choosing C is just choosing a particular subset of C++. The main difference from choosing a different subset, e.g. “Google C++” (i.e. writing C++ according to the Google style guide), is that the compiler enforces that you stick to the subset.
Linters etc... Validates the subset you're choosing to use for your project too.
Re: I write games in C (yes, C) (2016)
#178Earlier quoted context omitted.
If he doesn't use C++ features then there's no point of bothering with C++ at all. C++ is kinda but not really a superset of C. There are some nice features that are lacking in C++. The fixie example wants to make the comparison that using C instead of C++ is deliverately done just to brag about doing something in a way that is more difficult than in should be. In reality the issue is that C++ might not offer you any…
Usually you start with just one feature, like std::map instead of OpenSSL's abomination of a hashmap library or rolling your own. Of course you should use std::unordered_map instead of std::map because the latter is actually a treemap, but you probably don't know that when you first learn it...
Nah, I prefer to just use C, because at least I can parse the quite sane and helpful error diagnostics when I omit a semicolon or something, instead of getting 15 pages of unreadable garbage dumped into my lap by the oh-so-wonderful C++ standard library.
(Which quite frankly isn't much of a "standard" when there's about a dozen different real world interpretations of the code depending on which flavor of which compiler from which year that you're using.)
I also don't have to wait eons for my code to compile. Really, the mental and computational load of C has got to be 1/10 of C++.
What a nightmare C++ is, and it just keeps getting worse every year thanks to the incompetent standards committee.
Re: I write games in C (yes, C) (2016)
#179Earlier quoted context omitted.
Yeah, you could argue that choosing C is just choosing a particular subset of C++. The main difference from choosing a different subset, e.g. “Google C++” (i.e. writing C++ according to the Google style guide), is that the compiler enforces that you stick to the subset.
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.
And constructors and destructors to be able to use those vectors and hash maps properly without worrying about memory leaks.
And const references.
And lambdas.
Re: I write games in C (yes, C) (2016)
#180Noble quest, but without operator overloading when dealing with Matrix*Vector you end up with an unreadable mess for physics, skeletal animation etc. There is a reason professional game dev is still 90% C++. (Funny enough, amateur gamedev is C# these days, students use what they learn at uni).