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

291–300 of 556 posts

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

#291

Post by loup-vaillant »

tomp wrote: post #157
eropple wrote: post #111

Earlier quoted context omitted.

It's a requirement if you do network I/O whether you realize it or not.

If a bug in a game's network IO crashes/takes over the whole OS, the security vulnerability is in the OS, not in the game.

That's not the point. The point is, if you do network I/O, you are processing untrusted packets from the internet. If a carefully crafted set of such packets can trigger, say, a buffer overflow, you're toast.

A first line of defence is authentication. Make sure the packets come from a trusted source (you can MAC each packet for this), so only those trusted sources could possibly trigger the vulnerability.

If the only trusted source is an authoritative server, you might be able to hide that buffer overflow. If your network code is peer to peer however, you have to trust the other players not to run a cheat that takes over your machine… but at least that's not the whole internet.

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

#292

Post by jimmaswell »

forrestthewoods wrote: post #212
emmericp wrote: post #185

Earlier quoted context omitted.

Not a game developer, but I used to write UI addons for World of Warcraft. WoW allows you to customize your UI heavily with these Lua plugins ("addons") and Lua is garbage collected. It's a reasonable incremental GC so it shouldn't be too bad in theory. But in practice it can be horrible. You end up writing all kinds of weird code just to avoid allocations in certain situations. And yeah, GC pauses due to having lots…

I’ve shipped C++ games and Unity games. I have never spent more time managing memory than in C#. You have to jump through twisted, painful hoops to avoid the GC. Memory management is ultimately far simpler and easier in C++ than in C#.

I do gamedev in Unity and avoiding garbage creation feels easy enough to me for the most part.

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

#293

Post by h0l0cube »

zemo wrote: post #288
h0l0cube wrote: post #285

Earlier quoted context omitted.

I worked as a games programmer for 8 years in C/C++, and spent an accumulated 2 years just doing optimisation, during the time of 6th and 7th generation consoles. Freeing resources in a deterministic manner is important for the following reasons: FRAME RATE: having a GC collect at random frames makes for jerky rendering SPEED: Object pools allow reuse of objects without allocing/deallocing, and can be a cache-aligned…

you can turn off the gc in Go and run it manually. you can also write cache-aligned arrays of structs in Go if you want to. you can allocate a slab and pull from it if you want to. the existence of a GC doesn't preclude these possibilities.

>you can turn off the gc in Go and run it manually

And if you run the GC manually, you really don't know how long it will take - read: determinism.

> you can also write cache-aligned arrays of structs in Go if you want to

Wasn't this thread about why people don't use GC, not about go? I don't remember.

If you're using an object pool, you're dodging garbage collection, as you don't need to deallocate from that pool, you could just maintain a free-list.

> you can allocate a slab and pull from it if you want to. the existence of a GC doesn't preclude these possibilities

To take it further, you could just allocate one large chunk of memory from a garbage collected allocator and use a custom allocator - you can do this with any language. But you're not using the GC then.

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

#294

Post by boomlinde »

axaxs wrote: post #267
jdmoreira wrote: post #230

Earlier quoted context omitted.

I just want to say that no, you don’t need to free the resources. It's very possible to use a fix amount of heap memory during the whole lifecycle of your game. In fact I think that’s what people should aim for in 90% of the cases.

You can do the same thing in GC'd languages, though.

In which the garbage collector serves no advantage; only as a trap you have to remind yourself to step over.

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

#295

Post by inimino »

abetusk wrote: post #277

I had never considered a "data-centric" approach to be anti OOP but from the article: > I am not an OOP convert. I've spent most of my professional life working with classes and objects, but the more time I spend, the less I understand why you'd want to combine code and data so rigidly. I want to handle data as data and write the code that best fits a particular situation. I've come around to the idea much more that…

> Are OOP and "data-centric" approaches at odds with each other?

Yes, because OOP Objects are data plus code (methods). If you don't have methods, but just pass data around, you don't have OOP. If you do have methods, you meet the "expression problem".

If you have static types and well typed code you get pure data at runtime, and if you include unions and product or sum types at runtime, you end up with algebraic datatypes, and if you have RTTI and polymorphism and inheritance then you get classical OOP.

If you have just data living in memory at runtime, and just transformations of the data (functions) sitting in your code, then you get FP.

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

#296

Post by inimino »

makecheck wrote: post #114

I’m not sure why but programmers like to reject entire languages instead of just rejecting the features they don’t like. A lot of stuff in C++ is entirely avoidable. Protocol-oriented programming is extremely useful for games and I like Objective-C for that reason. (Objective-C doesn’t meet his mentioned goal of portability but this is an example where C++ could be used to gain “light” inheritance without having to o…

> I’m not sure why but programmers like to reject entire languages instead of just rejecting the features they don’t like.

The article mentions that:

>> What I want from a language

>> The strongest thing on my desired, but not required list is simplicity. I find looking up language features, and quirky 'clever' api's incredibly tiring. The ideal language would be one I can memorize, and then never have to look things up. (emphasis mine)

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

#297

Post by oppositelock »

yellowapple wrote: post #262
jackjeff wrote: post #184

Earlier quoted context omitted.

> C++ is as complex as you want to make it I second that. I always find the attitude of “C++ is bad so I’m going to stick to C” really bizarre. You can use C++ as a better C. - use type inference and references instead of pointers. Writing C style code with these features makes it more readable. - Don’t like OO programming. Stick to struct with all members public. It’s going to be a lot better than doing the same thi…

> use exceptions instead of return code for errors I happen to have the exact opposite opinion. Exception handling tends to feel too "magical" (read: non-deterministic, hard to behaviorally predict, etc.) relative to just returning an error code.

Exception handling doesn't work very well. It requires exception frames on the stack, and those go missing sometimes, leading to leaked exceptions and unexpected crashes. For example, if you pass a C++ callback function into a C callback, say in libcurl, the C library doesn't have exception handler frames in the stack, so exceptions are lost. If your C++ code throws from within that C callback, any catch above the C language boundary won't work. This is just one of countless gotchas. Don't use exceptions.

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

#298

Post by stephc_int13 »

eropple wrote: post #111
stephc_int13 wrote: post #63

Earlier quoted context omitted.

Yeah, I am not talking about vulnerabilities. I am simply talking about ease of use and avoidance of leaks and crashes. Writing super secure code is usually not a requirement for gamedev, and I completely agree, this is hard and potentially harder in C than, say, in Rust.

It's a requirement if you do network I/O whether you realize it or not.

In gamedev, we often use UDP for network I/O.

I am far from an expert in security but I've done a bit of reversing/hacking when I was 16 years old (DOS era)

I think this is hard to check for everything, but in my opinion, good security can be achieved with extreme simplicity.

Packets are fixed-size, every fields are manually bound checked and the packet is rejected if anything looks wrong.

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

#299

Post by stephc_int13 »

weberc2 wrote: post #198
stephc_int13 wrote: post #120

Earlier quoted context omitted.

There is no general answer to this question. Frame latency, timing and synchronization is a difficult subject. Some games are double or triple buffered. Rendering is not always running at the same frequency as the game update. The game update is sometimes fixed, but not always. I've had very awful experience with GC in the past, on Android, the game code was full C/C++ with a bit of Java to talk to the system APIs, I…

You didn't have a bad experience with GC in the past, you had a bad experience with a single GC implementation, one which was almost certainly optimized for throughput and not latency and in a language that pushes you toward GC pressure by default. :)

This is an example.

I never worked with Unity myself but I worked with people using Unity as their game engine, they all had problems with stuttering caused by the GC at some point.

You can try to search Unity forums about this subject, you'll find hundreds or thousands of topics.

What really bothers me with GC is that it solves a pain I never felt, and creates a lot of problems that are usually more difficult to solve.

This is a typical case of the cure being (much) worse than the illness.

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

#300

Post by [deleted] »

tomxor wrote: post #219
weberc2 wrote: post #175

Earlier quoted context omitted.

Go’s GC is low latency and it allows you to explicitly trigger a collection as well as prevent the collector from running for a time. I would wager that the developer time/frustration spent taming the GC would be more than made up for by the dramatic improvement in ergonomics everywhere else. Of course, the game dev libraries for Go would have to catch up before the comparison is valid.

Why is this downvoted? is it factually wrong? (I don't know Go so I'm asking)

[deleted]
Post reply on HN