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

Modern C++ gamedev: thoughts and misconceptions

vittorioromeo.info

Post reply on HN
Print view View original

191–200 of 221 posts

Re: Modern C++ gamedev: thoughts and misconceptions

#191

Post by tonetheman »

PezzaDev wrote: post #6

After years of experience writing code for games, I find that the dumbest code is the best code. It doesn't matter if it's C# or C++, whenever I've used something like reactive extensions or template metaprogramming, it has been a terrible mistake every single time. Make your code simple, dumb and verbose all the time. Avoid using any complex abstractions or any overcomplicated syntactic sugar and you'll have a codeb…

This advice is true across all areas of programming.

I always say it as "write code that you could debug at 2:00 am drunk."

Be simple, do not be clever and be clear.

Re: Modern C++ gamedev: thoughts and misconceptions

#192

Post by MauranKilom »

entha_saava wrote: post #180
MauranKilom wrote: post #28

Earlier quoted context omitted.

According to https://en.cppreference.com/w/cpp/algorithm/stable_sort : > This function attempts to allocate a temporary buffer equal in size to the sequence to be sorted. If the allocation fails, the less efficient algorithm is chosen. Or is this not what you consider a "functional construct"?

I know some basic C++ and STL. Is there anything like streams in C++. I mean things would be as easy as vec.stream().map(lambda).fold(T::operator+), so it wouldn't require any more allocations than those done by copy constructors.

The upcoming ranges library will provide exactly this! It uses | for composing operations.

See e.g. here: https://github.com/ericniebler/range-v3/tree/master/example

Re: Modern C++ gamedev: thoughts and misconceptions

#193

Post by MauranKilom »

jfkebwjsbx wrote: post #182
neutronicus wrote: post #179

Earlier quoted context omitted.

Any time you want to pass a named unique_ptr across an API boundary, you'll need to std::move it

...which you should avoid as much as possible do. Passing std types across API boundaries is a code smell.

What? That's one of the primary motivations!

"I have created an object and will pass its unique ownership to you." -> std::unique_ptr

"This routine needs a function that takes two ints and returns a float (without putting all my code into headers)." -> std::function.

Can you elaborate in what circumstance you should not pass std::types across API boundaries?

Re: Modern C++ gamedev: thoughts and misconceptions

#194

Post by pacificat0r »

He got upset when ppl with 15+ years of experience, working at dice or directors of tech at Activision pointed out that modern c++ is over complicated and they've been in that phase of liking abstractions but moved on. Funny he blanked the names of those dudes and some other milder replies.

Then he wrote a blog post on it.

Re: Modern C++ gamedev: thoughts and misconceptions

#195

Post by ironmagma »

schaefer wrote: post #79
deepaksurti wrote: post #23

Earlier quoted context omitted.

> Not always, though. See every bug and exploit with C arrays ... That can also be perceived as a a flaw of the language design in that it does not allow one to write dumb, safe and fast code. Which are such languages in existence today? edit: fixed typos

> Which are such languages in existence today? Zig will be there soon.

Zig first needs to have code samples in the documentation that compile.

Re: Modern C++ gamedev: thoughts and misconceptions

#196

Post by dkersten »

winterismute wrote: post #7

While I do agree with various points in the article, it is kind of funny that the author works in the financial sector and has, apparently, no experience in working on big games devloped in long stretches by hundreds of people at the same time: for example, this article about "C++ and gamedev" shows examples from his own Quake VR codebase, an insanely cool but clearly one-man project started and brought forward by he…

So? Doesn't mean people have to be toxic about a code snippet he posted because he found it interesting. Personally, I'm glad he posted about fold expressions, because I'm not up to date on C++17 yet and I found it quite interesting. He didn't deserve the replies he got and I feel that the only reason this article is about gamedev at all is because the gamedev community were the ones who jumped on him (and probably only because he mentioned his Quake VR project).

Re: Modern C++ gamedev: thoughts and misconceptions

#197

Post by dkersten »

xfs wrote: post #65
hhmc wrote: post #40

Earlier quoted context omitted.

The code on the right feels in mildly bad faith to me. - consts are dropped - variable definitions are merged onto multiple lines - usefully named constants like `nPixels`, `nBytes` are elided - the `idx` lambda is inlined The net effect, for an initial skim, is that the code on the right looks terser and simpler. But in reality many of the "short cuts" hurt the long term quality of the code.

I love C++17 fold expression, but... Local consts are not particularly useful, especially for things like ints. Compilers know it's const, and a reader doesn't need to worry about it in a local scope. width, height usually come in pairs, so putting them on the same line is usual. nPixels and nBytes are not used more than once so they are not useful abstractions, and the pattern of `width * height * bytes_per_pixel` i…

> Compilers know it's const

I can still assign to it. Sure, you can argue that if the code is complex enough that you might accidentally do that without it being obvious, then the code should be simplified or split up, but that's besides the point. If its const, the compiler will complain, if its not, it will silently let me. Nobody can write ideally-factored code all of the time and following good consistent practices helps. Also, I hear arguments like that all the time, but so much of actual real-world shipped code breaks these "rules", so I'd rather be pragmatic and choose a style that improves otherwise imperfect code.

Its also as much a hint to future me that the variable is intended to not be modified.

Re: Modern C++ gamedev: thoughts and misconceptions

#198

Post by dkersten »

s9w wrote: post #2

I agree with the author on many things - parameter packs however.. I've looked at them several times. Even if you get a grasp on their syntax, I've almost never been in a situation where they could be used. As he correctly observes it's a compile time thing. > In my particular scenario, all the texture file paths are hardcoded That feels like a very unique case. Usually data is given in a vector or something and then…

> Even if you get a grasp on their syntax, I've almost never been in a situation where they could be used.

Parameter packs can make some ugly code substantially simpler, IMHO. For example, I contributed some changes to the Godot C++ bindings a couple of years ago that made a number of super common functions variadic instead of having to create and pass in collections (eg debug printing, specifying argument types when registering signals, stuff like that). While not a strictly necessary change, it makes the resulting code easier to read. Parameter packs allow this.

Re: Modern C++ gamedev: thoughts and misconceptions

#199

Post by bionicbeagle »

1tCKV3QfIo wrote: post #148
eska wrote: 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.

It takes a special kind of arrogance to assume that you know better than the people who've been successful in a completely unrelated field.

It reminds me of the arrogance displayed in the Twitter thread, which is a shame. I think like someone said, experience is valued only by those who have it.

I've been there too though, I was that arrogant young programmer once thinking all these old-timers weren't a match for my technical skills. It usually passes.

Re: Modern C++ gamedev: thoughts and misconceptions

#200

Post by badsectoracula »

klibertp wrote: post #96
badsectoracula wrote: post #80

Earlier quoted context omitted.

Eh, no, i'm not exaggerating. I really have a hard time following the flow of the posted code. I can get a rough idea of what it is doing by ignoring most of the Modern C++-isms, but i still can't tell you with confidence that i know exactly what is going to happen (...and i'm not asking for an explanation, btw, that is besides the point :-P). I mean, sure, if i take that code and run it through a debugger - perhaps…

Well, readability is like this. It's not a property of the code alone, it's an emergent property based on both the code and your knowledge as a reader. It's very, very subjective, which our little disagreement here proves. Basically, the same code using the same feature can be both insurmountable wall of text and an elegant, readable solution - depending on your background, current knowledge, and personal taste (amon…

It isn't just about knowledge, but also about how much knowledge you'd need to keep in your head just to read something - the least the code requires from you before you even start reading the code, the more you can focus on understanding the code itself. And even when you know about the features shown, it still is hard to follow the flow. I mean, i do know about lambdas in C++ and have used them a lot, but i can still find it harder to follow code that uses them extensively with the flow jumping around as, e.g., calls to other functions call back to local lambdas.
Post reply on HN