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

11–20 of 143 posts

Re: Thoughts on Modern C++ and Game Dev

#11

Post by pavlov »

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.

Anything with realtime graphics was probably written in assembly. There were game companies whose entire business was porting games between platforms, essentially rewriting the code for each machine.

Slower-moving adventure and RPG games might be in a higher-level language. (IIRC the original Wizardry was written in a VM-based Pascal for Apple II?)

Companies that specialized in adventure games would have their own interpreter and VM — Infocom's ZIL, Sierra's AGI, Lucasfilm's SCUMM. Game developers would write code in a scripting language against that company-standard VM.

Amateur games might be written in BASIC because every computer under the sun shipped with a BASIC interpreter back then.

C wasn't a practical option because decent compilers didn't exist for most non-Unix systems until the end of the 1980s — or if they did, they'd cost an arm and a leg. (I think the retail price for Microsoft's C compiler for DOS was several thousand dollars.)

Re: Thoughts on Modern C++ and Game Dev

#12

Post by coldtea »

oselhn wrote: post #9
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.

That's not true. From my experience unit tests are great for agile. It will allow you to create "trusted" modules which you can move around and rework much easier (you can also treat your tests as executable documentation). Without tests you can't safely do any change to existing code especially if you are changing code written by someone else. You have to risk it and than spent considerable time in debugger if it br…

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

Re: Thoughts on Modern C++ and Game Dev

#13

Post by coldtea »

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.

>There a lot of games released during the 80's, were they really all written in assembly ?

Most of them, yes. Here's a well known game:

http://fabiensanglard.net/prince_of_persia/index.php

Re: Thoughts on Modern C++ and Game Dev

#14

Post by coldtea »

vardump wrote: post #4
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.

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…

>486 era you needed assembler to work around quirks like AGI stalls.

Plus, nobody had a 486 in the 80s (it was released in 1989). People would be lucky to have a 286, but usually just some home computer (Apple II, Spectrum, Commodore 64, Atari ST, Amiga 500, Amstrad CPC, etc).

Re: Thoughts on Modern C++ and Game Dev

#15

Post by vardump »

coldtea wrote: post #14
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…

> 486 era you needed assembler to work around quirks like AGI stalls. Plus, nobody had a 486 in the 80s (it was released in 1989). People would be lucky to have a 286, but usually just some home computer (Apple II, Spectrum, Commodore 64, Atari ST, Amiga 500, Amstrad CPC, etc).

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 division and multiply, most advanced math those things could do was little more than adding (add, sub, and, or, xor) two 8 bit numbers together. Even shifts and rotates could only handle 1 bit left or right.

CPU clocks were measured in low single digit MHz. On top of that, 8 bitters were very inefficient — each instruction would take 2-8 clock cycles (6510) or 4-23 cycles (Z80).

On PAL C64 you have 19656 clock cycles per 50Hz screen frame minus 25 bad lines. So you could realistically expect to execute only 5-8k instructions. If you used all the frame time for just copying memory, you'd be able to transfer just about 2 kB. Just scrolling character RAM (ignoring color RAM) took half of the available raster time (yes, I know about VSP tricks, but it wasn't known in the eighties).

16-bit systems allowed some C, but most Amiga and Atari ST games were written in assembler. I'd guess same is true for 286 era, but not sure.

Re: Thoughts on Modern C++ and Game Dev

#16

Post by lifthrasiir »

coldtea wrote: post #12
oselhn wrote: post #9

Earlier quoted context omitted.

That's not true. From my experience unit tests are great for agile. It will allow you to create "trusted" modules which you can move around and rework much easier (you can also treat your tests as executable documentation). Without tests you can't safely do any change to existing code especially if you are changing code written by someone else. You have to risk it and than spent considerable time in debugger if it br…

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

Re: Thoughts on Modern C++ and Game Dev

#17

Post by simonh »

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.

I can support the trust issue with C compilers. I did my CS degree in the 80s and every C compiler I used had severe bugs. These weren’t on Unix to be fair, they were to run on PCs or to program embedded systems, but they were awful. I remember one (Aztec C?) crashing out because one of my statements had two lines of whitespace before it instead of one (or maybe it was an extra space in a blank line? I forget), which was fine elsewhere in the program but just caused a problem in that particular context. I first used GCC in the 90s and it was heaven.

Re: Thoughts on Modern C++ and Game Dev

#18

Post by CoolGuySteve »

vardump wrote: post #4
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.

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 has improved since then.

Re: Thoughts on Modern C++ and Game Dev

#19

Post by CoolGuySteve »

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 horrible having to decipher the _m_data or whatever of various implementations.

I’m actually not sure if gcc is not compiling the inlines into the object code (I thought it was required by the standard) or if gdb just can’t find them.

Re: Thoughts on Modern C++ and Game Dev

#20

Post by otikik »

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 time" or "something that we can't do now because we don't have time now" (so we end up wasting more time in the end, having to do death marches, etc)

Post reply on HN