sncvsrtoip
Member
for example many games won't even start before proper calibration of camera and move controllers/dualshock 4, this have to be somehow overwriten without patching games, quite interesting how they did it
Last edited:
-
Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.
PSVR 2 will be Backwards Compatible with PSVR Titles
- Thread starter IbizaPocholo
- Start date
- Rumor VR
a multicultural team of v
Member
No you might be right, I am basing this off my assumption of how Sony would handle the API based off their history vs how Microsoft has, but that might not be a correct assumption. I do agree with your analysis, in that it should be solvable fairly eaily on paper. Good conversation though appreciate the input.I'm not sure that is because of API's tbh, they are just different approaches to backwards compatibility. Sony went the route of making the hardware act like a PS4 Pro and MS went down the virtual machine road, which I think they were already doing for XB1/X.
I don't know how much you know about object orientated software design (& apologies if you already know this), but an API can be as simple as an abstract interface between two parts (modules) of a program - meaning they can be switched out very easily because both are written to follow the same inputs & same outputs. I'm not going to get into the virtues of SOLID design principles, but they are pretty fundamental to software design and I'd expect the PS SDK to be following them as AFAIK its written in C++.
This is all conjecture though, I am not a games dev and I've never seen their SDK. I do have a lot of experience designing and writing this crap though so it doesn't seem too far out of the realms of possibility for me. You may well be right though, they might have not thought of this stuff and coded themselves into a corner. Time will tell I guess
And Mr. Mod I am NOT trying to make this a console war thing, I only bring up MS because it is exactly relevant to my thought process lol
Tracking system is not at all important - the Apps/Games talk to the SDK to get interpolated-future-predicted position. At no point are they 'aware' of the tracking system - they simply get the positional/rotational information about tracked devices. Different hw still has to serve the same information. Unless precision is specifically worse on PSVR2 in areas where PSVR was 'good' there's literally no reason for it to not 'just work'.
FOV is also a non-issue, no PSVR title can ship without correctly querying the FOV from the device (if it didn't, the reprojection that SDK performs later would give very broken results too). If they wanted to be extra safe, PSVR2 could always force narrower FOV to match PSVR1 in BC titles, it'd suck, but it would work.
Mapping controller inputs is a bit more involved, but Move was 'only buttons' so relatively straightforward, just in-game UI may be a bit confusing at times (that part would require game-patches to fix as it wasn't system controlled/each game has unique user-interface display, but it wouldn't stop game from working anyway).
There are some potential pitfalls around lens-matched rendering optimizations, SDK provided fairly low-level data-structures here to integrate into your command buffers and such, so lens-changing could technically cause trouble in some games. Possible work-around here would be to just return 'no optimization' in the PSVR2 parameters - as the PS5 is more than capable enough to brute-force those parts in BC games anyway.
TLDR - what's discussed is not all that different from how PCVR allowed SteamVR HMDs to work on Oculus APIs. And yes - most VR SDKs are 'very', very similar to one another to begin with.
Last edited:
You're confusing two concepts here, one is programming abstraction layers, another is how companies build for BC.
Sony's BC clearly has enhancements, and they had them all the way back to PS2->PS1 (which was not as much of a hw solution as people think). It is however true that prior to PSP, Sony didn't provide API abstraction for the entire console, but it has been the case ever since.
Now - consoles being consoles - developers do have ways to do some very direct interfacing with the hw even with the APIs (and that goes for all of Microsoft consoles as well), so if you are thinking API->HLE->BC, then no, it doesn't work like that on any device.
Auto HDR is an injection that happens after application hands over the buffer to the OS, basically analogous to how PS3 did PS1/PS2 upscaling/sharpening for instance.
Resolution changes have been restricted to emulated titles only, and frame-rate hack is a specific thing that could also work for certain 'select' PS4 titles if Sony wanted to pursue it. It's 'select titles' on XBox too - though if converting entire libraries, I expect more Xbox titles would work.
There are places where MS benefits from their abstraction layers (like forcing enhanced Texture filtering), or for example new I/O working a lot better on BC titles, but it's not as all encompassing as people assume either.
Tams
Member
That really depends on where the corrections, alterations and assumptions of coordinate data are being down. If it's all being done by the PSVR, that it should be relatively easy to port it over.
But knowing how these things tend to go, someone somewhere will have coded some of that stuff into the games for whatever reason and if so that'll require more work. And then there's always unforeseen bugs. Perhaps better tracking data will play havoc with software expecting lower resolution data?
Oddvintagechap
Member
This is going to be interesting.
Because the success of the backward compatibility might hinder the new gen abilities of the headset.
It’s going have emulate a camera actively tracking two controllers.
So it might be necessary for the headset to have a camera. To track the Tv, and place a imaginary camera under the glowing rectangle. Or it might come with a “wii” sensor bar. Or require the PS5 camera for back compatibility(which currently isnt usable for VR1).
I wonder if there’s any gameplay involving covering the colored orbs, requiring the system to track the space between the controller and the TV.
Interesting stuff.
But if they can do this. BRING PSVITA games over.
Because the success of the backward compatibility might hinder the new gen abilities of the headset.
It’s going have emulate a camera actively tracking two controllers.
So it might be necessary for the headset to have a camera. To track the Tv, and place a imaginary camera under the glowing rectangle. Or it might come with a “wii” sensor bar. Or require the PS5 camera for back compatibility(which currently isnt usable for VR1).
I wonder if there’s any gameplay involving covering the colored orbs, requiring the system to track the space between the controller and the TV.
Interesting stuff.
But if they can do this. BRING PSVITA games over.
BLAUcopter
Gold Member
Seemingly? They fucking better work.
Wonko_C
Member
Over 500 according to their PSVR anniversary post on their blog.
On the topic of BC, PCVR headsets initially used external cameras or base stations for tracking, then a few years later inside-out tracking headsets came out and the games still worked without issue. I assume PSVR2 will be the same for PSVR1 titles.
Last edited:
Bojanglez
The Amiga Brotherhood
Yeah that was so annoying, it was a great device for the price but that was a terrible oversight and a kick in the balls to the early adopters that are most likely also to give a shit about HDR.
I've hooked it up to my PS5 a couple of times and the performance boost is nice, but can't wait to have less cumbersome headset and controllers that charge via USB-C
FunkMiller
Gold Member
If they could get RE7 running at a similar level of fidelity in VR as it has in pancake mode on PC… that’d be quite a thing.
Last edited:
Don't see how that would matter - applications only have access to spatial/temporal data returned from the SDK, post-processing that(positions, velocities, angular momentum) would behave the same regardless of what your source is. And more importantly that 'only' applies to tracked controllers anyway - HMD data is used as is, unless you specifically want to (physically)torture your players.
Porting has been 'easy' for the entire 6 years of modern VR. All SDKs(6+ of them over the years?) are 'roughly' inter-changeable when it comes to base functionality. The tricky parts are pretty much exclusively around user-interface specific APIs and latency/display optimizations (which are indeed handled somewhat different from one vendor to the next). Of course there's a fair amount of difference between 'porting' and 'backward compatibility', but I discussed the relevant points in early post so I won't repeat myself.
If VR vendors forced that responsibility onto applications, VR would be in a much, much, much, MUCH worse state than it is today (or it'd be dead... already... again).
Of course it will, it's an inside-out tracking HMD - having a built-in camera (several of them actually) is how these work.
Honestly the screenshot in question brings the more relevant question if 'controllers' will be BC, because while glow-sticks can be relatively well emulated, there's a lot of PSVR games out there that were built around DS4 (and it's fundamental to the experience, not optional, in a number of them), and I don't think there's any good way for headset to track a DS4 (or DualSense for that matter).
Obviously there's no replacements for the gun accessory either, although that 'may' be trackeable from the HMD. But if they did that - they might as well track Moves as well... It gets kind of fuzzy at that point. Sony's always had a good track record with maintaining compatibility of controllers across generations, but VR is uncharted ground here...
Last edited:
Perrott
Gold Member
We'll see, but I don't think this is accurate.
It reads more like speculation on the verified Era member's end, because he works at Sony and he has never unveiled internal information publicly before, so I doubt he's talking based on insider knowledge as by doing so he'd be putting his career in danger.
It reads more like speculation on the verified Era member's end, because he works at Sony and he has never unveiled internal information publicly before, so I doubt he's talking based on insider knowledge as by doing so he'd be putting his career in danger.
Romulus
Member
Even if it's just the more prominent games are BC, this is a huge deal. Most likely the controller-supported games will get patches and that's a huge chunk. Heavy hitters like RE7, Wipeout, Astrobot, Star Wars Squadrons will be at least playable at higher visual settings. Even stuff like Skyrim, Doom, and Borderlands 2 shouldn't be a problem.
The good thing is a lot of potentially great PSVR games were hampered by things PSVR2 could remedy, so if patches are in order, it could be a gamechanger. For example, Hitman. I really enjoyed it and it's exponentially better in VR, but the controls take some practice and aren't perfect.
The good thing is a lot of potentially great PSVR games were hampered by things PSVR2 could remedy, so if patches are in order, it could be a gamechanger. For example, Hitman. I really enjoyed it and it's exponentially better in VR, but the controls take some practice and aren't perfect.
Last edited:
Kokoloko85
Member
It would be pretty stupidif they don’t. VR needs as many games as possible especially for new comers to PS VR2 who will have a bunch of PSVR 1 games to play
Tripolygon
Banned
That is an OS function to ensure tracking accuracy.
IntentionalPun
Ask me about my wife's perfect butthole
Yeah I think you are wrong. The games aren't all coding their own tracking implementation; they aren't all figuring out how to track the bright move controller balls.
That's what the SDK would do, built by Sony.. and they'd be fed the motion data.
I am a software engineer
There's no reason to think that games would care what is creating the motion data, if anything PSVR2 would just increase accuracy.
It's why VR games being "exclusive" to one headset or another on PC is obnoxious, because there is no real technical justification for it. It's like being exclusive to a mouse.
Last edited:
Gamerguy84
Member
So how will the 20 degree wider FOV work out?
sncvsrtoip
Member
yeah still they have to figure out how to translate inside out to outside in tracking for bc and lack of dualshock 4 in ps5
Tripolygon
Banned
All the game needs are the location of the hardware. The game is not doing the tracking, that's the os doing that and passing the information to the game.
sncvsrtoip
Member
I know but for example game expecting dualshock 4 movement in space, you can't do it with dualsense and psvr2 so they have to translate using new controlers tough game still thinks you use dualshock 4, imo not so trivial to do it without issues
Tripolygon
Banned
DualSense IMU is far more capable than DS4, and I feel like the light bar in front will play a role in tracking the DS using the PSVR2 inside-out camera. It is literally 2 strips on top of the controller clearly visible if a camera is on the HMD. My speculation anyway.
ManaByte
Gold Member
They'll track with forward facing cameras like the Oculus does.
mckmas8808
Mckmaster uses MasterCard to buy Slave drives
This is great news.
Reallink
Member
SteamVR/OpenVR acts as a translation layer for at least 3 completely different tracking technologies. Valve's Lighthouses (outside-in laser trackers), Oculus CV1 (outside-in camera tracking), and Quest/WMR/HTC/Varjo/Etc (inside out camera tracking). All the outside-in "PS Eye" and glowing balls on PSVR1 is doing is collecting X/Y/Z coordinates, same as the array of inside-out cameras and sensors on PSVR2. It should be trivial for someone with Sony's resources and low level hardware/software access to implement.
Last edited:
Tams
Member
It's not about VR vendors forcing that onto anyone (that would silly and self-defeating), but rather developers doing it themselves to, say, eke out that little bit more performance.
The thing about that is that it would require multiple, very unlikely circumstances to happen all at once (making it even more unlikely):
1) You'd need developer with clear knowledge of the tracking-overhead & insight that they can *meaningfully outperform the SDK.
*Substantial differences - not 1 or 2 fps more - noone would even consider what follows for that.
I've spent a fair amount of time with early evolution of modern VR, with launch titles across multiple platforms, and I'd be hesitant to say I could answer that question positively. Even though especially on PCs of the time (2016) - the SDK tracking overhead was really substantial (easily in the realm of 10% of the frametime available). We never saw that problem on console though, thanks to async-compute and SDK not being behind API walls that made a lot of things difficult/hacky in those days on PC. Not saying it's free - but it never came up on profiling as anything worth worrying about.
2) You'd need said developer to have someone on staff with significant experience working with sensor fusion and image processing/analysis - because we're literally talking about rewriting the tracking stack.
This isn't unheard of - but it's nonetheless rare enough that you remove 90% of developers out there by default to even attempt this.
3) You'd need to find a way to bypass TRC violations 2) would inevitably trigger.
I've been on that side of the fence, and yes there are stories I could tell about certain things being 'possible', but nothing even remotely on the scale of what we're talking about. We're talking substantial risk and I have no idea if it can even be pulled off (nevermind TRCs, just integrating with the rest of stack without everything falling apart would be a minor miracle). Moreover, getting caught would mean throwing out all the work from 1) and 2).
4) You'd need to convince your management that investing in 1-3 (we're talking multiple man-years of investment here) is both somehow more worthwhile than anything else you could spend that $/time on, the risk of it all being thrown out in 3) is acceptable, and figure out a way to work that into your project schedule somehow without multiplying your development time.
Good luck with the above given VR budgets have been incredibly hamstrung for vast majority of projects, including 'AAA' ones (especially 'AAA' ones actually).