Memory and C++ Debugging at Electronic Arts [video] • Hacker News Board

Re: Memory and C++ Debugging at Electronic Arts [video]

#51

Post by NickPollard » Thu, Oct 08, 2015, 8:27 AM UTC

bluecalm wrote: post #50

pandaman wrote: post #38

Earlier quoted context omitted.

Here is all you need to know to understand game development. It's just two things. Firstly, on a home console there are just two playable frame rates: 30 fps and 60 fps. This means you can only have frames either less than ~16.6 ms or ~33.3ms long. The next step is 20 fps and if you were even allowed to ship a game like that it would not make any money so you would likely get fired anyway. You will do very unsafe thi…

>>Firstly, on a home console there are just two playable frame rates: 30 fps and 60 fps. This is probably very basic but I am going to ask anyway: why are 40fps, 45fps or 47fps not possible?

Because the display is normally running at 60hz, so if you don't want tearing (where the frame to be displayed changes halfway through monitor refresh, leading to a sharp tear across the screen), you need to run at an integer number of refreshes per frame (known as vsync). 1 = 60fps, 2 = 30fps, 3 = 20fps.

Re: Memory and C++ Debugging at Electronic Arts [video]

#52

Post by pandaman » Thu, Oct 08, 2015, 8:30 AM UTC

bluecalm wrote: post #50

pandaman wrote: post #38

Earlier quoted context omitted.

Here is all you need to know to understand game development. It's just two things. Firstly, on a home console there are just two playable frame rates: 30 fps and 60 fps. This means you can only have frames either less than ~16.6 ms or ~33.3ms long. The next step is 20 fps and if you were even allowed to ship a game like that it would not make any money so you would likely get fired anyway. You will do very unsafe thi…

>>Firstly, on a home console there are just two playable frame rates: 30 fps and 60 fps. This is probably very basic but I am going to ask anyway: why are 40fps, 45fps or 47fps not possible?

The video out is fixed at 60hz so, at constant framerate, you can only output every frame, every two frames, every three frames etc. In other words you framerate is a factor of 60. You could tripple buffer and do variable rate so an average could be something like 40, but it would cost you 8M and variable framerate is perceived worse than constant. If you cannot hit 60 you better spend more time on getting game prettier at 30 than waste memory on a tripple buffer and get a stuttering game as a result. On current gen memory is not as much an issue but the variable framerate is still not perceived well.

Re: Memory and C++ Debugging at Electronic Arts [video]

#53

Post by MaulingMonkey » Thu, Oct 08, 2015, 8:32 AM UTC

bluecalm wrote: post #50

pandaman wrote: post #38

Earlier quoted context omitted.

Here is all you need to know to understand game development. It's just two things. Firstly, on a home console there are just two playable frame rates: 30 fps and 60 fps. This means you can only have frames either less than ~16.6 ms or ~33.3ms long. The next step is 20 fps and if you were even allowed to ship a game like that it would not make any money so you would likely get fired anyway. You will do very unsafe thi…

>>Firstly, on a home console there are just two playable frame rates: 30 fps and 60 fps. This is probably very basic but I am going to ask anyway: why are 40fps, 45fps or 47fps not possible?

Because your monitor is (probably) refreshing at 60hz. Your frames will display for some integer number of monitor refreshes - at 1 you'll get 60fps, at 2 you'll get 30fps.

Over a second, it's of course entirely possible to get something in-between, where some frames are displayed for 1 refresh, and others for 2 refreshes. Inconsistently waffling between these is going to be more jarring than sticking to one.

Recently, you have things like nVidia's... gsync? Which make the monitor refresh rate variable with compatible monitors, to match the game framerate, making 45fps entirely possible, and reducing the jarring from varying frame lengths. But this recent, rare, and likely PC and/or GPU vendor specific still.

Re: Memory and C++ Debugging at Electronic Arts [video]

#54

Post by z3phyr » Thu, Oct 08, 2015, 9:54 AM UTC

pjmlp wrote: post #35

z3phyr wrote: post #8

Earlier quoted context omitted.

A major chunk of software developers use C/C++ (including a lot of Game Developers); Although lot of people see only the tip of the iceberg. Look into your systems. Almost everything down there from your database to your compiler/interpreter/VM to your operating system, your web browser, your music player, the internals of your search engine and yes your favorite games (renderer, physics, most of the gameplay) is pro…

I like C++, but I am also quite older than the language and remember when the language was seen as unsuitable to write any of those systems you have mentioned. Eventually it got adopted by people like myself that didn't care for the naysayers and its compilers improved to the point many think it was always like that. Likewise others will use languages that the naysayers of today won't see as proper to write them and…

You are right. I see a huge potential in Rust. It seems very suitable for the C++ level domains. The only thing keeping me away from production usage today is the lack maturity with ecosystem and libraries.

Re: Memory and C++ Debugging at Electronic Arts [video]

#55

Post by z3phyr » Thu, Oct 08, 2015, 10:04 AM UTC

kayamon wrote: post #45

Zardoz84 wrote: post #40

Earlier quoted context omitted.

There some AA or AAA games using languages that not are C/C++ . Severence: Blade of Darkness (Aka Blade: The edge of darkness), have a lot of code on pure Python. And it's well know that Naughty Dog use a variant of Lisp on his games.

I'm sure there are - that's not what I said. Also, Naughty Dog's games do _not_ use Lisp, they use a custom language that looks a little like Lisp, but has no garbage collector.

Naughty dog used to use Game Oriented Assembly Lisp (GOAL), which was very scheme like. They dropped it for C++. Although they still use a Racket dialect for some gameplay scripting.

Re: Memory and C++ Debugging at Electronic Arts [video]

#56

Post by Flow » Thu, Oct 08, 2015, 10:11 AM UTC

StephanTLavavej wrote: post #30

jcranmer wrote: post #21

Earlier quoted context omitted.

Or on Linux or Windows: gcc is now written in C++, and I'm pretty sure MSVC itself is in C++.

Yes, both MSVC's front-end C1XX and back-end C2 (aka UTC) are written in C++. Even our CRT is mostly C++ now.

Do you update it to follow the latest standards or is it early 2003-ish C++?

Re: Memory and C++ Debugging at Electronic Arts [video]

#57

Post by jguegant » Thu, Oct 08, 2015, 11:18 AM UTC

z3phyr wrote: post #54

pjmlp wrote: post #35

Earlier quoted context omitted.

I like C++, but I am also quite older than the language and remember when the language was seen as unsuitable to write any of those systems you have mentioned. Eventually it got adopted by people like myself that didn't care for the naysayers and its compilers improved to the point many think it was always like that. Likewise others will use languages that the naysayers of today won't see as proper to write them and…

You are right. I see a huge potential in Rust. It seems very suitable for the C++ level domains. The only thing keeping me away from production usage today is the lack maturity with ecosystem and libraries.

Rust is kinda the Godwin's law of C++ threads these days.

Re: Memory and C++ Debugging at Electronic Arts [video]

#58

Post by lorenzhs » Thu, Oct 08, 2015, 12:06 PM UTC

e12e wrote: post #16

z3phyr wrote: post #8

Earlier quoted context omitted.

A major chunk of software developers use C/C++ (including a lot of Game Developers); Although lot of people see only the tip of the iceberg. Look into your systems. Almost everything down there from your database to your compiler/interpreter/VM to your operating system, your web browser, your music player, the internals of your search engine and yes your favorite games (renderer, physics, most of the gameplay) is pro…

AFAIK Debian isn't very diligent about tagging packages with "implemented-in", but even so: dpkg -l |grep ^ii -c #Installed packages 3608 # packages tagged as being in c++, and installed: aptitude search '?tag(implemented-in::c++)' \ |grep ^i -c 930 I'm sure there's lots of c++ in the other 75% (or they depend on a runtime/compiler/library written in c++) -- but at any rate - one in four packages is nothing to sneeze…

Your search query needs escaping for the pluses, otherwise it will match 'implemented-in::c' as well (aptitude's matching is weird).

Re: Memory and C++ Debugging at Electronic Arts [video]

#59

Post by magoghm » Thu, Oct 08, 2015, 12:29 PM UTC

pjmlp wrote: post #35

z3phyr wrote: post #8

Earlier quoted context omitted.

A major chunk of software developers use C/C++ (including a lot of Game Developers); Although lot of people see only the tip of the iceberg. Look into your systems. Almost everything down there from your database to your compiler/interpreter/VM to your operating system, your web browser, your music player, the internals of your search engine and yes your favorite games (renderer, physics, most of the gameplay) is pro…

I like C++, but I am also quite older than the language and remember when the language was seen as unsuitable to write any of those systems you have mentioned. Eventually it got adopted by people like myself that didn't care for the naysayers and its compilers improved to the point many think it was always like that. Likewise others will use languages that the naysayers of today won't see as proper to write them and…

In the early 90's I posted on some game developers forum that when consoles got more powerful processors it would be possible to write games in C instead of using assembly language. Everybody told me that I was an idiot.

Re: Memory and C++ Debugging at Electronic Arts [video]

#60

Post by inDigiNeous » Thu, Oct 08, 2015, 1:05 PM UTC

pjmlp wrote: post #47

inDigiNeous wrote: post #41

Earlier quoted context omitted.

I can answer only for my own account, but for starting a new project in late 2013 december, and now been working for it the past two years, related to custom geometry generated in VR, C++ was the only viable crossplatform option. With C++ (using the C++11 standard) I can assure pretty sure that the code compiles on Mac, Linux, Windows, Android, iOS and pretty much every platform. With the VR -platform we also need al…

However that is a consequence of available implementations, not of the language itself. Back in the day, I went Turbo Pascal -> C++ exactly for that reason (Turbo Pascal -> C was never an option). If the UNIX systems I had to work with, had a Turbo Pascal compatible compiler, I would kept using it.

Well, partly yes. If this was year 2030 and Rust was available on every platform so that everything worked perfectly, I would have probably used that.