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

Re: Modern C++ gamedev: thoughts and misconceptions

#81

Post by neutronicus » Sat, May 16, 2020, 3:30 PM UTC

eska wrote: post #74

krapp wrote: post #18

Earlier quoted context omitted.

>I find that the dumbest code is the best code Not always, though. See every bug and exploit with C arrays or pointers that exists because C devs think even minimal attempts at safety are too complicated or slow, or old-style PHP code that builds SQL queries out of printf strings directly from POST values, or probably countless other examples in other languages. C++ code that uses raw pointers instead of references o…

This sounds unnecessarily dismissive of C programmers. I see a lot of C programmers that shit on C++ but are intrigued by Rust, e.g. Linux kernel developers allowing modules to be written in Rust.

Yes, Rust is making a smart marketing decision by capitalizing on C programmers' antipathy towards C++ (and everyone else's).

I don't know that this is, ipso facto, evidence of anything about C programmers other than that they really hate C++, though.

Re: Modern C++ gamedev: thoughts and misconceptions

#82

Post by jbverschoor » Sat, May 16, 2020, 3:32 PM UTC

gordaco wrote: post #32

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

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…

Cleverness in this case means:

- Too many jumps in code logic instead of serial logic

- Premature optimization 1: messy code (using lots of unclear variables etc), this is common within calculations, and games have quite some of those.

- Premature optimization 2: failing to properly architect

- Single-character variables. Java IDEs default to fullvars

- Bad function/method names

- Not expressing what you mean (for i= vs foreach)

- Too many abstraction layers / IoC

- Too many sideeffects / complex code (interwoven code)

- Callback hell

Nr 1 is important.. You need to be able to "follow the code". If that requires you to create a DSL in order to code something async in a serial way, then by all means do so.

For example with: network (duh.), but also in games: character dialogs, animations etc. etc.

Re: Modern C++ gamedev: thoughts and misconceptions

#83

Post by neutronicus » Sat, May 16, 2020, 3:32 PM UTC

danielscrubs wrote: post #61

Koshkin wrote: post #43

Earlier quoted context omitted.

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 wit…

They did the legwork to figure out browser Applets as well.

Re: Modern C++ gamedev: thoughts and misconceptions

#84

Post by Jasper_ » Sat, May 16, 2020, 3:33 PM UTC

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…

Yeah, the weird thing is that this is not an atlas packer! It's a very crude long texture with arbitrary bounds, and most GPUs have a maximum texture dimensions, so given enough particles this would have broke. Even a simple skyline algorithm to pack rectangles would have worked far better and it's hard to see how to make that into modern C++ like the author shows.

Re: Modern C++ gamedev: thoughts and misconceptions

#85

Post by badsectoracula » Sat, May 16, 2020, 3:34 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...

Perhaps the people who dislike auto in C++ would also dislike the equivalent feature in other languages but they just happen to not work in them?

I know i do not use any of the languages you mention, for example - and if i did, i'd explicitly write any type names.

Re: Modern C++ gamedev: thoughts and misconceptions

#86

Post by asveikau » Sat, May 16, 2020, 3:35 PM UTC

MereInterest wrote: post #71

Koshkin wrote: post #52

Earlier quoted context omitted.

Traditionally C++ code is often considered harder to read than code in these other languages, and the "excessive" use of 'auto' does not make understanding code easier. Still, according to my observations the split in opinions on this is about 50/50; mine is that the use of 'auto' improves the "genericity" of code (on par with the use of templates) and its amenability to refactoring with less chance to make a mistake…

I'd also say that using auto makes your code easier to read, especially when you are the user of generic code. Looping through a vector where you need to keep track of the iterator, for example. for(auto iter = vec.begin(); iter!=vec.end(); iter++) for(std::vector ::iterator iter = vec.begin(); iter!=vec.end(); iter++)

These days there is also:

    for (auto i : vec)

Re: Modern C++ gamedev: thoughts and misconceptions

#87

Post by Sebb767 » Sat, May 16, 2020, 3:36 PM UTC

microtherion wrote: post #27

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…

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` and `pPosX`. Even though they're both int (or float), you can easily see that you shouldn't assign one to the other.

Using them to notate types, however, as in `iPosX`, is completely useless. I fully agree with that.

[0] https://www.joelonsoftware.com/2005/05/11/making-wrong-code-...

Re: Modern C++ gamedev: thoughts and misconceptions

#88

Post by badsectoracula » Sat, May 16, 2020, 3:36 PM UTC

BubRoss wrote: post #76

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…

An all or nothing approach to auto ends up being silly for reasons of clarity and specificity in types. Auto with compound types makes programs easier to read and write, especially if an IDE is there to expand complex type information. If the type is small, basic, intrinsic, etc. then auto can be a hindrance.

> An all or nothing approach to auto ends up being silly

I already wrote that there are some cases where auto is necessary (usually when used with more recent C++ features).

> especially if an IDE is there to expand complex type information

And i also already wrote that this information is not only often cumbersome to obtain but also such an IDE is often not available - e.g. in a web-based code review tool which also happens to be an environment where you want the code to be most understandable.

Re: Modern C++ gamedev: thoughts and misconceptions

#89

Post by badsectoracula » Sat, May 16, 2020, 3:45 PM UTC

vbezhenar wrote: post #49

KallDrexx wrote: post #39

Earlier quoted context omitted.

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...

With Java I've seen coding standards that you can use `var` only when type is obvious from declaration. For example: var person = new Person(); var car = selectCarById(carId); // Car if type is not obvious, it should be explicitly declared.

I'd avoid the second example since you'd need to know the return type of selectCarById to know what the actual type that will be returned is (the name doesn't help, it might return something like, say, a "ref" or something like that - e.g. in a game engine i worked on a couple of years ago all resource pointers were passed around encapsulated in a special template that handled automatic resource management - methods would still be called something like "GetMesh" but what you'd get wouldn't be a "Mesh" but a "TResRef", however since in other places in the engine you'd work with "raw" Mesh types, unless you knew what GetMesh returned - which could be the case for, e.g., some programmer that normally worked with at a completely different subsystem with its own rules - you'd might expect a "auto mesh = foo->GetMesh()" to be a "Mesh" but instead it is "TResRef").

Re: Modern C++ gamedev: thoughts and misconceptions

#90

Post by tomnj » Sat, May 16, 2020, 3:47 PM UTC

I’m often disappointed by how disrespectful people can be in programming discussions. It’s one thing to discuss tradeoffs but ridiculing peoples’ choices or speaking in absolutes is not helpful. There’s no One True Way to program.