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

81–90 of 556 posts

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

#81

Post by z3phyr »

the_gipsy wrote: post #22
ChrisSD wrote: post #5

So... essentially "I know and like C". Which is great! But as you say, that's not particularly useful for anybody else.

The guy should try Rust and then explain why he prefers either, that would be interesting.

I like rust, but for me, it is significantly more difficult to read and write. Same can be said about C++ with extreme STL code..

I prefer to read and write simple C like syntax. I would love it if I can get Rust concept of borrowing in C, or even simple operator overloading..

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

#82

Post by skrebbel »

choeger wrote: post #68
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?

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?

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

#83

Post by klipt »

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.

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?

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

#84

Post by detaro »

facorreia wrote: post #54
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…

Indeed, and also what about the effect of multiple cores? You could have 7 cores working on game logic and one doing GC.

That sounds like a massive synchronization nightmare and performance overhead that'll probably not be worth it.

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

#85

Post by matttb »

Scarbutt wrote: post #38
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…

Handmadehero started as C but transition to C++ AFAICT ?

It was C++ from day one because he intended to use operator overloading

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

#86

Post by pdpi »

bcrescimanno wrote: post #70
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…

Disclaimer: I'm not a game developer; but, I've worked on a lot of projects with tight frame time requirements in my time at Netflix on the TVUI team. I also have no experience in Go so I can't comment on the specifics of that garbage collector vs. V8. I don't think it's necessarily that it "can't" work as much as it takes away a critical element of control from the game developers and the times you find yourself "at…

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

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

#87

Post by zem »

F-0X wrote: post #66
mumblemumble wrote: post #35

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

>On the other hand, it is rapidly getting very complicated This seems to be the case for almost any "C replacement", and it will be (my prediction, at least) the reason they all fail. I feel I might be a bit of an outlier in this respect, but I have only ever enjoyed using languages which are small and simple - C, Go, Scheme. The times I've tried Rust, it's been nice to have code that cannot segfault, but I find it s…

you would probably like zig, if you haven't given it a look yet.

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

#88

Post by Aeolun »

et2o wrote: post #27
the_gipsy wrote: post #22

Earlier quoted context omitted.

The guy should try Rust and then explain why he prefers either, that would be interesting.

Interesting. I want to like rust but everytime I dive in it is getting more and more complicated and verbose.

Less verbose, more complicated in my opinion.

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

#89

Post by Rusky »

pdpi wrote: post #86
bcrescimanno wrote: post #70

Earlier quoted context omitted.

Disclaimer: I'm not a game developer; but, I've worked on a lot of projects with tight frame time requirements in my time at Netflix on the TVUI team. I also have no experience in Go so I can't comment on the specifics of that garbage collector vs. V8. I don't think it's necessarily that it "can't" work as much as it takes away a critical element of control from the game developers and the times you find yourself "at…

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

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

#90

Post by TurboHaskal »

mruts wrote: post #42

C is one of my favorite languages but you know what be almost perfect for the author’s needs? OCaml! Almost as fast as C, no mandatory OOP, great performance, C FFI, nice FP, totally portable and native executables. Unfortunately OCaml is single-threaded, has a stop the world GC (though if it’s good enough for Jane Street it’s probably good enough for you), and sometimes has unfortunate syntax (though ReasonML fixes…

While OCaml boasts very low GC latency, I believe F# would be a better choice for writing games. It is an even more straight to the point OCaml; a Windows first class citizen; has a concurrent GC and I've heard C# is pretty popular for writing games due to Unity, so one might be able to leverage that (I don't know).

A non CLOS heavy SBCL codebase would also be excellent.

Post reply on HN