I need to figure out what exactly it does before I can say something in regard to its feasibilty for vorpX.
Right now I can only speculate: might either be based on using depth-buffer information, which would be good, as vorpX already extracts it for Z3D in most games. Might also be based on interpolating geometry directly – which seems more likely. That wouldn’t be easily usable with vorpX. We’ll see.
First impressions after toying around with this for an hour:
1. Do not use ASW with the current release version of vorpX: doing so will result in heavy judder, probably what Laser meant by running very bad. Might be due the last release version being compiled against an older SDK.
2. With the current dev version there is no such issue and there are improvements in low frame rate situations, but don’t expect too much. You still will absolutely want to get 45, or better 90 real FPS. Once a game can be locked to steady 45fps everything is really smooth, although I’m not really sure whether I would call the difference revolutionary.
Once a game can be locked to steady 45fps everything is really smooth, although I’m not really sure whether I would call the difference revolutionary.
So the spacewarp should work similarly with vorpx than with native games? Maybe not revolutionary but it is allmost essential with heavier games, and while it can have some artifacts from it its better with it enabled than disabled.
I’m not really sure whether it does 100% the same as in most native games. vorpX for a bunch of reasons works quite different from native apps as it renders the game on one thread and then pushes the frames to the headset on another thread. With both threads locked to steady 45fps the effect theoretically should be the same as far as ASW is concerned, but I have to do more testing beyond the one hour I spent with this yesterday before can give a really qualified answer to that question.
Personally I wouldn’t call it almost essential, but that might be a matter of perspective.