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

411–420 of 556 posts

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

#411

Post by jcelerier »

AnimalMuppet wrote: post #391
PorterDuff wrote: post #324

Earlier quoted context omitted.

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 real…

I work on an open-source music sequencer (https://ossia.io) and no later than two days ago I had a fair amount of mails with someone who wanted to know the best settings for his machine to not have any clicks during the show (which are the audio symptoms of "missed deadline"). I've met some users who did not care, but the overwhelming majority does, even for a single click in a 1-hour long concert.

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

#413

Post by lacampbell »

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…

From the article:

"...I care about the speed of the compiler. I am not a zen master of focus, and waiting 10+ seconds is wasteful, yes, but more importantly it breaks my flow. I flick over to Twitter and suddenly 5+ minutes are gone."

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

#414

Post by jcelerier »

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 tends to feel

do you program a lot with your feelings ?

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

#415

Post by zippie »

Impossible wrote: post #355
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.…

Malloc was forbidden in a AAA title I worked on. Interestingly enough we also had two (!!!) embedded garbage collected scripting languages that could only allocate in small (32MB, 16 MB) arenas and would assert if they over allocated.

In modern C libraries malloc is mmap’ed anon pages underneath for an increasingly larger set of conditions these days.

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

#416

Post by jcelerier »

Pombal wrote: post #401
tejohnso wrote: post #361

Earlier quoted context omitted.

Also, the C++ committee is very serious about not paying for what you don't use. You can rest assured that there's no unused, hidden C++ bloat that is chipping away at your frame budget. This is not meant to be a strawman against the complexity cost argument, it's just a related feature of C++ that I thought might be worth explicitly pointing out in case anyone is misinterpreting. Also, if anyone has a credible dispu…

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

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

#417

Post by jcelerier »

0x0aff374668 wrote: post #105

Makes some really great points, similar to why C++ is not favored for embedded. C++ compilers are just too unpredictable and when trying to meet code limits in 128K, 32K or even 2K of flash, C++ is a nightmare. All of the major embedded SDKs (STM, Microchip, SiLabs, TI, NXP, I could go on) are written in C... and C only. MBED is C++, but I've never encountered or heard of an OEM or integrator using MBED in a real pro…

> Makes some really great points, similar to why C++ is not favored for embedded. C++ compilers are just too unpredictable and when trying to meet code limits in 128K, 32K or even 2K of flash, C++ is a nightmare. All of the major embedded SDKs (STM, Microchip, SiLabs, TI, NXP, I could go on) are written in C... and C only.

OTOH Arduino is C++ and works fine for millions of people, I've also dabbled a bit in various AVR, STM32 and ESP8266, all in C++.

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

#418

Post by mike00632 »

hackits wrote: post #307
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.…

Sounds very similar to NASA C programming guidelines. Each module during the initialization period would allocate its static memory size. Every loop had a upper bound's max iteration to prevent infinite loops. I think they posted the guidelines and it was a wonderful read about how they developed real time systems.

Do you happen to have a link to the guidelines?

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

#420

Post by xyproto »

bufo wrote: post #234
weberc2 wrote: post #186

Earlier quoted context omitted.

You’re writing in a much improved C. Strong type system (including closures/interfaces/arrays/slices/maps), sane build tooling (including dead simple cross compilation), no null-terminated strings, solid standard library, portability, top notch parallelism/concurrency implementation, memory safety (with far fewer caveats, anyway), etc. Go has it’s own issues and C is still better for many things, but “Go with manuall…

Go’s compiler is not at all optimized for generating fast floating point instructions like AVX and its very cumbersome to add any kind of intrinsics. This might not matter for light games but an issue when you want to simply switch to wide floating point operations to optimize some math.

Which compiler? The one from Google, GCC (gccgo) or TinyGo?
Post reply on HN