Modern C++ gamedev: thoughts and misconceptions • Hacker News Board

Re: Modern C++ gamedev: thoughts and misconceptions

#61

Post by danielscrubs » Sat, May 16, 2020, 2:44 PM UTC

Koshkin wrote: post #43

gordaco wrote: 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…

Indeed, despite all criticisms Java as a technology is one of the best things that has happened to the software industry, next to Linux.

Java won because of its humungous and stable standard library with the full backing of Sun (and Sun was huge presence at the time). It was quite a joy to have pretty much all the functions you could ever need (not really but it felt like it at least) at your fingertips without having to do manual dependency management.

As a technology it really didn't have much to give. Object Pascal was born in 1986, Ada in 1980 with language support for design by contract, JIT with Lisp in 1960 and Java came in 1995.

Re: Modern C++ gamedev: thoughts and misconceptions

#62

Post by danielscrubs » Sat, May 16, 2020, 2:48 PM UTC

Koshkin wrote: post #59

vbezhenar wrote: post #42

Earlier quoted context omitted.

I agree wholeheartedly. I spent so much time needlessly trying to be smart.

Yet, it is important not to abandon the hope to become smarter. Learning new tricks never gets old.

I think it's best trying to be smart in areas that will stand the test of time, not the latest lasagna architecture or library hype.

Re: Modern C++ gamedev: thoughts and misconceptions

#63

Post by leni536 » Sat, May 16, 2020, 2:50 PM UTC

elbows wrote: post #33

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

It's more of an issue with things like std::transform or std::copy_if. Ergonomically, it's nice if these kinds of functions either allocate and return a new container, or return an iterator that yields the elements of the result. But the C++ versions of these take the result location as an argument. It makes chaining them together a hassle because you have to create all the intermediate containers explicitly. I think…

Ranges will help with some of the composability issues of standard library algorithms.

[1] https://en.cppreference.com/w/cpp/ranges

Re: Modern C++ gamedev: thoughts and misconceptions

#64

Post by jfkebwjsbx » Sat, May 16, 2020, 2:52 PM UTC

hhmc wrote: post #37

MauranKilom wrote: post #24

Earlier quoted context omitted.

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?

> 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? This line of reasoning is vacously true for any syntax and semantics though. Move semantics and rvalue reference are only readable to people that have taken the time to understand them -- they're undoubtably useful though.

Move semantics and rvalue references are too complex and error prone to be useful in general code.

It is best to use them only in performance sensitive places and containers.

Re: Modern C++ gamedev: thoughts and misconceptions

#65

Post by xfs » Sat, May 16, 2020, 2:52 PM UTC

hhmc wrote: post #40

sharpneli wrote: post #34

There was a good comparison about those floating around: https://imgur.com/a/u1N4Fpy For me the code on the right is far more readable and easier to understand.

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` is so common that there is no ambiguity about what it does.

The idx lambda is probably a distracting abstraction which requires the reader to think of it in a different context than the immediate what pixel goes to where. Again, the pixel moving pattern in the right is so common it's familiar to most people working in similar areas, and in terms of error-prone both are not better than the other.

Re: Modern C++ gamedev: thoughts and misconceptions

#66

Post by Koshkin » Sat, May 16, 2020, 2:52 PM UTC

leni536 wrote: post #51

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…

Variadic templates are essential for simple, argument forwarding template functions. std::vector::emplace_back is a very simple example, this kind of use comes up now and then during work. [1] https://en.cppreference.com/w/cpp/container/vector/emplace_b... edit: This also shows that you don't have to be able to write variadic templates to reap the benefits of it. You can enjoy the benefits while using a library that…

The key to understanding techniques based on templates is to realize that C++ templates are just another programming language that (a) is functional, (b) is interpreted at compile time, and (c) where values are C++ types.

Re: Modern C++ gamedev: thoughts and misconceptions

#67

Post by numlock86 » Sat, May 16, 2020, 2:54 PM UTC

throwaway8941 wrote: post #41

lazypenguin wrote: post #15

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…

Could you please share the name of the game?

Could be Lineage 2, at least I am aware of multiple private server implementations there. And it came out in 2003. But then again it's far from being a niche game.

Re: Modern C++ gamedev: thoughts and misconceptions

#68

Post by gugagore » Sat, May 16, 2020, 2:54 PM UTC

fsloth wrote: post #48

microtherion wrote: post #26

Earlier quoted context omitted.

> Make your code simple, dumb and verbose all the time This is a frequently encountered argument, and sure, if you look at any single line , it looks very obvious what it does. But I would argue that verbosity and lack of abstraction has severe drawbacks for a programmer's ability to understand the overall codebase , and it is disastrous for long term maintainability. You start out with 20 identical pieces of boilerp…

I think you confuse simplicity with overt verbosity. There is no reason simple code can't have higher-level constructs. The interface to them is just likely very domain specific, and you don't start with them. But after you notice you are copying the same sort of code to a third place, you usually notice a pattern, extract that pattern (with no abstract frills attached) to a unique implementation that can be used eve…

"no abstract frills attached" I can't tell what you think a frill is, but I can't square that statement with the rest of your post, and with the OP. Higher-level constructs might require language features like template metaprogramming, or a level of indirection. There are a few ways in which you can have "the same sort of code".

Re: Modern C++ gamedev: thoughts and misconceptions

#69

Post by SloopJon » Sat, May 16, 2020, 2:55 PM UTC

KallDrexx wrote: post #39

badsectoracula wrote: post #31

Earlier quoted context omitted.

I've worked on a bunch of engines, both big AAA and small indie scaled ones and i agree with you. It is actually from this experience that i have a hard dislike for C++'s "auto" outside of cases where you can't do otherwise - it makes the code you didn't write hard to understand exactly what is going on (and sometimes error prone). Sure IDEs can show you the type if you mouse over (at least some of them), but if the…

I wonder how wide spread dislike of "auto" is in c++ (I've seen that a few places) when the equivalent type inference has become fairly standard and preferred in other languages like C#, Rust, Go, etc...

There is definitely disagreement in C# as to the proper usage of var.

Re: Modern C++ gamedev: thoughts and misconceptions

#70

Post by humanrebar » Sat, May 16, 2020, 2:56 PM UTC

PezzaDev wrote: post #36

microtherion wrote: post #26

Earlier quoted context omitted.

> Make your code simple, dumb and verbose all the time This is a frequently encountered argument, and sure, if you look at any single line , it looks very obvious what it does. But I would argue that verbosity and lack of abstraction has severe drawbacks for a programmer's ability to understand the overall codebase , and it is disastrous for long term maintainability. You start out with 20 identical pieces of boilerp…

No coding approach will ever solve an issue caused by a lack of discipline.

Broadly, that's not true. The correctness benefits of type safety could also be provided by discipline alone.