Hacker News Reader

Comment by gambiting | Hacker News Reader

I work in videogames - making any change to code takes about 2-4 minutes to compile(huge C++ codebase with a billion templates, it actually takes about 40 minutes from scratch with distributed build, few hours without it), plus second that again for the game to start and test. And god forbid you made any changes to data - then it's about 20-30 minutes to binarize the data packs again and deploy them. Really makes you slow down and think any change through before trying it. The "pray and spray" approach to coding simply doesn't work here.

View on HN

The compile times are part of the reason why scripting languages like Lua are popular in games. In engine code it's fine, but you don't want to wait minutes to see a change while working on higher-level parts of the game.

The data thing though, that sounds like your engine is poorly optimized for development time. There should be a way to work with data without repacking everything.

While I remember those days of C++ development - I never want to go back there. It's surprising people are willing to put up with this shit at this in this day and age. No wonder there's so much crunch time.

We do 0 crunch or overtime as a company policy, but yeah, it does slow down things a bit.

>>It's surprising people are willing to put up with this shit at this in this day and age

All major APIs, the SDKs for PS5/Xbox are all only provided in C++ so it's almost a necessity. Same reason why we all use Windows - the platform tools are only provided for windows.

Even when I mostly do managed languages, I keep getting back to C++, why am I willing to put up with it?

It is the language those managed language runtimes are written on, the main language for GPGPU programming, two major compiler building frameworks, and works out of box in all OS SDKs while providing me a way not to deal with C flaws unless forced by third party libraries.

I could be spending my time creating libraries for other ecosystems, but I have better things to do with time.

I sometimes wonder if these sorts of observations provide some reason to make either embeddedable languages or NOT self-host a compiler for a new language, but continue to write the compiler in C or C++. This is a weak argument compared to self-hosting a language, but might be something to consider in passing.

Indeed, that is why many times a language isn't self hosted.

It wasn't because it was lacking in capabilities, rather the authors decided they would spend resources elsewhere.

Naturally it has the side effect to reinforce the use of the languages that are already being used.

C++ is fine. It's just nobody likes designing and writing lighter weight tests and simulations to keep local dev workflows productive.

For things like AAA games and OS development, I'm not convinced simply picking another language solves the problem. At least not while keeping all the same benefits. C builds faster, sure, but it doesn't have the same feature set.

I'm trying to ! https://youtu.be/fMQvsqTDm3k?t=86

I'm getting 150 ms of iteration time on small cases, 200-300 on average ones

How are you building your code ? Here's my iteration time when working on the main codebase I'm on, https://github.com/ossia/score which is very template-heavy, uses boost, C++20 and a metric ton of header-only libraries: first on some semi-heavy file and then on a simple one https://streamable.com/hfkbzg

I'm actually curious why they bother converting game data at all into binary formats, before production builds. The logic is all there to load the data and you already have the raw data local; I would assume it takes more logic to unpack it and would seem faster to just use the raw data.

The data before packing and the data after unpacking are probably not the same formats.

Some of the packing steps are also probably lossy (eg. Take this super high poly count model, and cut away 99% of the polygons). If you skip that culling step, the game probably won't run.

Yes, that's exactly what it is. The "data" might be 8K textures, as part of the binarization it gets converted into a format that the client can understand, but also follows a "recipe" for the texture set throught the editor(so convert it a 2K texture with a specific colour spec). Same for models etc.

And yes, the client itself usually can't read the raw data, and even if it could there is not enough ram on consoles to load everything as-is. The workstations we use for development all have 128GB of ram just so you can load the map and all models in-editor.

Have you tried ccache now that it has MSVC support?

We use clang for all configurations and all platforms, and we use FastBuild(we also used to pay for Incredibuild but it wasn't actually any faster than FastBuild in our testing).

Reply on news.ycombinator.com