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

521–530 of 556 posts

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

#521

Post by weberc2 »

xyproto wrote: post #511
weberc2 wrote: post #332

Earlier quoted context omitted.

Yeah, C compilers optimize much more than Go compilers. Performance is C’s most noteworthy advantage over Go.

GCC can compile both C and Go. I searched for benchmarks but found none for GCC 9 that compares the performance of C and Go. Do you have any sources on this?

I don’t have a source, but it’s common knowledge in the Go community. Not sure how GCC works, but it definitely produces slower binaries than gc (the standard Go compiler). There are probably some benchmarks where this is not the case, but the general rule is that gcc is slower. gc purposefully doesn’t optimize as aggressively in order to keep compile times low.

Personally I would love for a —release mode that had longer compile times in exchange for C-like performance, but I use Python by day (about 3 orders of magnitude slower than C) so I’d be happy to have speeds that were half as fast C. :)

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

#522

Post by jayd16 »

doomlaser wrote: post #519
jayd16 wrote: post #518

Earlier quoted context omitted.

You can just set the GC mode to disabled and run it manually. https://docs.unity3d.com/ScriptReference/Scripting.GarbageCo...

That API is new and was just added to 2018.3 in December, around the same time they started previewing the incremental garbage collector and promoting ECS. From Unity: > Being able to control the garbage collector (GC) in some way has been requested by many customers. Until now there has been no way to avoid CPU spikes when the GC decided to run. This API allows you disable the GC and avoid the CPU spikes, but at the…

All true. However, even before you could disable the GC, you could ignore it as long as you weren't allocating and hit framerate. Unity isn't magic but the way people talk it's like Unity games don't exist.

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

#523

Post by ncmncm »

Const-me wrote: post #506
skohan wrote: post #461

Earlier quoted context omitted.

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

Memory is just one kind of resources. Games do tons of I/O, often gigabytes/second. To illustrate, any PC game has a lot of places which call GPU driver like this: D3D11_MAPPED_SUBRESOURCE mapped; context->Map( buffer, 0, D3D11_MAP_WRITE_DISCARD, 0, &mapped ); // Write memory address pointed by mapped.pData context->Unmap( buffer, 0 ); With C++ RAII, you can do something like that instead: MappedBuffer mapped{ buffer…

This. Freeing memory is the least important job for destructors.

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

#524

Post by ncmncm »

MaulingMonkey wrote: post #507
ncmncm wrote: post #443

Earlier quoted context omitted.

> The problem isn't GC per se. In other words, the problem is GC, full stop.

Thing is, I've helped ship my share of GCs in games, and they're not always a problem. UI solutions often/usually use some kind of GCed language for scripting. But the scale and scope of what UIs are dealing with are small enough that we don't see 100ms GC spikes. Our tools and editors leverage GCed languages a lot - python, C#, lua, you name it - and as long as their logic isn't spilling into the core per-frame per-…

Right, well-contained GC in non-critical threads is not a problem. Once you get it trying to scan all of memory, your caches get corrupted, and only global measurements can tell you what the performance impact really is.

GC enthusiasts always lie about their performance impact, almost always unwittingly, because their measurements only tell them about time actually spent by the garbage collector, and not about its impact on the rest of the system. But their inability to measure actual impact should not inspire confidence in their numbers.

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

#525

Post by ncmncm »

oppositelock wrote: post #478
ncmncm wrote: post #439

Earlier quoted context omitted.

Don't pass functions to libcurl that throw. Otherwise, exceptions make code simpler, cleaner, and more reliable. They will never "go missing" unless you do something to make them go missing. Code that does those things is bad code. Don't write bad code. Do use exceptions.

Well, of course, that's how you fix such a bug, however, when using third party libraries and other people's code, you don't necessarily know that this is happening until you have missing exceptions. In my opinion, exceptions also complicate code by taking error handling out of the scope of the code you are writing, since you can't know whether anything you call throws, so you may not catch, and some higher level cod…

If you don't know what functions you are passing to third-party libraries, you have a much bigger problem than any language can help you with.

Google's proscription on exceptions is purely historical. Once they had a lot of exception-unsafe code, it was too late to change. Now they spend 15-20% of their CPU cycles working around not being able to use RAII.

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

#526

Post by inimino »

fileeditview wrote: post #434
inimino wrote: post #289

Earlier quoted context omitted.

Why pick a language that has a feature you need to immediately turn off? Some people probably want to, but ... why?

I guess you use every feature (insert any language here) offers for every program you write with it? The answer to your question is probably: because they like the language, are productive in it, know the libraries and the feature can be turned off so it's an option.

If I consistently don't use all the features, I pretty quickly start looking at simpler languages.

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

#527

Post by FrozenVoid »

z3phyr wrote: post #77
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?

If C gets operator overloading and RAII, there will be no good reason to use C++ for me!!

Only operator overloading is really important and would cut down the size of code written substantially. Thats the only real advantage of using C++ vs C. Everything else oop, function overloading,RAII,etc can be replaced with macros and structs.

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

#528

Post by neop1x »

hackits wrote: post #448
mike00632 wrote: post #418

Earlier quoted context omitted.

Do you happen to have a link to the guidelines?

http://spinroot.com/gerard/pdf/P10.pdf

I was wondering why I couldn't open this pdf on my android pdf viewer and this link gives me cloudflare's captcha. It uses google's ReCaptcha - storefronts, bicycles, semaphores. What a terrible practice. People stop overusing cloudflare!

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

#529

Post by tripzilch »

Can anyone explain me why this is on the front page? I mean it's basically someone bashing languages they've not worked with, not understand or in the case of C++ simply don't like. As in, he doesn't bring anything new or insightful to the table, just "this is my personal opinion". Which btw is a fine opinion, as far as personal ones go, not one that I share, but it's a perfect example of "great let's agree to disagree".

Which IMHO basically amounts to trolling for HN comments if you post it here. Now people are just going to argue how wrong he is, against and for their favourite languages and nobody will learn anything new or useful.

Is this guy well-known or something? Did he make any good games in C?

Maybe I'm missing the point of this article (someone please explain), but it looks like it's worth as a post is only as a discussion starter and an inflammatory one at that. If there was any time a reason to flag a discussion thread for being useless, it's this one I think.

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

#530

Post by tripzilch »

detaro wrote: post #347
coldtea wrote: post #331

Earlier quoted context omitted.

> For the vast majority, soft real-time is fine, since an occasional deadline-miss results in minor inconvenience, not property damage, injury or death. A "minor inconvenience" like a recording session going wrong, a live show with stuttering audio, skipped frames in a live TV show, and so on?

As long as the individual event happens seldom enough few of these actually are a big problem. Soft real-time being allowed to blow deadlines doesn't mean it can't be expected to have a very high rate of success (at least that's the definitions I've learned), and clearly a sufficiently low rate of failure is tolerated. There's a vast difference between "there's an audio stutter every day/week/month/..." and "noticeab…

The production side usually renders the final audio mix off-line, so no real-time requirements there for getting optimum sound quality. I'd say the occasional rare pop or stutter is worse to have during a live performance than when mixing and producing music.
Post reply on HN