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

511–520 of 556 posts

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

#511

Post by xyproto »

weberc2 wrote: post #332
bufo wrote: post #234

Earlier quoted context omitted.

Go’s compiler is not at all optimized for generating fast floating point instructions like AVX and its very cumbersome to add any kind of intrinsics. This might not matter for light games but an issue when you want to simply switch to wide floating point operations to optimize some math.

Yeah, C compilers optimize much more than Go compilers. Performance is C’s most noteworthy advantage over Go.

GCC can compile both C and Go. I searched for benchmarks but found none for GCC 9 that compares the performance of C and Go. Do you have any sources on this?

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

#512

Post by takeda »

freyr wrote: post #385
takeda wrote: post #342

Earlier quoted context omitted.

Go was pushed as a C replacement, but very few C programmers switched to it, it seems like it took hearts of some of Python, Ruby, Java etc programmers.

Nonetheless, Go has many advantages over C that are not related to GC.

So does Python or Ruby, that doesn't mean it is a C replacement.

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

#513

Post by doomlaser »

jayd16 wrote: post #325
doomlaser wrote: post #196

Earlier quoted context omitted.

Unity uses/used the standard boehm garbage collector [1] for over a decade, and it has been notorious for causing GC lag in games produced from that engine, noticeable in occasional sudden spikes of dropped framerate while the GC does a sweep at a layer of abstraction higher than Unity game developers can control directly. People went to extreme measures to avoid allocating memory in their games: manually pooling eve…

That Unity was using that ancient collector was the main complaint. Switching to an incremental GC is long overdue. As for pooling objects, you'd go to those "extreme measures" as a matter of course in any other language as well. You wouldn't want to alloc and free every frame no matter the language.

Yes. the boehm collector is the root of the problem for Unity's runtime. It's just the verbatim code from that repository in fact. But in other languages, such as C with standard libraries, you can still do common things like comparing stings and calling printf() without inadvertently triggering a dreaded GC sweep. Not so in Unity's C#.

And allocating memory is fine during runtime when you are in control of the allocation and the cleanup, whereas in Unity, the sweeps are fully out of your control, expensive, and will just sometimes happen in the middle of the action

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

#514

Post by RobertKerans »

meheleventyone wrote: post #476
RobertKerans wrote: post #282

Earlier quoted context omitted.

You wouldn't have this still up somewhere like GH would you? I'm currently writing a toy ECS implementation and have somewhat similar needs, and I've been trying to build up a reference library of sorts covering novel ways of dealing with these kind of JS issues

Three.js implements their math this way. https://github.com/mrdoob/three.js/blob/master/src/math/Vect... You can see most operations act on the Vector and there are some shared temporary variables that have been preallocated. If you look through some of the other parts you can see closures used to capture pre-allocated temporaries per function as well.

Ah brilliant, that's definitely useful. Thank you for the pointer

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

#515

Post by RobertKerans »

tomxor wrote: post #310
RobertKerans wrote: post #282

Earlier quoted context omitted.

You wouldn't have this still up somewhere like GH would you? I'm currently writing a toy ECS implementation and have somewhat similar needs, and I've been trying to build up a reference library of sorts covering novel ways of dealing with these kind of JS issues

No sorry, this is from more than 5 years ago and it was never FOSS, but I only implemented rudimentary operators anyway, you could easily adapt existing libraries or write your own, the above concept is more valuable than any specific implementation details... the core concept being, never implicitly generate objects, e.g operate directly on parameter objects, or re-use them for return value, or return persistent int…

Thank you though, what you've written here is very useful -- you're describing things I'm immediately recognising in what I'm doing. As I say, it's just a small toy (and I think one that would definitely be easier in a different language, but anyway...). At the minute I'm actually at the point where I'm preallocating and persisting a set of internal objects, and at a very very small scale it's ok, but each exploration in structure starts to become manageable pretty quickly.

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

#516

Post by zemo »

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

As a gamedev i would LOVE to give the gc 1ms per frame if it would be hard bounded and allocs are guaranteed not to stall.

Go is honestly probably not a great language for game development for other reasons but the GC could likely clear that goalpost. https://blog.golang.org/ismmkeynote

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

#517

Post by loeg »

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.

Again, we're talking about a very restricted hard realtime environment. How do you trust, let alone qualify, a 3rd party binary blob that you know calls malloc(), which is a direct violation of your own design requirements?

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

#518

Post by jayd16 »

doomlaser wrote: post #513
jayd16 wrote: post #325

Earlier quoted context omitted.

That Unity was using that ancient collector was the main complaint. Switching to an incremental GC is long overdue. As for pooling objects, you'd go to those "extreme measures" as a matter of course in any other language as well. You wouldn't want to alloc and free every frame no matter the language.

Yes. the boehm collector is the root of the problem for Unity's runtime. It's just the verbatim code from that repository in fact. But in other languages, such as C with standard libraries, you can still do common things like comparing stings and calling printf() without inadvertently triggering a dreaded GC sweep. Not so in Unity's C#. And allocating memory is fine during runtime when you are in control of the alloc…

You can just set the GC mode to disabled and run it manually.

https://docs.unity3d.com/ScriptReference/Scripting.GarbageCo...

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

#519

Post by doomlaser »

jayd16 wrote: post #518
doomlaser wrote: post #513

Earlier quoted context omitted.

Yes. the boehm collector is the root of the problem for Unity's runtime. It's just the verbatim code from that repository in fact. But in other languages, such as C with standard libraries, you can still do common things like comparing stings and calling printf() without inadvertently triggering a dreaded GC sweep. Not so in Unity's C#. And allocating memory is fine during runtime when you are in control of the alloc…

You can just set the GC mode to disabled and run it manually. https://docs.unity3d.com/ScriptReference/Scripting.GarbageCo...

That API is new and was just added to 2018.3 in December, around the same time they started previewing the incremental garbage collector and promoting ECS.

From Unity:

> Being able to control the garbage collector (GC) in some way has been requested by many customers. Until now there has been no way to avoid CPU spikes when the GC decided to run. This API allows you disable the GC and avoid the CPU spikes, but at the cost of managing memory more carefully yourself.

It only took them 14 years and much hand wringing from both players and developers to address :)

A similar thing is going on with their nested scene hierarchy troubles, also releasing in 2018.3 with their overhaul to the prefab system, to sort of support what they call "prefabs" having different "prefabs" in their hierarchy without completely obliterating the children. What they have now is not ideal, but they're working on it.

Prior to that, if you made. say, a wheel prefab and a car prefab, as soon as you put the wheels into your car prefab, they lost all relation to their being a wheel, such that if you updated the wheel prefab later, the car would still just have whatever you had put into the car hierarchy originally, which naturally has been the source of endless headaches and hacky workarounds for many developers.

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

#520

Post by uvtc »

> Haxe feels much more promising than most alternatives. If I do web stuff again I'll be diving in here. There is some good library support. I am a little concerned by its relative youth, will it last?

Haxe has actually been around since 2005 or so. I'm really liking Haxe as a general-purpose compile-to-just-about-anything language.

Post reply on HN