To maintain 30FPS you must finish a frame in 33ms (1000ms/30). To maintain 60FPS you must finish a frame in 16ms. Some of the VR literature I've read has recommended 90FPS or higher to combat nausea - 11ms. A millisecond could easily be 1/10th of your entire frame budget for the whole game's per-frame processing time, to say nothing of individual subsystems. At least we have multiple cores, but some stuff must run on the main thread...
> Also, rad game tools is a company that makes very useful tools for profiling.
arcin is of course referring to Telemetry[1] here, a wonderful tool for generating explicitly annotated flamegraphs that I've helped integrate into multiple codebases at different jobs. Engine-custom[2] tooling is also common, where you're seeing scopes measure in microseconds. There's a bunch of FOSS alternatives[3] of varying quality / functionality - nothing that's put Telemetry out of business for me yet though. "I'll write one myself for Rust someday!" I keep telling myself ;)
You guys have much cooler stuff to play with than I have for profiling things. Also better visualizations, but that is perhaps to be expected from the game industry.
>Some of the VR literature I've read has recommended 90FPS or higher to combat nausea - 11ms
That explains why VR is so computation heavy. Also curious what the mechanism is why you become nauseous under the 90fps. Perhaps the brain observes you are moving abruptly with lower frame rates, giving a constant sense of acceleration.
About telemetry. It feels weird that they are so flexible about their license, I am come from the corporate world, where licensing is set in stone. Is the game industry mostly informal?
>I'll write one myself for Rust someday
You do your game development in Rust? I have interest in Rust, because it has an interesting type system, but perhaps it would be nice to make a simple game in it to learn it and look how that goes.
> Also curious what the mechanism is why you become nauseous under the 90fps. Perhaps the brain observes you are moving abruptly with lower frame rates, giving a constant sense of acceleration.
I'm lucky enough to not suffer from the effects myself... supposedly Habituation can help, so perhaps I just read enough books in moving vehicles as a child?
> About telemetry. It feels weird that they are so flexible about their license, I am come from the corporate world, where licensing is set in stone. Is the game industry mostly informal?
It varies a good bit. Gamedev middleware shops are often small companies not burdened by large bureaucracies, dealing with high price, low volume sales - so they can afford a more high touch, personalized, and perhaps informal approach to sales. They also want to maximize the amount of devs trying their software - even if they don't use it for their current project or company, they might use it for the next, which is more sales - so they're quite happy to hand out evaluation licenses, or talk about missing features / platforms you might be interested in.
Those licenses are partially enforced by software, and for console versions, they might need to verify your lawyers have executed an appropriate NDA with Sony/Microsoft/Nintendo/??? before they even let you download those versions, however. Possibly via posting to shared, restricted access forums.
More standardized pricing systems are also common.
> You do your game development in Rust? I have interest in Rust, because it has an interesting type system, but perhaps it would be nice to make a simple game in it to learn it and look how that goes.
Just for my side projects so far - my professional gamedev work is generally C++ plus a dozen other languages that vary by company for scripting and supporting tools. There's a lot of interest in Rust, though - it's type system and borrow checker do a lot to catch the kinds of heisenbugs that plague large high-performance C++ codebases (which in turn lead to crunch, missed milestones, etc. depending on the company culture.) On smaller codebases, the borrow checker feels more like a nuisance than a help until you get quite used to it, but at this point I feel like I have gotten used to it (and perhaps become a better programmer in the pursuit).
In my next job search I'll definitely be keeping an eye out for the chance to play with Rust professionally...
To maintain 30FPS you must finish a frame in 33ms (1000ms/30). To maintain 60FPS you must finish a frame in 16ms. Some of the VR literature I've read has recommended 90FPS or higher to combat nausea - 11ms. A millisecond could easily be 1/10th of your entire frame budget for the whole game's per-frame processing time, to say nothing of individual subsystems. At least we have multiple cores, but some stuff must run on the main thread...
> Also, rad game tools is a company that makes very useful tools for profiling.
arcin is of course referring to Telemetry[1] here, a wonderful tool for generating explicitly annotated flamegraphs that I've helped integrate into multiple codebases at different jobs. Engine-custom[2] tooling is also common, where you're seeing scopes measure in microseconds. There's a bunch of FOSS alternatives[3] of varying quality / functionality - nothing that's put Telemetry out of business for me yet though. "I'll write one myself for Rust someday!" I keep telling myself ;)
[1] http://www.radgametools.com/telemetry.htm
[2] https://www.youtube.com/watch?v=DMO4X9leTG8
[3] https://github.com/jonasmr/microprofile https://github.com/Celtoys/Remotery https://github.com/loganek/hawktracer https://github.com/google/orbit