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

461–470 of 556 posts

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

#461

Post by skohan »

ncmncm wrote: post #449
slacka wrote: post #33

Earlier quoted context omitted.

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.

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

Why? My understanding is that in modern game dev you're mostly traversing large arenas of structured memory, and you avoid freeing individual objects like the plague.

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

#462

Post by alxlaz »

loeg wrote: post #318
GuB-42 wrote: post #278

Earlier quoted context omitted.

I have actually worked on a system where malloc() was forbidden. In fact it always returned null. Buffers were all statically allocated and stack usage was kept to a minimum (it was only a few kB anyways). The software was shipped with a memory map file so you know exactly what each memory address is used for. A lot of test procedures involved reading and writing at specific memory locations. It was for avionics BTW.…

Why even define a malloc() in this environment if it always returns NULL?

Not OP but the most common reason I've seen is that this was an additional restriction that they imposed for their project. The standard library includes a perfectly working malloc. You override it so that you can't end up calling it accidentally, either explicitly (i.e. your brain farts and you do end up malloc()-ing something) or implicitly (i.e by calling a function that ends up calling malloc down the line). The latter is what happens, and surprisingly easy and often. Not all libraries have the kind of documentation that glibc has, nor can you always see the code.

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

#463

Post by gmueckl »

gypsyharlot wrote: post #208
gmueckl wrote: post #40

Earlier quoted context omitted.

Yup. Quake 3 is basic. I remeber that the whole game had a "measly" 150.000 lines of code or so. It doesn't do a ton of things modern games do. The list of things expected from modern games these days in comparion is far too long to list here. These things have become elaborate world simulators. And all of these features add up. The Unreal Engine is around 4 million lines without dependencies (e.g. PhysX, a proper au…

Quake 3 has 230.000 lines of code. If Quake 3 is considered basic, then any studio with less than 100 developers can probably reach for C. The Unreal Engine is far more than a modern game. You wouldn't call Clang and editor just because Vi was compiled with it.

The Unreal Engine is less than a modern game. The actual game is obviously missing. Also, you need engine specific editing tools to make a 3d game that looks more advanced than minecraft. It is a mistake to exclude them just because the don't have to be shipped with the final product.

And Quake 3 was made by a team of roughly 20 people. Id Software was quite small until they started to work on Rage.

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

#464

Post by ClumsyPilot »

greggman2 wrote: post #363
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…

There's probably 500+ successful GC based games on the Steam store another 100000 to a million hobby games doing just fine with GC. I started game programming on the Atari 800, Apple 2, TRS-80. Wrote NES games with 2k of ram. I wrote games in C throughout the 90s including games on 3DO and PS1 and at the arcade. I was a GC hater forever and I'm not saying you can ignore it but the fact that Unity runs in C# with GC a…

I don't think the argument is "you can't ship succesfull game with GC"

You might spend more time fighting the GC than benefitting from it. And that seems to be the experience for large games - simpler ones might not care.

Unity offers a lot more than just a language, and developers have to choose, are they willing to put up with GC to get the rest of what Unity offers.

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

#465

Post by beokop »

xamuel wrote: post #61
lurquer wrote: post #49

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. Am I an idiot for not knowing for sure this is a joke, or is the poster an idiot for not intending a joke? I'm so confused...

It's not intended as a joke, and please have patience with me if I'm an idiot. Imagine you had a program involving, say, chairs. It has things called chairs, which you pass around to functions which take chair arguments. Suddenly, the next version of the language comes out and now "chair" is a reserved keyword, and all your code is broken. To fix it, you have to go through your whole codebase and rename all your "cha…

By that logic, you can’t program interrupts with C because “int” is a reserved word.

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

#466

Post by HeavyStorm »

simias wrote: post #72
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 reality is you still have to free resources, so it's not like the garbage collector is doing work that doesn't need to be done. Does it? In most game I expect resource management to be fairly straightforward, allocation and freeing of resources will mostly be tied to game events which already require explicit code. If you already have code for "this enemy is outside the area and disappears" is it really that muc…

It's NOT "a bad idea that causes more problems than it solves", but still may be a bad idea for the (games, real-time, etc) industry.

GC means not only that memory management is simpler, it means that it goes away for most of the programs out there.

Most programmers I know aren't writing code that run Twitter-like servers or avionics, nor are they programming the next Doom game. These people are writing apps and doing back end coding for some big company where real-time isn't an issue and the focus is on getting code out fast, with good average quality and "cheap" labor.

In this case, having a high level language/runtime that doesn't requirs a programmer that can reason about allocations is key.

I can't even begin to tell the kind of codebase that I have seen. Two years ago I was working on a C/C++ legacy system that was thousands of lines of codes and almost every file had memory leaks (that cppcheck could find itself, mind you). Some of them where caused by delivery deadlines, most of them where caused by unskilled employees.

(oh, in case you're wondering: all those leaks where solved by having ten times the hardware and a scheduled restart of the servers)

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

#467

Post by alexhutcheson »

talkingtab wrote: post #155
stephc_int13 wrote: post #74

Earlier quoted context omitted.

I know this subject quite well and I will later publish a detailed article. The real run-time cost of memory management done well in a modern game engine written without OOP features is extremely low. We usually use a few very simple specialized memory allocators, you'd probably be surprised by how simple memory management can be. The trick is to not use the same allocator when the lifetime is different. Some resourc…

I buy this - specialized memory allocators, after all I've used mbufs. So which languages would be good or recommended for coercing types when using memory allocators?

C++ or Rust

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

#468

Post by notacoward »

nightcracker wrote: post #456
notacoward wrote: post #365

Earlier quoted context omitted.

> if these are transparent, no-performance-impact caches If there were no performance impact, there would be no point. I'm not just being snarky; there's an important point here. Caches exist to have a performance impact. In many domains it's OK to think about caching as a normal case, and to consider cache hit ratio during designs. When you say "no performance impact" you mean no negative performance impact, and tha…

While you might test your hard real-time requirements with caches disabled, there's still reason to run the code with caches afterwards. E.g. errors that didn't match a branch or input scenario during testing which would go over budget without cache, but with cache might prevent a crash. Another could be power consumption, latency optimization, or improvement of accuracy. E.g. some signal analysis doesn't work at all…

You could be right on some of those. That didn't seem to be the prevailing attitude when I worked in that area, but as I said that was a long time ago - and it was in only a few specific sub-domains as well.

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

#469

Post by xyproto »

littlestymaar wrote: post #423
xyproto wrote: post #419

Earlier quoted context omitted.

Can't think of any. Do you have an example?

You can't call native libraries without going through cgo. So unless you don't want to have audio, draw text and have access to the graphic APIs, you'll need cgo, which is really slow due to Go's runtime. For game dev, that's a no go (pun intended). Additionally, the Go compiler isn't trying really hard at optimizing your code, which makes it several times slower on a CPU-bound task. That's for a good reason: because…

You are only talking about the Go compiler from Google.

GCC also supports Go (gccgo) and can call native libraries just like from C.

I'm not saying there are no drawbacks in Go, just that I can't think of any advantages of C over Go.

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

#470

Post by Pombal »

jcelerier wrote: post #416
Pombal wrote: post #401

Earlier quoted context omitted.

You are describing 'zero cost abstractions'. Except that they are anything but zero cost. Game developers and low level programmers shy away from them because of their impact in compile and build times, debug build performance and stack trace bloat, increased cognitive load, reduced refactoring ability. Even std::unique_ptr has runtime costs in release builds that a raw pointer does not. In game development performan…

> Even std::unique_ptr has runtime costs in release builds that a raw pointer does not. O RLY ? https://gcc.godbolt.org/z/QhbUjI

Yes, really. It's fine for simple types but for more complex types in more complex situations, you pay the price.

Unique pointers carry around not just the type but also a default deleter, if you provide one. That deleter has to be copied around, checked for nullptr before execution and set to nullptr when ownership changes.

For even more examples of this have a look at this talk when it comes out: https://cppcon2019.sched.com/event/Sfq4/there-are-no-zero-co...

Post reply on HN