Live data from Hacker News

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

jonathanwhiting.com

111–120 of 288 posts

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

#111
I'm pulling apart and rewriting so far a little in C a personal fork of OpenTTD 12.2. I began on it a few years ago for the first time for the heck of it after patching for realtime, began again while adding features I wanted until I hit a bad enough snag, and now began again by first extracting most used functions and profiling with Valgrind inbetween.

Things I noticed are inconsistent coding styles, overly complex processes, unused(!) functions, inefficient data use, nothing surprising with a project worked on by various people in their spare time and their own ideas on how to code. And this isn't even talking about later versions. To me it's an example of how unrestricted access to bling features causes a mess.

Eventually I want it converted to C (C23), split apart in seperate functions with a decent source code organisation, and simplified processes to make it easier to understand what's going on and extend fuctionality. For this I need it simplified as possible and weed out the layer of complexity caused by C++ first. Going to take plenty of time, but I'm still having fun doing it (most of the time anyway :-p ).

I'm not advocating anything, but it's satifying to me to bring clarity to code and see small improvements to performance during the process at the same time. It also gave me an opportunity to develop a unique syntax style that visualises parts of the code better for me.

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

#112
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 remember the creator of Kaiju engine stating something about C++ compilers producing slower code with C-style C++.

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

#113
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’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.

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

#114

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

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 benefit at all and it could potentially bring you issues later on for things such as interfacing with other languages.

I personally do not see the point of using C++ if you do not use any of its features.

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

#115

Earlier quoted context omitted.

Were not most games back in the day in C?

Back in what day? Quake II I would say is the best good looking thing written in pure C. id Tech 3 is partly C++. Everything after that era was pretty much C++. Even GoldSrc is partly C++. Source was pure C++.

I guess back in my day, early to mid 90s. My understanding is C became more common.

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

#116

>Death of flash >The library support for games[in Go] is quite poor, and though you can wrap C libs without much trouble, doing so adds a lot of busy work. I can't see when this was written, but it has to be around 2015. So, about 10 years ago. I wonder what his opinion is today.

The first capture of the page on Internet Archive Wayback Machine is from January 9th, 2016. So it’s at least that old. Also here is a snapshot of the main page of his website from that time, which has screenshots of his games and thereby provides context into what kind of games he had made and published when the blog post was written. https://web.archive.org/web/20160110012902/http://jonathanwh... This one looks lik…

I think it would be aprópiate if @dang added a (2016) to the title

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

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

Your website seems to be blocking Tor

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

#118
post #110

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?

It's a class, so it doesn't work in C.

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

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

It's possible to use only a subset of the language. You could write a Java program without classes if you really wanted to. Just put the whole thing in main(). A lot of smart people pick and choose what they want from the language, just like religion, they keep the good parts and discard the bad.

main is also in a class in Java.

Even with the recent extension where it looks like it isn't, the compiler adds one for you.

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

#120
post #41

Earlier 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.

When I developed D, a major priority was string handling. I was inspired by Basic, which had very straightforward, natural strings. The goal was to be as good as Basic strings.

And it wasn't hard to achieve. The idea was to use length delimited strings rather than 0 terminated. This meant that slices of strings being strings is a superpower. No more did one have to constantly allocate memory for a slice, and then keep track of that memory.

Length-delimited also super speeded string manipulation. One no longer had to scan a string to find its length. This is a big deal for memory caching.

Static strings are length delimited too, but also have a 0 at the end, which makes it easy to pass string literals to C functions like printf. And, of course, you can append a 0 to a string anytime.

Post reply on HN