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

191–200 of 288 posts

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

#191

Post by uecker »

JamesTRexx wrote: post #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…

This is great! This so rare that people remove the complexity again that has accumulated over the years. Most of the programming world is just accumulating entropy and then people give up and start fresh at some point, which is just sad.

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

#192

Post by uecker »

direwolf20 wrote: post #160
guerrilla wrote: post #82

As a hardcore C programmer and zealot myself... How in the hell can you be productive like that? C is a systems programming language, not an application programming language, let alone relevant to the levels of abstraction you'd want in game development. That said, "I am dead" is a very real video game indeed... and his arguments are very sound. I also can't stand C++. I disagree with him on Java though. The core lan…

You have to try it. You can write anything you want in C. Or assembler. It's hardly going to be very productive but... productivity is greater than zero, and the more you try the better you get. Rollercoaster Tycoon was written by hand in assembly, as were all NES and SNES games including ones like Earthbound and A Link to the Past — and SNES assembly isn't nearly as nice as x64.

Ah, the C++ guy who think you need all the features of C++ to be efficient... Many people of people are super productive in C. There is a cost, but this is usually just some initial overhead to identify / write some libraries. In a larger project this initial overhead is irrelevant.

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

#193

Post by [deleted] »

jiggawatts wrote: post #102
cedilla wrote: post #28

Earlier quoted context omitted.

There are a few exceptions though, like most mobile games, visual novels (many of which use Python of all languages, due to an excellent framework called ren'py), and of course games written using Unity or XNA, which use .NET languages. Also, three decades is going a bit too far back, I think. In the mid nineties, C was still king, with assembly still hanging on. C++ was just one of several promising candidates, with…

> Also, three decades is going a bit too far back My memory was wrong: I was thinking of the Quake 1 engine, but I just looked it up and it’s C with some assembly code, no C++. The reason I remember it being C++ was because Visual C++ was the compiler tooling required on Windows.

[deleted]

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

#194

Post by lelanthran »

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…

> Complaining about a language having features you don't want is silly.

If your criteria for a good language is "how many features does it have", then sure, C++ wins. OTOH, if you criteria is "How many footguns does the language have" then C++ loses to almost every other mainstream language, which includes C.

Sometimes the lack of footguns is a plus.

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

#195

Post by ternaryoperator »

9rx wrote: post #74
ternaryoperator wrote: post #44

Earlier quoted context omitted.

The use of "golang" for posts and comments is desirable IMHO because it greatly facilitates search, especially on sites such as HN that cover many languages.

Searching "site:news.ycombinator.com go" on Google didn't yield any results that weren't about the Go programming language even after going several pages deep. What kind of search problems are you having, exactly? And why is it unique to Go? I am sure there are comments on HN about metal oxidization, making sharp changes in direction, Norse gods, and letters of the alphabet.

But if you go to the search box at the bottom of the HN page and type in 'go' the first hit is "Julian Assange has reached a plea deal with the U.S., allowing him to go free," In the top 10 results, only _two_ are about Go, the language.

Whereas the first 50 golang hits are all about the language.

You might have your preferred approach, but there are good reasons for using golang.

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

#198

Post by dualogy »

pyrolistical wrote: post #39

I always liked C. I enjoyed how brutal it is, except the preprocessor. This is why zig is a godsend. It is actually simpler than C while being more precise than C! For example zig can distinguish between a pointer to a single element vs a pointer to an array of unknown length. Where as in c abi, it is all T* When importing a c lib, you can make it more ergonomic to use than c itself. Being able to easily import c lib…

> as practically all so called c++ libs also export a c header as they know how important it is

In the gamedev space, I'd say too few of them do.

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

#199

Post by pjmlp »

tialaramex wrote: post #167
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…

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

Except that C++ provides the tools to do just like C, Rust, or whatever one feels like doing for dispatching, even if it requires a few pages of template metaprogramming mixed with compile time executions, or writing exactly the same C code on the common subset across both languages.

Now with reflection even more tools will be available.

Which is why despite all its warts and security flaws, many inherited from C source code compatibility, many domains will keep using it, because they will complain about their missing 1% that no one else uses.

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

#200

Post by pjmlp »

agentultra wrote: post #175
tialaramex wrote: post #167

Earlier quoted context omitted.

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

Only if devs lack the skills to understand what to actually use.

There is this anti-C++ bias that keeps forgetting that using C++ doesn't mean use every feature.

Just like many keep using C as if C89 was latest, and never adopt anything added in the last 30 years.

Post reply on HN