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

391–400 of 556 posts

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

#391

Post by AnimalMuppet »

PorterDuff wrote: post #324
detaro wrote: post #319

Earlier quoted context omitted.

What percentage of the market is A/V build to actual hard real-time standards, and not expected to run on devices that can't provide it (so no PCs with normal OSes, no smartphones)? For the vast majority, soft real-time is fine, since an occasional deadline-miss results in minor inconvenience, not property damage, injury or death. I assume some dedicated devices are more or less hard real time, due to running way sim…

I take it that scarcely anyone here has written software for video switchers, routers, DVEs, linear editors, audio mixers, glue products, master control systems, character generators, etc. etc. Missing a RT schedule rarely results in death, but you'd think so given the attitude from the customer. That's a silly definition for it. There's a whole world out there of hard real time, the world is not simply made up of st…

I actually have written software for video routers and character generators. We didn't consider them hard real time, though I wouldn't claim that such was standard industry usage.

For example, if you're doing a take, you have to complete it during the blanking interval, but usually the hardware guarantees that. In the software, you want you take to happen in one particular vertical blanking interval (and yes, it really is a frame-accurate industry). But if you miss, you're only going to miss by one. We didn't (so far as I know) specify guarantees to the customer ("If you get your command to the router X ms before the vertical interval, your take will happen in that vertical"), so we could always claim that the customer didn't get the command to the router in time. Again, so far as I know - there may have been guarantees given to the customer, but I didn't know about them.

But that was 20 years ago, back in the NTSC 525 days.

Nice name, by the way. Do you know of any video cards that will do a true Porter & Duff composite these days? I recall looking (again, 20 years ago) at off-the-shelf video cards, and while they could do an alpha composite, it wasn't right (and therefore wasn't useful to us).

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

#392

Post by AnimalMuppet »

vnorilo wrote: post #375
kazinator wrote: post #203

Earlier quoted context omitted.

C++ RAII is completely gone without the use of classes; it requires something with a destructor.

I guess the OP means pod types (plain Cish structs) where dtors are implicit.

But then what's left of RAII? What resource is there to allocate other than the memory itself? RAII means more than just "get memory to put this in".

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

#393

Post by Uptrenda »

I've been surprised and delighted by C recently myself; Being able to make a small change to a datatype, variable name, and so on, and then instantly seeing an IDE highlight errors relating to it is amazing for productivity. The language is incredibly simple. I mostly use structures to define my own 'types' and design functions to work on pointers to those types. That way you can control whether you want your data to live on the stack or heap and its fairly robust. I've rarely if ever had to use function pointers or macros, but they're there if you need more advanced features. I find just being able to manipulate memory and buffers as raw bytes with no bullshit wrappers helps you so much with actual programming (TM.)

As far as data types go, I haven't used much more than linked lists and basic hash maps so far. For everything else I use fixed-sized arrays. It helps you precisely control how much memory the program is using without worrying that some higher-level magic garbage collector will overflow. Despite having that level of control, I haven't been frustrated by it yet. Yes, the standard library is very basic, but you can add the types you need very easily. There's some beautiful C code out there that will give you exactly what you want without having to include hundreds of obscure futures you'll never need. Overall, I've been very happy with it, and I look forwards to trying to run my code on all kinds of weird and wonderful platforms. I see huge competitive benefits for C code bases, to be honest.

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

#394

Post by bsder »

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…

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

Even if you are perfect, you will still fragment over time. At some point, you must move a dynamically allocated resource and incur all the complexity that goes with that--effectively ad hoc garbage collection.

There are only two ways around this:

1) You have the ability to do something like a "Loading" screen where you can simply blow away all the previous resources and re-create new ones.

2) Statically allocate all memory up front and never change it.

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

#396

Post by eigenloss »

ChrisSD wrote: post #124
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.

I'm not sure that rehashing Rust vs. C is particularly interesting at this point. At least not for those who regularly read HN. Maybe in another few years...

Sounds like Rust has come pretty far.

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

#397

Post by vnorilo »

AnimalMuppet wrote: post #392
vnorilo wrote: post #375

Earlier quoted context omitted.

I guess the OP means pod types (plain Cish structs) where dtors are implicit.

But then what's left of RAII? What resource is there to allocate other than the memory itself? RAII means more than just "get memory to put this in".

Presuming GP includes unique_ptr, there's no real loss of RAII. In my opinion you might as well write trivial classes, but hey, to each his own.

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

#398

Post by lone_haxx0r »

Bekwnn wrote: post #258

I have similar frustrations using C++, but don't feel using C or even Rust would be an improvement, more of "side-grade" due to various tradeoffs those languages have for game development compared to C++. I am excited about the development of both Zig and Jai since they both are trying to fill what I believe is a much needed role of a C-like language with a few more nice language features like better compile-time cod…

The thing I hate about them is the backwards declaration syntax.

var x:i32 = 5; ugh, it makes no sense.

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

#399

Post by xigency »

einpoklum wrote: post #50

> [C++] is high performance, and it offers but features I don't want, and at a great complexity cost. 1. Complexity of implementation is not complexity of use. Example: Take std::array vs a plain C array. std::array is a few hundreds of lines of code. But - it's about as inutitive to use; has more convenience features; easier for the compiler to optimize; and doesn't let you should yourself in the foot that easily. 2…

Serious game developers often do not use STL as a matter of habit and principle.

That goes for most of your points about standard libraries. If you are developing code that you expect (or hope) to run on Windows, Linux, Nintendo consoles, phones, PS4's and Xboxes and expect to know the real performance cost of operations, you will be writing all of your own standard libraries anyway. It is very much a problem of "...the complexity of non-standardized often-inconsistent idiosyncratic platforms and libraries for achieving the same things."

> Complexity of implementation is not complexity of use.

And that's where the language complexity comes into play. Game developers who are bootstrapping need to implement and use these pieces. If you are simplifying your life with C++ features, you must know the ins-and-outs and you cannot rely on new language features because you don't have a choice of compiler in most cases.

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

This is a fair ask and is definitely more accurate of C than C++. What you might write is longer, more tedious code, but that is its own trade-off.

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

#400

Post by zemo »

PavlovsCat wrote: post #390
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…

> what I find so deeply frustrating is that the argument that GC can't work in a game engine is never qualified The program having a say in how the GC behaves would be one requirement IMO. > you could run a GC on every single frame and use less than 3% of your frame budget on the GC pause Could I? In what languages?

not sure about other managed runtimes but in Go you can disable the automated GC scheduling and schedule it yourself. The GC runs in sub-millisecond time. https://blog.golang.org/ismmkeynote

the point isn't "Go is good enough", because I don't know if it is because the requirements are not stated particularly clearly. If the GC took zero time, duh, it would work and people could use it, it would save them some error cases and make their programming lives easier. If the GC took 3 seconds, it doesn't work. There exists some latency value under which a GC is fast enough that there's no sane argument for -not- using it. What is that value? That's the question at hand.

Post reply on HN