Live data from Hacker News

Modern C++ gamedev: thoughts and misconceptions

vittorioromeo.info

211–220 of 221 posts

Re: Modern C++ gamedev: thoughts and misconceptions

#211
post #207

Earlier quoted context omitted.

But that is exactly what you do when going after performance in game development, even in C and C++, and it isn't less ugly by using those languages instead of Java. There is an EA available for Valhalla and there is now the roadmap to incrementally bring such features into the platform. Java 14 has a new native memory support as experimental and it might reach stable already by 15. https://jdk.java.net/valhalla/ htt…

In C and C++ you don't need to make int-arrays. You can group data that is accessed together in structs and keep arrays of these structs. With regards to performance, there must be some fine art in splitting structs into smaller structs, and keep them as parallel arrays, but there is also a limit to it. At some point you will need too many pointers to point at the same position in all these arrays. I've never cared t…

Just to add something that I forgot to mention on my previous comment that I think it is worthwhile mentioning.

Naturally at some level you will have a class full of native methods as FFI to OS APIs or libraries written in C or C++.

From that point of view, I consider Java still a better option as game engine scripting language as Python/Lua/JavaScript, because you get strong typing, there is still dynamic loading, a good set of AOT/JIT/GC infrastructure and more control over memory layout than those languages allow for.

Naturally that is a matter of personal taste.

Re: Modern C++ gamedev: thoughts and misconceptions

#212

Earlier quoted context omitted.

Because there is yet no proper for loop for argument packs or tuple-like objects, fold expressions over the comma operators are unfortunately the next best thing. Edit: also the default comma operator discards its lhs, it is pretty much always used for its side effects.

Yeah, I figured it might not be currently possible. I was thinking about something like Scala HList[1], which provides a map/flatMap (which enables for-loop) method for tuples (among other functionality). [1] https://github.com/milessabin/shapeless/wiki/Feature-overvie...

boost.fusion, boost.hana provide similar functionality (i.e. arbitrary runtime or compile time transformations over tuple-like objects) but they are relatively large dependencies and it is not worth it just for a tuple for-each.

Re: Modern C++ gamedev: thoughts and misconceptions

#213
post #16

Earlier quoted context omitted.

I just fixed a segfault the other day because one of our new hires fresh from college is eager on using modern c++ and didn't put parentheses at the correct place in his fold expression.

It sounds like an interesting bug, can you elaborate? On the surface it sounds like your new hire merely used fold expressions to call functions and operators that were already treacherous on their own.

Sorry, I can't look it up right now, but trying to reconstruct it in my head it must've been something like

    y = (f(x1), f(x2), f(x3))
vs

    y = f(x1, x2, x3)
Not entirely sure anymore though. But it was something about causing side effects but throwing away return values with the ,-operator and involved function calls, I think

Re: Modern C++ gamedev: thoughts and misconceptions

#214
post #183

Earlier quoted context omitted.

If you're doing foo a lot, you make a foo() function. That doesn't mean you have to create a pure virtual FoolikeOperation class and FoolikeOperationFactory, a concrete ActualFooFactory and an ActualFooOperation class.

Suppose you do foo a lot. And sometimes you need to do either foo or bar inside of baz. You can pass a flag to baz, to choose either foo or bar. Now you have a closed set of possibilities. If you want to extend the functionality e.g with a plug-in, or got any other reason you want to avoid committing to the choice, then you either need 1. first class functions, so that you can pass in foo or bar or whatever. or if yo…

Oh, for sure, you can still find yourself in a situation where that kind of heavyweight design pattern is appropriate. And if you do, then by all means uses it. I think they're just saying don't jump straight to the top of the tower of abstraction when the first step or two up the staircase will do what you want.

Re: Modern C++ gamedev: thoughts and misconceptions

#215
post #151

I don't understand why does he show loop-based version using 2 for loops instead of using just one. I usually work in higher-level programming languages, but can't believe that cache hits or something else makes it faster than finding sum and maximum both while going through all images only once. And having just one loop makes it simpler too.

Choosing C++ over C means his programming abilities aren't very good.

The fact that you seem to think C is blanket superior to C++ means that your programming abilities aren't very good. There are many reasons to choose C++ over C, especially if those two are your only options.

Re: Modern C++ gamedev: thoughts and misconceptions

#216
post #104

His personal blog post has eight obtrusive ads plus a Donate button (to an engineer in finance in London.) I get the sense the author's deliberately stirring controversy.

His Twitter profile pic isn't helping either.

Maybe he changed it, but.. what is wrong with his twitter profile pic? It looks pretty ordinary to me. Am I missing something?

Re: Modern C++ gamedev: thoughts and misconceptions

#217

I would personally use for loop without size_t. It is short and simple and works as intended, anyone can understand it.

Do you mean with decltype(std::declval ().width) as the article suggests? Or with an ad-hoc typedef, e.g. Image::size_type? Or with a fixed type that should work correctly? This use of auto is particularly valuable.

Honestly I would just use auto. I favor heavy use of auto actually, if you got a modern IDE auto is a really great feature.

Re: Modern C++ gamedev: thoughts and misconceptions

#218
post #87

Earlier quoted context omitted.

So, naive code attracts naive programmers? I'm not sure this is the ringing endorsement you take it to be. I should also add that Hungarian notation is the prototypical example of dumb, verbose code, that wants to make individual lines easier to understand by dragging type information into every single variable name.

> I should also add that Hungarian notation is the prototypical example of dumb, verbose code If used wrongly. Joel Spolsky wrote a whole post on it[0], but the TL;DR is that you should use the notation to differentiate between variables of the same type. For example, you might have world coordinates and object coordinates in a game script. Correctly used Hungarian notation would denote them, for example, with `wPosX…

For dynamic languages sure. For strongly typed languages it's better to just use the type system to prevent those kind of things. C++ doesn't have great support here (lots of boilerplate needed) & usually people reach for Boost Units or Boost strong types but it's not that hard (https://www.fluentcpp.com/2016/12/08/strong-types-for-strong...). Mozilla is also exploring this specifically for coordinate spaces & whatnot too (https://research.mozilla.org/2014/06/23/static-checking-of-u...).

Re: Modern C++ gamedev: thoughts and misconceptions

#219

Earlier quoted context omitted.

His Twitter profile pic isn't helping either.

Maybe he changed it, but.. what is wrong with his twitter profile pic? It looks pretty ordinary to me. Am I missing something?

Sorry, meant the banner pic on his profile page, at top.

Re: Modern C++ gamedev: thoughts and misconceptions

#220
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…

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.

Nothing in templates is 'simple and dumb': it may look so but it isn't: try to write some, you'll inevitably makes some mistake and the errors are really awful!
Post reply on HN