Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Thoughts on Modern C++ and Game Dev

elbeno.com

Post reply on HN
Print view View original

61–70 of 143 posts

Re: Thoughts on Modern C++ and Game Dev

#61

Post by andrewmcwatters »

overgard wrote: post #52

A few thoughts: * None of the problems that have been commented on are unique to the games industry at all. Slow debug builds suck for all C++ developers and weird template meta-programming is confusing for practically everyone. * He makes these broad hand-wavey statements like "individuals don't feel pain from slow compile times", or "big companies can just can throw processor power at it" to which I would say, BS.…

My question is, where are all these "big companies" who can throw more processor power at these problems? Because frankly, every major company I've been at uses the same commodity or cloud hardware everyone else does, so I just don't see it. It's a moot point.

Rarely do I see workstation-grade hardware in the wild, and when I have, they're build slaves that are incredibly anti-agile.

Re: Thoughts on Modern C++ and Game Dev

#62

Post by Kenji »

deng wrote: post #33

So, the solution to bad debug performance is essentially YAGNI? I'm afraid that isn't a very convincing argument. If your code is several orders of magnitude slower in debug mode, then this is a problem. Simply downplaying this with arguments like "single-step debugging is a last resort" or "just write better tests" won't make this problem vanish. Just like exploding compile times are not solved with "just buy Incred…

I never use the debugger for game design, except postmortem to see where the segfault happened. I have an advanced logging mechanism and sprinkle my code with logs. I see everything in the logs. There is no need to use the debugger because I always see what's happening. And I can compile my game without the logs (or disable them at runtime) if I need raw performance. That's how you do modern C++ programming.

Re: Thoughts on Modern C++ and Game Dev

#63

Post by andrewmcwatters »

jokoon wrote: post #60
edoo wrote: post #57

Most industry game dev is also done on top of C++ engines and libraries. I can see Go being used in the near future as the big engines offer bindings but I bet in 5-10 years the average startup is using something like C#. It is slow as beans but eventually CPU speed will make it much more reasonable for real use. The Unity engine is a good example. It has a weird easy powerful super bloated paradigm.

You just mentioned 2 garbage collected languages on a game dev topic. I don't think they're adequate. Remember how the article was very insistent about being able to control memory and CPU resources. Those are one of the few reasons C++ is not dead. Rust? I don't see it either.

A big part of this is ecosystem. You have so many game libraries and software that are written in C and C++. To many gamedevs, Rust is just a systems language Go. It doesn't bring anything significant to the table compared to just using a limited subset of C++.

Re: Thoughts on Modern C++ and Game Dev

#64

Post by deng »

jokoon wrote: post #60
edoo wrote: post #57

Most industry game dev is also done on top of C++ engines and libraries. I can see Go being used in the near future as the big engines offer bindings but I bet in 5-10 years the average startup is using something like C#. It is slow as beans but eventually CPU speed will make it much more reasonable for real use. The Unity engine is a good example. It has a weird easy powerful super bloated paradigm.

You just mentioned 2 garbage collected languages on a game dev topic. I don't think they're adequate. Remember how the article was very insistent about being able to control memory and CPU resources. Those are one of the few reasons C++ is not dead. Rust? I don't see it either.

His point is that many studios nowadays use an established engine and do not develop in the C++-from-scratch-style. Especially smaller studios do not have the capacity for this and also depend much more on cross-platform availability to generate more sales. So they use Unity or stuff like Gamemaker Studio and use whatever binding is available (C#/Boo/Js for Unity, Gamemaker Studio has its own language). Or they even turn to something more exotic, like Haxe/Heaps.

Re: Thoughts on Modern C++ and Game Dev

#65

Post by sehugg »

pulsarpietro wrote: post #3

I am a bit puzzled by this: "Before about the early 90s, we didn’t trust C compilers, so we wrote in assembly." There a lot of games released during the 80's, were they really all written in assembly ? https://www.myabandonware.com/browse/year/ I don't have experience in the game industry at all, I must add.

They weren't all in assembly. Lots of games were published in BASIC or Pascal or even custom interpreters like Z-Code. But most arcade games and cartridge titles were coded in assembly back then.

Re: Thoughts on Modern C++ and Game Dev

#66

Post by mattnewport »

overgard wrote: post #52

A few thoughts: * None of the problems that have been commented on are unique to the games industry at all. Slow debug builds suck for all C++ developers and weird template meta-programming is confusing for practically everyone. * He makes these broad hand-wavey statements like "individuals don't feel pain from slow compile times", or "big companies can just can throw processor power at it" to which I would say, BS.…

I think slow debug performance is a bigger problem for games than many other applications. It's annoying for everyone but the nature of games as interactive experiences means you often have to play a game to reproduce a bug easily and often with a full production level where the bug was reported, not with simpler test content. If you can't maintain a playable frame rate in debug builds this can be a problem.

This problem was worst in my experience in the Xbox 360 / PS3 generation because the in order processors handled debug builds very poorly and were different enough from a PC that it was common to have to debug on target rather than on a PC build on a much more powerful development machine. It's less of an issue with current generation consoles that are basically PCs as they don't suffer as badly with debug performance and many issues can be debugged on a PC build on a more powerful system. It may be more of an issue for mobile still.

Fortunately many of the newer features of C++ 17 and 20 help both with improving debug performance and with simplifying / reducing the need for "weird template meta-programming". Several also help with compile times and modules in particular are quite focused on tackling the biggest root cause of slow compiles in C++.

Re: Thoughts on Modern C++ and Game Dev

#67

Post by coldtea »

lifthrasiir wrote: post #16
coldtea wrote: post #12

Earlier quoted context omitted.

> That's not true. From my experience unit tests are great for agile. Not when you're constantly prototyping, which is what game dev essentially is for the most part of the process...

> which is what game dev essentially is for the most part of the process... Except that it isn't. You don't maintain the equal velocity of changes throughout the process, even for indie games. And there are always portions of the game amenable to tests.

Changes until the last minute to crucial gameplay elements are not uncommon..

Re: Thoughts on Modern C++ and Game Dev

#68

Post by mattnewport »

andrewmcwatters wrote: post #61
overgard wrote: post #52

A few thoughts: * None of the problems that have been commented on are unique to the games industry at all. Slow debug builds suck for all C++ developers and weird template meta-programming is confusing for practically everyone. * He makes these broad hand-wavey statements like "individuals don't feel pain from slow compile times", or "big companies can just can throw processor power at it" to which I would say, BS.…

My question is, where are all these "big companies" who can throw more processor power at these problems? Because frankly, every major company I've been at uses the same commodity or cloud hardware everyone else does, so I just don't see it. It's a moot point. Rarely do I see workstation-grade hardware in the wild, and when I have, they're build slaves that are incredibly anti-agile.

EA I know gives developers very powerful workstation class developer machines because I used to work there and have friends who still do and if anything it sounds like they've got even more powerful on a relative basis since I left.

Re: Thoughts on Modern C++ and Game Dev

#69

Post by MrRadar »

pjc50 wrote: post #29
richardjdare wrote: post #23

Earlier quoted context omitted.

Back then assembly language was much more ergonomic than it is now, and the machines were simpler. Many of my favourite games in the 80s were made by teenagers programming in their bedrooms. Check out this 68000 assembly tutorial video from Scoopex, the Amiga demo scene group: https://youtu.be/bqT1jsPyUGw He gets a simple graphical effect going on the Amiga in only a few lines of assembly. Doing the same thing using…

> much more ergonomic than it is now, This is an interesting line of argument - in what way, and what could be done to improve the ergonomics? > He gets a simple graphical effect going on the Amiga in only a few lines of assembly. Doing the same thing using DirectX in c++ would take you all day! This is absolutely true, but in something like ShaderToy you can go back to producing complex pixel-bashing effects with a…

> This is an interesting line of argument - in what way, and what could be done to improve the ergonomics?

Due to the enormous complexity of modern CPUs I'm not sure there's anything that could be done. With the 486 and contemporary (and earlier) uarches you could largely expect the CPU to execute exactly what you wrote so understanding the performance impact of any given bit of assembly was pretty straightforward. Then CPUs started adding features like superscalar, speculative, and out-of-order execution, branch prediction, deep pipelines, register renaming, and multi-level caching that massively complicate modeling the performance of any given code.

For example you may need to explicitly clear an architectural register before reusing it for a new calculation to avoid creating a false dependency in the uarch which would prevent the CPU from executing the calculations in parallel. Knowing when this is necessary can be hard and the rules are usually different between different uarches, even within the same uarch family.

Good assembly programmers who are aware of all this complexity can still beat compilers but they certainly can't do that for the scale of code that compilers routinely generate. Thankfully compilers are generally "good enough" these days and assembly only needs to be hand-written for very hot inner loops for performance-critical code or for cryptographic code where the exact performance characteristics of the code could potentially leak information if they're not handled correctly.

Re: Thoughts on Modern C++ and Game Dev

#70

Post by vlovich123 »

deng wrote: post #33

So, the solution to bad debug performance is essentially YAGNI? I'm afraid that isn't a very convincing argument. If your code is several orders of magnitude slower in debug mode, then this is a problem. Simply downplaying this with arguments like "single-step debugging is a last resort" or "just write better tests" won't make this problem vanish. Just like exploding compile times are not solved with "just buy Incred…

I'm curious if this comment stays true once you build debug with -Og since that's an actual optimization level now that ensures the code remains debuggable while still applying a meaningful number of optimizations. Most people turn off all optimizations in debug builds but that's silly for 99% of problems unless you're tracking down a potential compiler bug.
Post reply on HN