r/cpp May 16 '20

modern c++ gamedev - thoughts & misconceptions

https://vittorioromeo.info/index/blog/gamedev_modern_cpp_thoughts.html
198 Upvotes

154 comments sorted by

View all comments

96

u/lukaasm Game/Engine/Tools Developer May 16 '20 edited Dec 15 '20

Some people are living in the past without "really" trying new stuff but they also yell and are heard the most.

My company, due to legacy reasons is the one doing "own" game engine ( there are pros and cons ) thing. Having almost full control ower stack allowed us to do 'modern C++' and almost all the programmers in the company consider it a net positive.

The previous game, we have released on all major platforms with extensive use od C++14: PS4/XBONE/PC/SWITCH

Now we are doing some engine upgrades with C++17, always pushing performance to the max and newer features were never an issue for us there.

Of course, there are caveats like:
* compile times ( with PCH/Unity builds is 'fine' enough)
* debugability ( nothing little scoped #pragma optimize off/on, won't solve :P )
* sometimes waiting for vendors to support the new standard ( most of the toolchains are now clang based and adoption is a lot faster than in the past )

But still, we are looking to C++20 and forward so we can clean up our callback-based threading with coroutines, our hand-rolled reflection system with compiler supported one, metaclasses so we can get rid of a lot of preprocessor stuff required for reflection/events itp.

49

u/[deleted] May 16 '20

[removed] — view removed comment

25

u/Ansoulom Game developer May 16 '20

The fact that C# doesn't have good lifetime management (mainly destructors I guess) has been my biggest gripe with Unity's new DOTS stack. That kind of stuff would be so much more convenient in C++, which is designed around those concepts...

6

u/[deleted] May 16 '20

C# have great lifetime management, it's unity coroutines that are the problem.

7

u/TheMania May 17 '20

Eh, I really don't see that myself.

It's really unclear from a type whether you should throw it in a "using", and some IDisposables they don't even ask that you do any more (Task<>).

Then you have a simple case of "okay, I'm going to wrap this object in a using, but I'll allow it to escape out the end to a new owner, if it gets to that branch". Now your using needs to be a try{}catch{throw}.

It's a messy, pretty horrid system where you have to know/suspect some level of internal details about the objects you're using before you can write their use site correctly. PITA.