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

Re: Thoughts on Modern C++ and Game Dev

#81

Post by zrobotics » Fri, Jan 04, 2019, 4:38 PM UTC

slezyr wrote: post #38

richardjdare wrote: post #23

Earlier quoted context omitted.

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.

Have you looked through the SDL source, though? Sure, I can get a window open and paint lines very easily, I only have to write ~50-150 LOC. However, I've silently added thousands of lines (and at least one dll) to my project. The library only hides some of the complexity (which I love about it), but the complexity still exists.

Re: Thoughts on Modern C++ and Game Dev

#82

Post by _lbaq » Fri, Jan 04, 2019, 4:43 PM UTC

jokoon wrote: post #60

edoo wrote: post #57

Most industry game dev is also done on top of C++ engines and libraries. I can see Go being used in the near future as the big engines offer bindings but I bet in 5-10 years the average startup is using something like C#. It is slow as beans but eventually CPU speed will make it much more reasonable for real use. The Unity engine is a good example. It has a weird easy powerful super bloated paradigm.

You just mentioned 2 garbage collected languages on a game dev topic. I don't think they're adequate. Remember how the article was very insistent about being able to control memory and CPU resources. Those are one of the few reasons C++ is not dead. Rust? I don't see it either.

Garbage Collection is not per default something bad, even in game development, its a method of memory management, just like reference counting, or manual memory management.

If you are allocating memory in your renderloop, your likely doing it wrong. Allocation outside of this critical path, well, chose your poison.

GC will consume more memory, but likely to be faster when it comes to allocating and deallocating large amount of small blocks.

Reference counting, if you do it properly (to avoid thread starvation), is costly. Cheap atomic reference counting, involves a calculated risk that you may have threads hanging.

Manual memory management, well, we all know the cost of that :)

That being said, many many games are today developed with Unit which uses C# as its primary programming language.

Re: Thoughts on Modern C++ and Game Dev

#83

Post by jayd16 » Fri, Jan 04, 2019, 5:06 PM UTC

lifthrasiir wrote: post #16

coldtea wrote: post #12

Earlier quoted context omitted.

> That's not true. From my experience unit tests are great for agile. Not when you're constantly prototyping, which is what game dev essentially is for the most part of the process...

> which is what game dev essentially is for the most part of the process... Except that it isn't. You don't maintain the equal velocity of changes throughout the process, even for indie games. And there are always portions of the game amenable to tests.

Its not like tests are impossible. It's more that TDD is almost impossible.

Re: Thoughts on Modern C++ and Game Dev

#84

Post by corysama » Fri, Jan 04, 2019, 5:17 PM UTC

tokyodude wrote: post #77

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'm not sure what most teams do now-a-days but I went to GDC in Koln and saw the Croteam talk. Over 10 or so years by programmers just adding a little here and there as it occurred to them they had build a pretty cool testing system. First they had made it so if someone was playing the game and saw a bug they could press the "file a bug" key, type in a description and the game would save out enough info to bring some…

Similarly, on a game I worked on we had a “controller monkey” that would spam all possible player actions (move, jump, attack, special powers) rapidly and randomly. We then had the testers record multiple paths exploring through each level. Every few seconds the monkey-controlled player character would be teleported a bit further down the path to ensure progress and coverage. Dozens of people would set the monkey to run all night when they went home for the day. In the morning we would have a dozen fresh crash dumps.

Re: Thoughts on Modern C++ and Game Dev

#85

Post by corysama » Fri, Jan 04, 2019, 5:20 PM UTC

edoo wrote: post #57

Most industry game dev is also done on top of C++ engines and libraries. I can see Go being used in the near future as the big engines offer bindings but I bet in 5-10 years the average startup is using something like C#. It is slow as beans but eventually CPU speed will make it much more reasonable for real use. The Unity engine is a good example. It has a weird easy powerful super bloated paradigm.

You should read http://lucasmeijer.com/posts/cpp_unity/

Re: Thoughts on Modern C++ and Game Dev

#86

Post by georgeecollins » Fri, Jan 04, 2019, 5:22 PM UTC

pulsarpietro wrote: post #3

I am a bit puzzled by this: "Before about the early 90s, we didn’t trust C compilers, so we wrote in assembly." There a lot of games released during the 80's, were they really all written in assembly ? https://www.myabandonware.com/browse/year/ I don't have experience in the game industry at all, I must add.

In the mid 90's teams I led wrote code in assembly for things that were very performance intensive, in particular 3D rendering without 3D cards. There was also a need to write in assembly for the PS2, which had a very complicated and idiosyncratic architecture. In both cases you were really desperate for every bit of performance you could get and you didn't necessarily trust compilers to make optimal code. Since then compilers have improved and CPUs are much smarter about predicting what memory they will need.

Also, Microsoft Visual C became good, but it was not before version 4. I remember watching a team at Activision literally take more than an hour to compile their game. Perhaps they were doing something wrong, but similar teams had much less of a problem when 4.0 came out. You cannot imagine what a drag that is to a team's productivity and creativity.

Re: Thoughts on Modern C++ and Game Dev

#87

Post by foldr » Fri, Jan 04, 2019, 5:27 PM UTC

mattnewport wrote: post #75

arandr0x wrote: post #71

I'm not in games but my industry is adjacent and I have the same gripes with c++. (Which the author characterized very well.) Although build and debug times definitely are an issue regardless of the performance of the hardware. I find reading C++ "standards" papers onerous and feel like they're written in a way that's deliberately inaccessible. I don't much like the idea of going to CppCon -- even if my company funde…

If you want to get involved and for your voice to have value then you have to educate yourself on the subject. Unfortunately too many of my former colleagues in the games industry (I'm now in a "games adjacent" industry too) fail to do this before complaining about C++ and have the same attitude of "it's not fair that I should have to know what I'm talking about before anyone will listen to my complaining seriously".…

>"it's not fair that I should have to know what I'm talking about before anyone will listen to my complaining seriously".

In a way it isn't fair. Most users of most programming languages don't know the language very well. So the views of these programmers are important.

Re: Thoughts on Modern C++ and Game Dev

#88

Post by satsuma » Fri, Jan 04, 2019, 5:27 PM UTC

rafaelvasco wrote: post #42

shmerl wrote: post #34

Game developers should start using more Rust.

Yeah it's an awesome language. Has its downsides (language enforced memory micromanagement is a good thing but can get annoying sometimes.) but it's one of the best we have now. For now i'll stay with my beloved C#.

+1 for csharp, got to use it in an introductory unity class and fell in love with it.

Re: Thoughts on Modern C++ and Game Dev

#89

Post by mattnewport » Fri, Jan 04, 2019, 5:45 PM UTC

foldr wrote: post #87

mattnewport wrote: post #75

Earlier quoted context omitted.

If you want to get involved and for your voice to have value then you have to educate yourself on the subject. Unfortunately too many of my former colleagues in the games industry (I'm now in a "games adjacent" industry too) fail to do this before complaining about C++ and have the same attitude of "it's not fair that I should have to know what I'm talking about before anyone will listen to my complaining seriously".…

>"it's not fair that I should have to know what I'm talking about before anyone will listen to my complaining seriously". In a way it isn't fair. Most users of most programming languages don't know the language very well. So the views of these programmers are important.

I've never really bought this argument. If you want to contribute to theoretical physics and be taken seriously it's expected that you have a solid grounding in physics. This principle is generally fairly widely applied. There are people on the standards committee who represent their companies and part of their role is to speak for the needs of the 'regular' programmers at their companies who may not be as well informed on the language - Titus Winters from Google takes that part of his role seriously. Bjarne Stroustrup teaches C++ to many students and one of his big focuses is on simplifying the language for beginners. To do a good job of simplifying something though you actually need to understand the problem space very well. Simple ain't easy.

If someone wants to represent the 'average' programmer then the best way to do it would be to educate themselves on the language and the current state of standardization and then participate as an advocate for those programmers.

Re: Thoughts on Modern C++ and Game Dev

#90

Post by arandr0x » Fri, Jan 04, 2019, 5:48 PM UTC

Clanan wrote: post #80

arandr0x wrote: post #71

I'm not in games but my industry is adjacent and I have the same gripes with c++. (Which the author characterized very well.) Although build and debug times definitely are an issue regardless of the performance of the hardware. I find reading C++ "standards" papers onerous and feel like they're written in a way that's deliberately inaccessible. I don't much like the idea of going to CppCon -- even if my company funde…

Off-topic but can you recommend any resources off-hand for improving in your preferred C++? I share your approach but have a heck of a time finding quality books and such. (Email in profile if preferred.)

I enjoy Yossi Kreinin's blog [1] and The Old New Thing [2]. I don't read programming language books, which I usually find to have little good industry knowledge and to be too detail oriented and easily out of date. Although K&R (the one about C) is a great book that's exactly the right size and the examples from the Gang of Four book are actually very on point.

Most often I learn code by reading code. OpenSceneGraph is an example of an open source project that has modern ish C++ but no deliberately abstract misdirection. Open source usually does not have super clean code but it's a good way to sample the variety of structures you can find in a project. Of course the classics (sqlite and the Linux kernel) are much too C-like for where I'm getting at but they are still full of lessons for how to organize modules and APIs, how many arguments to pass and where, where to park I/O code, that sort of thing.

I posted it here for the benefit of HN readers who may have the same question but I'll write you an email too so you can share what you want to improve and such. There aren't many C++ programmers left in the HN-reading, not just punching a clock demographic, and I kind of miss talking to people who get that. Like the prototypical game dev in the article I go to one conference a year, and it's not about C++.

[1]: https://yosefk.com/blog/ [2]: https://blogs.msdn.microsoft.com/oldnewthing/