Thoughts on Modern C++ and Game Dev • Hacker News Board

Re: Thoughts on Modern C++ and Game Dev

#31

Post by pferde » Fri, Jan 04, 2019, 11:57 AM UTC

de_watcher wrote: post #22

jayd16 wrote: post #2

I don't want to weigh in on the rest of the content but the characterization of the game industry is pretty accurate in my experience. I would expand more on the first bullet point of why game devs don't test. Tests are anti-agile and game development is extremely agile. Usually you don't know what kind of game you're making until you're done.

A sufficiently big game in an established genre with in-house engine and expansions has several levels of automatic tests.

In my experience, such games only have manual testing, done by the people who bought the game.

Re: Thoughts on Modern C++ and Game Dev

#32

Post by exDM69 » Fri, Jan 04, 2019, 12:00 PM UTC

CoolGuySteve wrote: post #18

vardump wrote: post #4

Earlier quoted context omitted.

Heavier things, like graphics processing were typically written in assembler. Or sound mixing. Some things like texture mapping you could only write in assembler, because you'd need to use x86 lower/higher half of word (like AL and AH registers) due to register pressure. Spilling to stack could have caused 50%+ slowdown. 486 era you needed assembler to work around quirks like AGI stalls. On Pentium the reason for ass…

Last time I used SSE intrinsics, which was GCC 4.9 I think, I had a lot of trouble with register usage. It looked like it was compiling down to use only one SSE register for everything instead of parralelizing across them. I tried the same algorithm in godbolt with some clang versions and it was slightly better, using two or three registers, but not by much. So I had to break it into inline assembly. I wonder if GCC…

> I wonder if GCC has improved since then.

Yes, it has. I've written a lot of SIMD code and spent a good amount of time reading the compiler assembly output and there has been huge improvement over the last decade.

GCC register allocation wasn't great, then it got better with x86 SSE but still sucked at ARM NEON, and now it seems to be decent with both.

Clang was better at SIMD code before GCC was. It was equally good with SSE and NEON.

In my experience, compilers are much better than humans at instruction scheduling. Especially when using portable vector extensions, you don't have to write the same code twice and then tweak the scheduling for every architecture separately.

Re: Thoughts on Modern C++ and Game Dev

#33

Post by deng » Fri, Jan 04, 2019, 12:11 PM UTC

So, the solution to bad debug performance is essentially YAGNI? I'm afraid that isn't a very convincing argument. If your code is several orders of magnitude slower in debug mode, then this is a problem. Simply downplaying this with arguments like "single-step debugging is a last resort" or "just write better tests" won't make this problem vanish. Just like exploding compile times are not solved with "just buy Incredibuild".

But his argument fits well with C++'s history of finding exceedingly complex solutions for simple problems. Want to have efficient matrix calculation? Well, who needs native support for matrices when you can do the same with expression templates and static polymorphism/CRTP (see: Eigen library).

The last section of the article says you either do nothing or you get involved. I'm afraid it is missing the obvious third option: switch to another language which actually supports your use case.

Re: Thoughts on Modern C++ and Game Dev

#34

Post by shmerl » Fri, Jan 04, 2019, 12:27 PM UTC

Game developers should start using more Rust.

Re: Thoughts on Modern C++ and Game Dev

#35

Post by cheez » Fri, Jan 04, 2019, 1:06 PM UTC

deng wrote: post #33

So, the solution to bad debug performance is essentially YAGNI? I'm afraid that isn't a very convincing argument. If your code is several orders of magnitude slower in debug mode, then this is a problem. Simply downplaying this with arguments like "single-step debugging is a last resort" or "just write better tests" won't make this problem vanish. Just like exploding compile times are not solved with "just buy Incred…

For what it's worth, I only use a debugger when I have a crash.

Re: Thoughts on Modern C++ and Game Dev

#36

Post by Jyaif » Fri, Jan 04, 2019, 1:16 PM UTC

arka2147483647 wrote: post #6

>Epilogue (... snip ...) > 1. Do nothing (...) You can deal with that by imposing rules on what is and isn’t allowed in your codebase, (...) This is what everybody is already doing in gamedev > 2. Get involved (...) C++ committee participation is open to everyone. (...) Most game dev studios are Small or Mediums sized companies, and don't really have the time to waste in Committee meatings...

> Most game dev studios are Small or Mediums sized companies, and don't really have the time to waste in Committee meatings..

Irrelevant. What counts is where the C++ game devs are, and it's in the big companies. And participating in the design of a language is not a waste of time...

Re: Thoughts on Modern C++ and Game Dev

#37

Post by youdontknowtho » Fri, Jan 04, 2019, 1:27 PM UTC

Whenever the response to a twitter argument is "get involved and make the change you want to see happen" you can expect absolutely nothing to change.

Part of this is just people complaining on a platform that over values short pithy complaints.

Re: Thoughts on Modern C++ and Game Dev

#38

Post by slezyr » Fri, Jan 04, 2019, 1:28 PM UTC

richardjdare wrote: post #23

pulsarpietro wrote: post #7

Earlier quoted context omitted.

I must have been a bloody hard and interesting work, back then.

Back then assembly language was much more ergonomic than it is now, and the machines were simpler. Many of my favourite games in the 80s were made by teenagers programming in their bedrooms. Check out this 68000 assembly tutorial video from Scoopex, the Amiga demo scene group: https://youtu.be/bqT1jsPyUGw He gets a simple graphical effect going on the Amiga in only a few lines of assembly. Doing the same thing using…

You should use SDL for this and not DirectX. You don't need complex API for GPU to paint line if you concerned about complexity.

Re: Thoughts on Modern C++ and Game Dev

#39

Post by pjmlp » Fri, Jan 04, 2019, 1:29 PM UTC

CoolGuySteve wrote: post #26

pjmlp wrote: post #25

Earlier quoted context omitted.

Yes, given the graphical tooling for multi-core, GPGPU, data visualization, edit-and-continue, mixing Assembly with code (even on .NET), interaction with GUI components on WPF/UWP apps,...

That kind of gets to the heart of what I’m saying. These graphical tools are great as long as they do what you need. But they are less composable and customizable than an expression parser. Like in the article he mentions not being able to see custom data types, but my .gdbinit has a few pretty printers in it for exactly that purpose. And when you do get something customized in MSVC like a specific PGO build or somet…

VS supports displaying custom types.

Regarding gdb, during the mid-90's I got by calling it from XEmacs, until I discovered DDD.

I got spoiled with Borland debuggers, typing n, s, l, p all the time and drawing structures on paper gets tiring after a while.

Re: Thoughts on Modern C++ and Game Dev

#40

Post by rafaelvasco » Fri, Jan 04, 2019, 1:32 PM UTC

jayd16 wrote: post #2

I don't want to weigh in on the rest of the content but the characterization of the game industry is pretty accurate in my experience. I would expand more on the first bullet point of why game devs don't test. Tests are anti-agile and game development is extremely agile. Usually you don't know what kind of game you're making until you're done.

I mostly. Agree. Tests can be useful in some specific games, specific cases, but in general they're much harder to do in gamedev compared to other areas. Maybe one case for gamedev would be to test the calculations of character damage in a RPG based on several factors. But that is an isolated case.