Following on from the success of the Steam Deck, Valve is creating its very own ecosystem of products. The Steam Frame, Steam Machine, and Steam Controller are all set to launch in the new year. We’ve tried each of them and here’s what you need to know about each one.
“From the Frame to the Controller to the Machine, we’re a fairly small industrial design team here, and we really made sure it felt like a family of devices, even to the slightest detail,” Clement Gallois, a designer at Valve, tells me during a recent visit to Valve HQ. “How it feels, the buttons, how they react… everything belongs and works together kind of seamlessly.”
For more detail, make sure to check out our in-depth stories linked below:
Steam Frame: Valve’s new wireless VR headset
Steam Machine: Compact living room gaming box
Steam Controller: A controller to replace your mouse
Valve’s official video announcement.
So uh, ahem.
Yes.
Valve can indeed count to three.
10ms is way too slow for multithreading latency in games. Even 1ms for part of a frame is too slow. At 90hz you only have 11ms per frame.
Though using your pc as a host for a game server that the frame connects to would be possible. Like a multiplayer game. It could help with offloading some CPU heavy elements. I suspect though that most of the difficulty will be rendering, like in the quest.
Well, like the examples I tried to give… its fairly common in game dev to set aside a distinct physics thread or set of threads, that run at some fixed number, maybe 30 or 60 fps, to avoid the once very common problem of game physics functions going bonkers with unexpected hardware speeds.
It also helps with just generally normalizing physics behavior in complex vs simple scenes, lets you just have solid bounds for number of whatever kind of dynamic things possible in an area.
Or, for doing things like deep simulation, where you run like, an aporixmation, a simplification of many npcs, non rendered, but when a player comes into view of one of them, then they transition from approximately simulated, to fully simulated.
So like, most games just spawn and despawn like crowds of people by more or less a ‘where are you’ ‘what time of day is it’ and ‘what npcs should be here’, and then it just picks blank templates out of a pool.
But if you wanted a uh, 1000s of npcs doing a daily routine in a city or landscape, potentially having reactions to other npcs they may meet… thats more like deep sim, thats something you can approximate on a slowed down timeframe, thus potentially shunt off to another segment of threads/hardware, more geared toward regular iterations on a massive dataset, than hyperspecific, hyper fresh data.
Can also be used with something like dynamic, ambient loot or wildlife or fauna generation/simulation.
Like yeah, I agree that there are mant uses cases where 10ms is still too much latency, but… why not apply ‘foviated rendering’ to something like… procedural terrain generation, in chunks/maps/meshes of descreasing size, increasing detail?
If the player is mostly stationary, not moving rapidly, just slowly build out more detail ariund them, in a circle.
If they are moving rapidly, prioritize pre caching various detail levels of chunks that they are rapidly moving toward, stop the above naive, layered detail build out process.