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

41–50 of 143 posts

Re: Thoughts on Modern C++ and Game Dev

#41

Post by jcelerier »

pjmlp wrote: post #25
CoolGuySteve wrote: post #19

Is Visual Studio really the best debugger? Every time I use it I get really frustrated by the difficulty of entering complex instructions. The GUI is more discoverable but I find myself missing gdb ‘s functions and parser. However, one thing in gdb that’s become steadily worse is the ability to evaluate STL’s operator[] and the like in optimized code, with the debugger frequently whining about inlining. It’s pretty h…

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

At least for the Qt ecosystem, apps like Heaptrack, Hotspot, Gammaray are in my opinion miles better than what VS provides.

Re: Thoughts on Modern C++ and Game Dev

#42

Post by rafaelvasco »

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

Re: Thoughts on Modern C++ and Game Dev

#43

Post by richardjdare »

pjc50 wrote: post #29
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…

> much more ergonomic than it is now, This is an interesting line of argument - in what way, and what could be done to improve the ergonomics? > He gets a simple graphical effect going on the Amiga in only a few lines of assembly. Doing the same thing using DirectX in c++ would take you all day! This is absolutely true, but in something like ShaderToy you can go back to producing complex pixel-bashing effects with a…

My notion of ergonomic mostly comes from programming the Amiga in 68000 and then moving to the PC and being horrified by x86!

In 68k you had 8 32-bit data registers, (d0-d7) and 8 address registers (a0-a7)

If you wanted to access bytes or 16 or 32 bits you could do so like this:

  move.w #123,d0 ; move 16bit number into d0
  move.b #123,d1 ; move byte into d1

  move.l #SOME_ADDRESS,a0; set address reg a0 to point to a memory location.
  move.b d1,(a0) ; move contents of d1 to memory location a0 is pointing to.
Nice and easy to work with and remember.

On x86, thanks to its long and convoluted history you have all kinds of doubled up registers which you have to refer to by different names depending on what you are doing, and tons of historical cruft.

On top of the CPU, the old home computers had no historical cruft and it was very easy to talk to the hardware or system firmware; usually you'd just be getting and setting data at fixed memory locations. I can read an Amiga mouse click in one line of 68k. I've no idea how you'd do it on a modern PC or even Java! Modern systems just aren't as integrated, for better and worse.

Assembly language was also part of mainstream programming back then. You'd learn Basic then go straight to assembly if you wanted to do anything serious. So there were computer magazine articles on assembly, childrens books[1]. My first assembler, Devpac, came from a magazine coverdisk with a tutorial from Bullfrog, Peter Molyneaux's old game company[2].

So there were a whole range of cultural and technical reasons for assembly language being much more of a human-useable technology back in the day.

>It's just the external Tower of Babel from boot to usability has got a lot larger.

Yes I agree, I kinda miss being able to see the ground, which is probably why I find retro programming so appealing.

[1]https://archive.org/details/machine-code-for-beginners [2]https://archive.org/details/amigaformat39/page/n61

Re: Thoughts on Modern C++ and Game Dev

#44

Post by vardump »

aerique wrote: post #27
vardump wrote: post #15

Earlier quoted context omitted.

Oh right, I missed it was about eighties. Yeah, back then assembler was even more pervasive. It was the only way to write something publishable on 8-bit systems. Well, there were some action games (like C64 Beach Head), trivia and adventure games written in BASIC. You spent a lot of time on 8-bitters getting code and asset size down, so that it'd even fit on the machine in the first place. Forget about luxuries like…

I'm not sure this is correct but: I remember reading or hearing rumours that Psygnosis' Barbarian (for the Amiga and Atari ST) was written in C and that it was so slow because of that. What I mean is: we perceived it as being slow because of the rumours. Just typical nerd attitude that we still see now.

Sure, some games were written completely in C. I believe significant number were hybrids, performance sensitive parts in assembler and other code in C.

Some games were prototyped in C and optimized afterwards.

For example Amiga Turrican 2 required 33 MHz 68030 CPU during the development phase. Of course the final version ran fine on 7 MHz 68000 Amiga.

Re: Thoughts on Modern C++ and Game Dev

#45

Post by de_watcher »

pferde wrote: post #31
de_watcher wrote: post #22

Earlier quoted context omitted.

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.

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.

Re: Thoughts on Modern C++ and Game Dev

#46

Post by vardump »

exDM69 wrote: post #32
CoolGuySteve wrote: post #18

Earlier quoted context omitted.

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 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 sometimes not working and generating correct SIMD instruction. Even when data is SIMD width aligned. For example, recently I saw ICC not generating a horizontal add in the most basic scenario imaginable. * shrug *.

Re: Thoughts on Modern C++ and Game Dev

#47

Post by SomeHacker44 »

Jyaif wrote: post #36
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...

Its a matter of perspective, what constitutes a waste of time.

If you are under pressure to ship something now/soon, and may not exist as a company in the next standards cycle, then it is probably a waste of time for that company.

Re: Thoughts on Modern C++ and Game Dev

#48

Post by vardump »

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…

> Back then assembly language was much more ergonomic than it is now, and the machines were simpler.

In a way that's true. I also enjoyed writing assembler back then, especially on 68k.

However, to really extract the last cycle you often ended up generating a block of code at runtime (kind of very basic JIT).

Sometimes self-modifying code provided the final oomph to get something running fast enough. The reasons varied: sometimes it was because of running out of registers, sometimes dynamically changing the performed operation without branch.

Too bad for the later CPUs with instruction prefetching and caching...

Re: Thoughts on Modern C++ and Game Dev

#49

Post by neutronicus »

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 abstractions in programming and you have to care about representation and choice of algorithm pretty much from the get-go, and IMO C++ is actually the best available option for managing that complexity, especially when you're solving large systems in parallel (and it's worth pointing out that one of the front-running open-source libs in this space is written in C++[1]).

[1] https://github.com/trilinos/Trilinos

Re: Thoughts on Modern C++ and Game Dev

#50

Post by coffeeaddicted »

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…

You can parse expressions inside the "QuickWatch" dialog in VS.
Post reply on HN