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

331–340 of 556 posts

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

#331

Post by coldtea »

detaro wrote: post #319
PorterDuff wrote: post #316

Earlier quoted context omitted.

""soft" real-time (e.g. games, or audio/video) " Hah. Who sez that audio and video products have 'soft' real time? Go on now.

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…

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

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

#332

Post by weberc2 »

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.

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

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

#333

Post by fastball »

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…

You just agreed with the OC.

RT video/audio failing never results in death. Where as failures in "avionics, industrial control" absolutely can / do. That seems to be where OC was drawing the line.

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

#334

Post by cdirkx »

Avamander wrote: post #314
z3phyr wrote: post #81

Earlier quoted context omitted.

I like rust, but for me, it is significantly more difficult to read and write. Same can be said about C++ with extreme STL code.. I prefer to read and write simple C like syntax. I would love it if I can get Rust concept of borrowing in C, or even simple operator overloading..

Same, I heavily prefer less symbols in my code. I think it might also relate to how I find it much harder to remember long formulas but than remembering the sentence describing the formula. If I could type for example `brw x` instead of `&x` I think I'd like it more - I guess I like it more Python-y?

You could use a macro :)

  macro brw($expr:expr) { &$expr }
And use it like 'brw!(x)' instead of '&x'.

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

#335

Post by weberc2 »

stephc_int13 wrote: post #299
weberc2 wrote: post #198

Earlier quoted context omitted.

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

What is Unity’s STW time? Is it optimized for latency? If not, you’re using the wrong collector. The pain point it solves is time spent debugging memory issues and generally a slower pace of development, but of course if you’re using a collector optimized for throughout, you’ll have a bad time. Further, a low-latency GC will pay off more for people who haven’t been using C or C++ for 10 years than those who have.

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

#336

Post by johannes1234321 »

seamyb88 wrote: post #287
einpoklum wrote: post #248

Earlier quoted context omitted.

> when you can implement the vast majority of C++ features in native C No, you absolutely cannot, even in principle. C++ is not "C with classes" and some syntactic sugar like it started out. That's not been the case for many years already. Also, even the features you can implement - you won't; you don't have the person-years for that. You will have to, need to, use libraries. For those you need to compare the librari…

So which feature can you not implement? The only I can think of which you'd have real problems are anonymous functions/lambdas. Most other features I think you can implement. It won't look the same, but it will serve the same purpose.

Things coming to mind:

Pointers which can't be NULL (aka. references)

Exceptions which also clean up intermediate frames (the exception itself can be done with longjmp, but no destructors which could be run)

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

#337

Post by piaste »

viraptor wrote: post #329
drudru11 wrote: post #261

Earlier quoted context omitted.

Wow - disabling the caches is an extreme measure. I get it though. After doing that, you can (probably) do cycle counting on routines again. Just like the 80s or earlier.

I don't. Maybe we're thinking about different kind of caches, but if these are transparent, no-performance-impact caches, then why wouldn't you prove the system works well with caches off (guarantee deadlines are met), then enable caches for opportunistic power gains?

Who will provide a guarantee that the caches are truly transparent and will not trigger any new bugs?

Essentially, you would need to prove the statement "if a system works well with caches off, then it works well with caches on" to the satisfaction of whatever authority is giving you such stringent requirements.

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

#338

Post by detaro »

fastball wrote: post #333
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…

You just agreed with the OC. RT video/audio failing never results in death. Where as failures in "avionics, industrial control" absolutely can / do. That seems to be where OC was drawing the line.

Seems to be a common distinction, although GP is right with the addition that the production side of things is more demanding (and at least would suffer financial damage if problems occur to often) than the playback side formed by random consumer gear, and has some, especially low-level/synchronization-related, gear to hard standards. But often soft is enough, as long as it's reliable enough on average.

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

#339

Post by badatshipping »

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

It's common to use stack and pool memory allocators, where this becomes no longer expensive work.

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

#340

Post by takeda »

correct_horse wrote: post #283
mlthoughts2018 wrote: post #227

Earlier quoted context omitted.

Doesn’t this just change semantics? Whatever custom handlers you wrote for manipulating that big chunk of memory are now the garbage collector. You’re just asking for finer grained control than what the native garbage collection implementation supports, but you are not omitting garbage collection. Ostensibly you could do the exact same thing in e.g. Python if you wanted, by disabling with the gc module and just writi…

C's free() gives memory back to the operating system(1), whereas, as a performance optimization, many GCd languages don't give memory back after they run a garbage collection (see https://stackoverflow.com/questions/324499/java-still-uses-s... ). Every Python program is using a "custom allocator," only it is built in to the Python runtime. You may argue that this is a dishonest use of the term custom allocator, but c…

Python is a bad example to talk about gc, because it uses different garbage collector than most of languages. It is also the primary reason why getting rid of GIL and retaing performance is so hard. Python uses reference counters and as soon as the reference count drops to 0 it immediately frees the object, so in a way it is more predictable. It has also a traditional GC and I guess that's what was mentioned you can disable it. The reason for it is that reference count won't free memory of there is a loop (e.g. object A references B and B references A, in that case both have reference count 1 even though nothing is using them), do that's where the traditional GC steps in.
Post reply on HN