Live data from Hacker News

Modern C++ gamedev: thoughts and misconceptions

vittorioromeo.info

141–150 of 221 posts

Re: Modern C++ gamedev: thoughts and misconceptions

#141
I don’t think this really covers the whole topic, but yeah the Twitter thread is toxic in the exact way most threads are tbh...

I’ve been using C++ for about 15 years now, and also tbh, and dislike just about everything beyond 11-14. The cognitive load reading code has just skyrocketed. The simple basis of the issue was when the meaning of existing syntax elements being “overloaded”. &, &&, [] in my mind. It is not complicated or profound reasoning - simple as now you need to decipher more context to understand what is being expressed. I’ve been materially disappointed to spend 5-10 minutes reading a small bit of unfamiliar code only to learn that what it ultimately expressed was truly trivial. It just makes you feel like c++ has become like the toxic parts of academics/math where everything is expressed in the most complex way possible to establish superiority over others.

The comments about debug ability are true. STL sources/template stacks are absolutely terrible to work with. Luckily with the STL though, what 99%+ of the time, the bug is in your usage, so it doesn’t matter much. To be fair though that is a trade off - I feel like I’m on vacation debugging c# or Python, but that is (almost) an intrinsic benefit of interpreted languages, with the well-known associated costs. Just templates... the cognitive load of having to understand (simply read) and debug code from an abstract definition introduces significant pain in terms of debug ability and general usability.

“C++ is not the STL” - true but c’mon - whatever is built-in mostly defines the stuff that you can be sure is portable, and rely on as a standard practice/resource in large projects. Very few sane people want 5 different implementations of a vector or string from god knows where with god knows what bugs. In the industry for c++, there is serious need for the _option_ to “reinvent the wheel” of standard libs, but it shouldn’t be that this is necessary to achieve baseline performance or usability in common use cases.

I am of the same opinion as at least one other below - simplicity of implementation and readability of language are king in the “real” world. What’s better than the beauty of a meta-programmed, absolute masterpiece of modern C++ and zero-cost abstractions? A program that I can understand in 10 minutes two years after it was written, or better yet that can be understood and debugged by 90% of skill levels instead of 10%.

This conversation could, and does, go on without end. My net-net conclusion so far is that modern C++ has done more harm to itself than good because it is trying to be too much. When the creator of the language can’t even keep up with it enough to call himself an expert, it’s a pretty obvious red flag that things have gone off the rails.

Re: Modern C++ gamedev: thoughts and misconceptions

#142

Earlier quoted context omitted.

Matches my experience as well in the hobby gamedev realm. I can give an anecdote, I’m involved in a “private server” dev community for an old niche MMO from 2003. There exists 3 codebases: first the original code written in a windows-style C++ with heavy use of inheritance, custom collections, Hungarian notation, etc. The second is a collaborative open source version that is written in a naive/basic C++ style (e.g. c…

That's not really giving the full picture of ROSE online! - The official server (arcturus) is awful to work with code-wise. But all the decently big private servers uses it because at one point we only had the binaries of it and it worked out of the box. When the source started to leak too, it was easier to continue forward with that thing. - The "simple version" which I am assuming you refer to is os(i)rose. This wa…

Some other anecdotes:

The official server was stolen due to horrible code-practice (C++-wise and software engineering in general), like having plain SQL-injections when creating characters. Worst! This was one of the reason that made the company (TriggerSoft) behind the game go bankrupt. The game was full of security holes back in 2005. This made the game's economy being broken due to few cheaters, created few horrible roll-backs and such. This drained the player's base from the game.

The "simple C++ server" osrose was also plagued by security issues and technical issues. Up to a point that people preferred to patch the official server with dll-injections + assembly rather than trying to make this "simple C++ server" work.

Re: Modern C++ gamedev: thoughts and misconceptions

#143
post #107
post #97

Earlier quoted context omitted.

Folds are not complicated. They are just not familiar to the intended readers. The changed version is idiomatic in image processing or similar areas that deal with pixels. Being idiomatic makes it familiar to read, and easy to change.

But the wider context here -- and the reason the changed version was presumably written -- is the accusation that folds are overcomplicated. It's under that lens that I am criticizing the changed code.

Not just folds. Also the lambda and the inner loop which is memcpy instead of range3. It’s about every part of the function, including but not limited to the folds.

Re: Modern C++ gamedev: thoughts and misconceptions

#144

Earlier quoted context omitted.

C++ fold expressions, the main C++ feature the article covers, are simple and dumb (at least, enough to use them) but not verbose, and definitely harder to get wrong than a much more verbose for loop.

I love fold expressions, but if you're inside a variadic template, you've long left the realms of "simple and dumb". IMO. I mean, they're only readable to people who have dabbled in variadic templates in their free time. That's how many people on your (future) team?

Or you know, anyone who has used them in their day job writing C++. Just like literally every language feature.

Re: Modern C++ gamedev: thoughts and misconceptions

#145
post #126

Earlier quoted context omitted.

Most people hate const at first (myself included) but once you get used to it, it really does reduces mental load. Not having to glance around is precisely the point, its not a big thing but it does help.

I stopped using it for locals after it increased my mental load. The maintenance cost of const for all local variables is huge during refactor like you're fighting it just to get things done. And in most cases where the type of a variable matters I do have to glance around like when I need to remove a variable or change its type or refactor its dependent variables so const doesn't really for those cases.

If you have to assign to a const variable during a small refactor, then maybe it shouldn't have been const in the first place? I'm struggling to imagine examples where this is a real problem

Re: Modern C++ gamedev: thoughts and misconceptions

#146
post #32

Earlier quoted context omitted.

I would say Java, which I suspect is bound to be a bit of an unpopular opinion here (I expect more startup people than enterprise denizens in HN); but the more I think about it, the more sure I'm that it fits the bill: - Dumb: you bet. The inclusion of lambdas has shaken things a little, but usually Java code is straightforward with little space for "cleverness". The counterpoint to this, of course, would be the meme…

> Fast: also yes. Usually about 2x or 3x the run time of C/C++ code, some times even less. not commenting on the Java part as I believe it's usually faster than that (though not so sure when you see the years of hoops that Minecraft java had to go through to stop being so damn slow all the time...) , but it's kinda frustrating to be fighting for microseconds almost daily and then hear people saying that 2x slower is…

I know this thread is about game development, but not everyone has hard deadlines to churn out frames. The comparison is useful because it separates Java from many other languages that are possibly 10x slower, which make them unsuitable for a huge number of domains where Java can still be useful.

Re: Modern C++ gamedev: thoughts and misconceptions

#147
I stopped reading at "I would like this to happen at runtime".

I got burnt so many times by runtime craziness already that the only thing I want happening at runtime is trivial code running from top to bottom.

But if you enjoy runtime hacks, more power to you! You must be a much better developer than me.

Re: Modern C++ gamedev: thoughts and misconceptions

#148
post #20

Reading the twitter thread he mentioned in the introduction gave me a very bad impression of the author. He started a nonconstructive flamewar, called all constructive criticism misguided, and thereby shit on half a dozen video game development VETERANS. The arguments by Omar in particular are worth reading much more than this article. Also, all his code examples are bad. No one would build a texture atlas the way he…

Bloomberg has a higher hiring bar than most, if not, all game studios. I like how you fallback on seniority while the video game industry isn't exactly known for top tier talent.

Re: Modern C++ gamedev: thoughts and misconceptions

#149

Earlier quoted context omitted.

C++ fold expressions, the main C++ feature the article covers, are simple and dumb (at least, enough to use them) but not verbose, and definitely harder to get wrong than a much more verbose for loop.

I love fold expressions, but if you're inside a variadic template, you've long left the realms of "simple and dumb". IMO. I mean, they're only readable to people who have dabbled in variadic templates in their free time. That's how many people on your (future) team?

It's funny how defensive mediocre engineers get.

Re: Modern C++ gamedev: thoughts and misconceptions

#150
post #118

Earlier quoted context omitted.

Your view sounds very jaded to me. Maybe Rust is liked more by C programmers because they prefer its approach, rather than C++'s? Calling it a marketing ploy seems without merit to me.

I'm a C++ developer who occasionally writes Rust. The experience of writing new code in one is very, very similar to the experience of writing new code in the other, right down to the compile times. The lifetime analysis in Rust is nice and pretty far ahead of what static analyzers can do in C++, but Rust Generics are a pretty weak approximation to Templates. Rust has better Browser integration, C++ has Qt. One imagi…

I agree with most of what you're saying here except for the point on generics versus templates. I wouldn't say generics are an approximation of templates at all, templates are something in between generic programming and macros and that leads to them being hazardous, slow, and generally speaking unergonomic.

Rust's generics allow for some seriously powerful abstractions to be built in a very clean and readable way, although there can be friction with stuff that would be simple with templates in C++ and quite verbose in Rust.

Maybe concepts will change that.

Post reply on HN