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

441–450 of 556 posts

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

#441

Post by ncmncm »

BearOso wrote: post #152
benhoyt wrote: post #59

Earlier quoted context omitted.

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

People don’t write games in GC languages, so GC language developers don’t optimize for games, so people don’t write games in GC languages. It’s just a vicious cycle. It never breaks because for big projects there is too much financial risk.

Also, because everybody who tries optimizing a GC language for games fails, badly. And, GC language developers know that if they promote their language for games, any game developers (temporarily) taken in will hate them forever, and bad-mouth their language.

Languages not used for anything anyone cares much about don't attract much bad press. There are reasons why games are written the way they are. It is not masochism.

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

#442

Post by jorams »

lonelappde wrote: post #430
loeg wrote: post #378

Earlier quoted context omitted.

> Because even if you don't use it directly, you might use some code that uses it. It seems extremely unlikely that any general purpose code you might adopt, which happens to invoke malloc() at all, would be fit for purpose in such a restricted environment without substantial modification; in which case you would just remove the malloc() calls as well. > And even then, it might not ever be called given the way you ar…

Spoken like someone who never had a 3rd party binary blob as a critical dependency.

If you need your system to never dynamically allocate memory, an opaque 3rd party binary blob which might still do that doesn't seem like a valid inclusion.

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

#443

Post by ncmncm »

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

The last time I encountered GC issues in gamedev, we were seeing 100ms GC pauses (that's 6 dropped frames at 60fps!) every 30 seconds or so. We had poor insight into why, and what we could glean of "why" was that it was a widespread problem with how our designers were prototyping stuff in JS (more specifically, they were writing it as regular JS, instead of jumping through hoops to try and relieve GC pressure through…

> The problem isn't GC per se.

In other words, the problem is GC, full stop.

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

#444

Post by ncmncm »

einpoklum wrote: post #161
flatline wrote: post #76

Earlier quoted context omitted.

I’m not a game programmer but with RAII for example (I realize this is not a C idiom), it really becomes a non-issue if you have things scoped properly. For everything that doesn’t fit into this box you probably wouldn’t be relying on a GC anyway, the GC may do the final memory reap but scope control is still often manual in memory-managed languages.

That's not entirely true. If you only rely on RAII you may end up with millions of shared pointers, each of which needs to be managed independently and having its own overhead. They may also be independently allocated, which means they will be fragmented in memory. Not so simple.

Indeed, if you have a noticeable number of shared pointers, you are Doing It Wrong. A few here and there at top level are harmless, but if they have leaked into public interfaces or low-level infrastructure, you might better pitch the whole codebase and start over.

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

#445

Post by jokoon »

I still believe that C++ is great because you can "use the good parts".

To me the STL containers are good enough. It's always a balance between how much time you save, and how much performance you lose. C++ is good enough with this. The only lacking thing would be an object pool.

The author writes

> but so simple it's not too hard to learn to use it carefully.

I would really love a replacement to C++, or an subset of C, that have the best of both languages. I can't use C because it becomes hairy very quickly, since you don't have things like STL containers.

I don't like Rust for the exact reason I quoted the author. The learning curve of Rust is too step, and its syntax if to distant from C. C is great because it's easy and fast, but it's also lacking many modern features that makes the programmer's life easier, without stomping down on performance or customization.

It's true that C++ is very complex, but I still believes it's very very usable, and the standard is improving a lot.

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

#446

Post by ncmncm »

eropple wrote: post #320
stephc_int13 wrote: post #298

Earlier quoted context omitted.

In gamedev, we often use UDP for network I/O. I am far from an expert in security but I've done a bit of reversing/hacking when I was 16 years old (DOS era) I think this is hard to check for everything, but in my opinion, good security can be achieved with extreme simplicity. Packets are fixed-size, every fields are manually bound checked and the packet is rejected if anything looks wrong.

That jibes with my knowledge. But I've seen some real weird stuff before. ;) Folks using variable-length fields and happily just dumping the contents into eval(), all sorts of awful.

Bad code is bad code, in any language.

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

#447

Post by Elrac »

I'd like to voice my disagreement with the author about C having the shortest compile times. From my own experience and reports all over the Web, it seems that Go handily beats C at compilation speed.

This is mostly down to a lot of design decisions in Go made with the goal of speeding up compilation. Elimination of header files, pre-compilation of Go modules, efficiently parseable syntax and more.

From what I've seen, first-time compilation of Go programs competes well with C, while incremental compiles are practically instantaneous.

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

#448

Post by hackits »

mike00632 wrote: post #418
hackits wrote: post #307

Earlier quoted context omitted.

Sounds very similar to NASA C programming guidelines. Each module during the initialization period would allocate its static memory size. Every loop had a upper bound's max iteration to prevent infinite loops. I think they posted the guidelines and it was a wonderful read about how they developed real time systems.

Do you happen to have a link to the guidelines?

http://spinroot.com/gerard/pdf/P10.pdf

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

#449

Post by ncmncm »

slacka wrote: post #33
stephc_int13 wrote: post #21

The author's opinion is uncommon but not unique. A few examples: https://handmadehero.org/ https://ourmachinery.com/post/physical-design/ Simple libs widely used in game dev circles: https://github.com/nothings/stb This one is a full game engine with tools made for educational purpose: https://www.raylib.com/ I do write games and game engine code and tools in C++ without using any of the OOP features. I know quite a…

Writing game engines in C++ without using any OOP features, makes perfect sense to me. Other than the author likes C, he failed to show me why his approach is better than yours. I found it very light on details.

Writing game engines in C++ without using destructors is just foolish.

If by OOP you mean virtual functions? Nobody uses that stuff much anymore, except Java refugees. (They use shared pointers, too.) But, anyplace you would use a function pointer in C, it's cleaner with a virtual function, and often faster.

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

#450

Post by ncmncm »

klipt wrote: post #183
Thiez wrote: post #104

Earlier quoted context omitted.

OOP is such a nebulous thing. Just because the word 'class' is used doesn't mean something is OOP. Those smart pointers don't use inheritance, they don't implement any interfaces, no virtual methods...

I would call that using a subset of OOP features[1], not avoiding it entirely. But I guess there's no point in arguing over semantics. [1] As Wikipedia defines OOP: "a programming paradigm based on the concept of "objects", which can contain data, in the form of fields (often known as attributes or properties), and code, in the form of procedures (often known as methods)." https://en.wikipedia.org/wiki/Object-oriente…

It's not classic OOP without inheritance and virtual functions.

But nobody seriously uses virtual functions anymore, except where they would need to use function pointers, and for precisely those uses virtual functions are way better: cleaner, safer, often faster.

Post reply on HN