Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Thoughts on Modern C++ and Game Dev

elbeno.com

Post reply on HN
Print view View original

51–60 of 143 posts

Re: Thoughts on Modern C++ and Game Dev

#51

Post by AnIdiotOnTheNet »

vardump wrote: post #46
exDM69 wrote: post #32

Earlier quoted context omitted.

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

> In my experience, compilers are much better than humans at instruction scheduling. It'd be more accurate to say they're much better than humans when the heuristics or whatever they use works. Sometimes the compiler messes up badly. The workflow is often to compile and then examine disassembly to see whether the compiler managed to generate something sensible or not. Other issue is that compiler pattern matching is…

Things like this make me question the wisdom of ever using higher level languages. We took the path of abstracting our description of what we want to happen away from processor instructions with the idea that we could write code that could then compile on multiple architectures without changes, but the reality is that we still often need to special case things even without performance considerations, and the farther we abstract the more performance seems to be impacted and the more often we seem to end up jumping through abstraction hoops rather than getting things done.

The minimalist in me wonders if maybe just using some kind of macro system on top of assembler plus a bytecode VM with the ability to drop to native instructions wouldn't ultimately be better.

Re: Thoughts on Modern C++ and Game Dev

#52

Post by overgard »

A few thoughts:

* None of the problems that have been commented on are unique to the games industry at all. Slow debug builds suck for all C++ developers and weird template meta-programming is confusing for practically everyone.

* He makes these broad hand-wavey statements like "individuals don't feel pain from slow compile times", or "big companies can just can throw processor power at it" to which I would say, BS. Fast iteration in C++ is really hard because of the delay and it's a big problem for everyone.

* "Participate more" -- isn't that exactly what people are doing on twitter? Not everyone can go to CppCon.

Re: Thoughts on Modern C++ and Game Dev

#53

Post by AnIdiotOnTheNet »

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.

That's just piling on even more abstraction! You may as well use a hex editor and create a single line BMP, then "run" it with any image viewer.

Re: Thoughts on Modern C++ and Game Dev

#54

Post by deng »

neutronicus wrote: post #49
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…

> 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). I have to defend C++ here - "native matrices" is under-specified. In practice, "Matrix" is one of the leakiest abstractio…

For many projects you won't need that complexity. You just want to directly map basic matrix operations to the usual BLAS/LAPACK calls. Fortran 90+ does that job well, for instance, and performance will usually be better than a C++ library (yes, I've tested against Eigen and Armadillo, although that was years ago). Combine that with the enormous compile times and the absolute ridiculous error messages for even simplest syntax errors, and I never looked back. Fortran may have a bad rep, but the newer iterations are actually pretty good for that kind of stuff.

Re: Thoughts on Modern C++ and Game Dev

#55

Post by blktiger »

otikik wrote: post #20
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 think the reason is that tests have a very obvious up-front cost, while the time they save is distributed in the future, in a non-immediately obvious way. I still think that they end up saving time, with some exceptions like UI code, which are more easily tested "by hand". Game project managers are infamous for not being great planners, so it wouldn't surprise me that they dismissed automated tests as "a waste of t…

Modern games have only increased the benefits a game studio can gain from testing as well. Games are now moving into service territory which only increases the amount of time spent maintaining the game while continuing to add to it.

Re: Thoughts on Modern C++ and Game Dev

#56

Post by SeanBoocock »

de_watcher wrote: post #45
pferde wrote: post #31

Earlier quoted context omitted.

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

My experience is from working on one of the games with automatic tests. From the playing experience: yes, there are way more games with internal manual and external community testing.

Yeah at a certain level game productions will usually have automatic “smoke” tests for general build stability and I’ve worked on one that had automatic feature tests with replayed input. These were generally useful for catching obvious crashes and regressions, but the overhead only makes sense for a certain level of production. Could also see, and have heard of, more rigorous functional testing of things like a procedural generation pipeline that are otherwise harder to get sufficient coverage of manually.

Re: Thoughts on Modern C++ and Game Dev

#57

Post by edoo »

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.

Re: Thoughts on Modern C++ and Game Dev

#58

Post by andrewmcwatters »

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 might want to stretch that estimate out. I'm running an Intel Core i5-3550 from 2012. Furthermore, I foresee no reason to upgrade in the next 4 years. The current i5 on userbenchmark.com's front page is the 9600k, which says it's ~53% faster than my 3550. 7 years later.

CPU performance is barely going anywhere. Developers should instead try to figure out how to do more with less growth.

GPUs are also overpriced, and playing older games and comparing them to new ones doesn't show great payoff. As far as I'm concerned, we've plateaued. Maybe going from a GTX 760 to a 1060 would give me a few more frames, but frankly, more often than not, the games are programmed like utter shit.

Re: Thoughts on Modern C++ and Game Dev

#60

Post by jokoon »

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.

Post reply on HN