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

101–110 of 556 posts

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

#101

Post by forrestthewoods »

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…

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

Bro, game devs talk about this non-stop. There are probably 1000 GDC talks about memory management.

Game devs don't spell the fine details because they are generally talking to other game devs and there is assumed knowledge. Everyone in games knows about memory management and frame budgets.

> If you have a garbage collector that runs in 200us, you could run a GC on every single frame and use less than 3% of your frame budget on the GC pause.

And if pigs could fly the world would be different. ;)

Go has a super fast GC now. It had a trash GC (teehee) for many many years. But Go is not used for game dev client front-ends. If C# / Unity had an ultra fast GC that used only 3% of a frame budget that would be interesting. But Unity has a trash GC that can easily take 10+ milliseconds. (Their incremental GC is still experimental.) It's a problem that literally every Unity dev has to spend considerable resources to manage.

For 50+ years GC has been a poor choice for game dev. Maybe at some point that will change! The status quo is that GC sucks for games. The onus is on GC to prove that it doesn't suck.

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

#103

Post by xyproto »

Rusky wrote: post #89
pdpi wrote: post #86

Earlier quoted context omitted.

> and the times you find yourself "at the mercy" of the garbage collector is pretty damn frustrating. You're still at the mercy of the malloc implementation. I've seen some fairly nasty behaviour involving memory leaks and weird pauses on free coming from a really hostile allocation pattern causing fragmentation in jemalloc's internal data.

That's true, and it's why the alternative to GC is generally not "malloc and free" or "RAII" but "custom allocators." Games are very friendly to that approach- with a bit of thought you can use arenas and object pools to cover 99% of what you need, and cut out all of the failure modes of a general purpose GC or malloc implementation.

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.

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

#104

Post by Thiez »

klipt wrote: post #83
oldmanhorton wrote: post #69

Earlier quoted context omitted.

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.

If by safe pointers you mean unique_ptr etc, I'm pretty sure those are classes: https://en.cppreference.com/w/cpp/memory/unique_ptr So by definition require OOP?

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

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

#105

Post by 0x0aff374668 »

Makes some really great points, similar to why C++ is not favored for embedded. C++ compilers are just too unpredictable and when trying to meet code limits in 128K, 32K or even 2K of flash, C++ is a nightmare. All of the major embedded SDKs (STM, Microchip, SiLabs, TI, NXP, I could go on) are written in C... and C only. MBED is C++, but I've never encountered or heard of an OEM or integrator using MBED in a real product.

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

#106

Post by balaam »

Hokusai wrote: post #57

Some points: > All my solo project games I've been making recently have been written in 'vanilla' C. The author is talking about solo projects, not big projects where dozens of teams may be collaborating. It is good that he makes the point at the beginning. > Nobody does this. This is just not true. There are solo projects developed in Python, Go, even Commodore 64 assembly. When you do something for fun, you can hav…

> You need very good practices to make C++ compile fast.

I would reframe this as the design of C++ makes it hard to write code that compiles fast.

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

#107

Post by majewsky »

xyproto wrote: post #103
Rusky wrote: post #89

Earlier quoted context omitted.

That's true, and it's why the alternative to GC is generally not "malloc and free" or "RAII" but "custom allocators." Games are very friendly to that approach- with a bit of thought you can use arenas and object pools to cover 99% of what you need, and cut out all of the failure modes of a general purpose GC or malloc implementation.

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.

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

#108

Post by billfruit »

They didn't dwell on why they chose C over C++, in much detail. In my view the conveniences and quality of life features provided by c++ makes it a better choice than C for large programs.

Also there are many kind of games that do not require a real time user interaction including many turn based games, card games, etc, so the type of game could be a factor in the selection of the tool. Some time s I guess game design can incorporate pauses and delays that might be required for technical reasons.

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

#109

Post by prewett »

xamuel wrote: post #67
eternalny1 wrote: post #34

Earlier quoted context omitted.

> the game itself has objects (as in, things the player can pick up and put in their inventory), the game itself has classes (as in RPG classes). It might even have factories, depending on the game. This makes no sense to me. By that logic, it would be difficult for me to create a scheduling system for classes being taught in factories with OOP, which it's not.

For a program about classroom-scheduling, it would be nice if you could use "class" as a structure name. Then you could declare a function as taking a "class" as an argument. But if "class" is a reserved keyword in the language, you have to come up with some other name like "_class" or "ClassStruct". I didn't mean to say it's an earth-shattering obstacle. Just one minor additional nitpick to add to the gigantic pile…

The use of "clazz" by Java programmers always seemed like a good solution to me.

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

#110

Post by zerr »

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…

Just a quick note, in such contexts, what is meant actually is a non-deterministic GC.
Post reply on HN