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

Why I Write Games in C (yes, C)

jonathanwhiting.com

Post reply on HN
Print view View original

111–120 of 556 posts

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

#111

Post by eropple »

stephc_int13 wrote: post #63
cwyers wrote: post #44

Earlier quoted context omitted.

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

Yeah, I am not talking about vulnerabilities. I am simply talking about ease of use and avoidance of leaks and crashes. Writing super secure code is usually not a requirement for gamedev, and I completely agree, this is hard and potentially harder in C than, say, in Rust.

It's a requirement if you do network I/O whether you realize it or not.

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

#112

Post by yvdriess »

oldmanhorton wrote: post #69
pier25 wrote: post #58

Earlier quoted context omitted.

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

Because c++ without OOP still gives you RAII (which is neutered a bit if you don't write your own classes but still), safe pointers, references, lambda, and an immense standard library, to name a few.

That but without using any of the standard libraries. Even RAII can get in the way.

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

#113

Post by pm90 »

majewsky wrote: post #107
xyproto wrote: post #103

Earlier quoted context omitted.

Interestingly, it's fully possible to disable the automatic garbage collection in Go to achieve this. Disable the garbage collector: debug.SetGCPercent(-1) Trigger garbage collection: runtime.GC() It is also possible to allocate a large block of memory and then manage it yourself.

> It is also possible to allocate a large block of memory and then manage it yourself. At which point you're mostly just writing C in Go.

Actually you're not.

I would very much prefer a stripped down version of Go used for these situations rather than throwing more C at it. The main benefits of using Go are not the garbage collection, its the tooling, the readability (and thus maintainability) of the code base, the large number of folks who are versatile in using it.

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

#114

Post by makecheck »

I’m not sure why but programmers like to reject entire languages instead of just rejecting the features they don’t like. A lot of stuff in C++ is entirely avoidable.

Protocol-oriented programming is extremely useful for games and I like Objective-C for that reason. (Objective-C doesn’t meet his mentioned goal of portability but this is an example where C++ could be used to gain “light” inheritance without having to opt in to the rest of the mess that C++ can be.)

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

#115

Post by CriticalCathed »

wwright wrote: post #62
jchw wrote: 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…

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 "static typing" which you either have or don't.

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

#117

Post by oconnor663 »

TurboHaskal wrote: post #94
sha666sum wrote: post #75

Earlier quoted context omitted.

My experience with Rust is that I have to fight the compiler a lot, but when the program compiles, it works . If it doesn't work, it means there's an error with my file/network paths or I did something in the wrong order, errors which no language can save me from. Rust also becomes a lot less verbose when you get better at it. The ? operator is especially useful.

> but when the program compiles, it works That's not even true for languages with dependent types, which Rust lacks.

And at the same time, I've heard people say "when it compiles, it works" about much weaker type systems, like Go's. It just seems to mean "this language catches more errors at compile time than the previous language I used."

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

#118

Post by leetcrew »

benhoyt wrote: post #59
zemo wrote: post #46

> 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 love this opinion from games programmers because they never qualify it and talk about what their latency budgets are and what they do in lieu of a garbage collector. They just hand wave and say "GC can't work". The reality is you still have to free resources, so it's not like the garbage c…

In particular I know that Go's GC is optimized for very low latency (rather than throughput), and is not a stop the world GC. So I'm wondering why it doesn't work for games? Are the pauses still too high for games, or is he missing something? Benchmarks or concrete results in Go would be great here. Edit: specifics from https://blog.golang.org/ismmkeynote - Go hugely improved GC latency from 300ms before version 1.5,…

maybe this is an ignorant question, but why do people always cite GC latencies in seconds? is there an implied reference machine where the latency is 300ms? I would expect it to vary a lot in the wild based on cpu frequency and cache/memory latency. is there some reason why this doesn't matter as much as I think it does?

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

#119

Post by sramsay »

z3phyr wrote: post #77
pier25 wrote: post #58

Earlier quoted context omitted.

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

If C gets operator overloading and RAII, there will be no good reason to use C++ for me!!

Is RAII in C a serious suggestion being made anywhere?

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

#120

Post by stephc_int13 »

zemo wrote: post #98
stephc_int13 wrote: post #74

Earlier quoted context omitted.

I know this subject quite well and I will later publish a detailed article. The real run-time cost of memory management done well in a modern game engine written without OOP features is extremely low. We usually use a few very simple specialized memory allocators, you'd probably be surprised by how simple memory management can be. The trick is to not use the same allocator when the lifetime is different. Some resourc…

as an example point, the Go garbage collector clears heaps of 18gb in sub-millisecond latencies. If I'm understanding the problem at hand (maybe I'm not!), given an engine running at a target framerate of 144 frames per second, you're working with a latency budget of about 7ms per frame. Do you always use all 7ms, or do you sometimes sleep or spin until the next frame to await user input? We can also look at it from…

There is no general answer to this question. Frame latency, timing and synchronization is a difficult subject.

Some games are double or triple buffered.

Rendering is not always running at the same frequency as the game update.

The game update is sometimes fixed, but not always.

I've had very awful experience with GC in the past, on Android, the game code was full C/C++ with a bit of Java to talk to the system APIs, I had to use the camera stream. At the time (2010) Android was still a hot mess full of badly over engineered code.

The Camera API was simply triggering a garbage collect about every 3-4 frames, it locked the camera stream for 100ms (not nanoseconds, milliseconds!) The Android port of this game was cancelled because of that, it was simply impossible to disable the "feature".

Post reply on HN