How old is this article? It says Haxe is new, but Haxe is a relatively old tool, first released in 2006.
Why I Write Games in C (yes, C)
231–240 of 556 posts
Re: Why I Write Games in C (yes, C)
#232[2016] it seems
Re: Why I Write Games in C (yes, C)
#233> 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…
Even Unreal Engine has garbage collection for UObjects. I love C but I don't think it's necessarily the best language for games programming anymore, I believe C++ is more suited since games fit into the OO paradigm so much better. I am only a hobbyist though so my opinion probably doesn't matter.
EDIT: Unreal Engine is primarily written in C++, and has garbage collection. I'm not salty about the downvote, but I would like to understand why what I have said is apparently incorrect.
Re: Why I Write Games in C (yes, C)
#234Earlier quoted context omitted.
> 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.
You’re writing in a much improved C. Strong type system (including closures/interfaces/arrays/slices/maps), sane build tooling (including dead simple cross compilation), no null-terminated strings, solid standard library, portability, top notch parallelism/concurrency implementation, memory safety (with far fewer caveats, anyway), etc. Go has it’s own issues and C is still better for many things, but “Go with manuall…
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.
Re: Why I Write Games in C (yes, C)
#235I'm currently trying to decide if Nim is my C replacement. On the one hand, it isn't C++, and it has real type safety, and it interfaces with existing C libraries very easily. On the other hand, it is rapidly getting very complicated, and seems almost eager to become another C++ in terms of sheer volume of language features.
[deleted]
Re: Why I Write Games in C (yes, C)
#236Earlier quoted context omitted.
There is still the STL, there are still templates and data structures have a very well-defined lifetime.
Isn't the STL mostly classes? How is that not OO?
Well, yes you have some objects in there. But it is rather an implementation detail. You don't use inheritance for instance.
Re: Why I Write Games in C (yes, C)
#237Have you tried D? It’s popular in game development world and very pleasant to work with. https://dlang.org/
D doesn't seem to be popular in any field, unfortunately.
Not popular, but it was definitely used: http://dconf.org/2016/talks/watson.html
> Can D be used to make games? Yes. Has it been used in a major game release? It has now. Remedy Entertainment have successfully shipped the first AAA game to use D code. And it’s in a fairly critical subsystem too. This talk will cover the usage of D in Quantum Break, problems encountered and solved, and where we want to take our usage of D in the future.
Re: Why I Write Games in C (yes, C)
#238No mention of Rust?
So I dug some more, and it turns out that while he does have something to say about Rust, I'm not sure I'm convinced by his conclusion about safety: "Safety. Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows. I especially refuse to “rewrite it in Rust” - because no matter what, rewriting an entire program from scratch is always going to introdu…
how do you know the article by Drew DeVault represents the opinion of the author of the article above? Did he link it somewhere?
Re: Why I Write Games in C (yes, C)
#239Earlier quoted context omitted.
> 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.
Unfortunately the excellent standard library is a major benefit of Go, and it uses the GC, so if you set GOGC=off you're left to write your own standard library.
I would also like to see a stripped-down version of Go that disables most heap allocations, but I have no idea what it would look like.
Re: Why I Write Games in C (yes, C)
#240> 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 pooling objects) with no clear single cause to blame.
Other issues I've seen include nondeterministic GC sometimes failling to garbage collect one level before we loaded another, OOMing the game. Have you ever forced a GC three times in a row to try and ensure you're not doubling your memory use on a memory constrained platform? I have. (This was exacerbated by cycles between the GCed objects and traditionally refcounted objects - you'd GC, which would run finalizers that would decref, which in turn would unroot some GCed objects allowing them to be collected, which in turn run more finalizers, which would decref more objects, ...)
The last time I encountered a similar (de)alloc spike in a non-GC gamedev system was much longer ago, and it was a particular gameplay system freeing a ton of graphics resources in a single frame, when doing something akin to a scene transition or reskinning of the world - which was easily identified with standard profiling tools, and easily fixed in under a day's work by simply amortizing the cost of freeing the resources over a few frames by delaying deallocs with a queue. More commonly there were memory leaks from refcounted pointer cycles, but those also generally pretty easily identified and fixed with standard memory leak detection tools.
The problem isn't GC per se. It's that most/all off-the-shelf language-intrinsic GCs are opaque, unhookable, uncustomizable, unreplacable black boxes which everything is shoved into. malloc/free? Easily replaced, often hookable. C++'s new/delete? Overloadable, easily replaced, you have the tools to invoke ctors/dtors yourself from your own allocators. Localized GC for your lock-free containers ala crossbeam_epoch? Sure, perfectly fine. Graphics resource managers often end up becoming something similar to GCed systems on steroids, carefully managing when resources are created and freed to avoid latency spikes or collecting things about to be used again soon.
But the GCs built into actual languages? Almost always a pain in the ass.