Forum Replies Created
-
Posts
-
Ralf, from one developer to another: small, timely updates keep the community interest in your software high.
We should all be here to talk about how awesome VorpX is, but instead, it’s been 9 months since we had even a minor update, and we’re all on the spectrum of impatient and pissed off.
it’s not just DK2 support people are impatient for – it’s all of the small features and everything that has been promised. You’re bundling too many features into each update. From what I’m reading, this update will include DK2 support, DX11 geometry support, lots of setting changes, fixed shaders in Skyrim, an automated licensing solution, and probably more that you haven’t mentioned. That is just NUTS. Hell, I’d be happy with the letterbox rendering changes only, which were supposedly resolved 4 months ago. Why do I have to wait for DK2 support for that fix? You’re trying to be Internet Explorer when you should be Chrome. Change your dev cycle to release small features silently and very often. It minimizes risk for you, keeps your community engaged and happy, and shows that you are constantly working on our investment.
I’m looking at purchasing VorpX and the fact that the last update was so long ago was what made me hold off. A history of updates on a steady tic is totally what inspired confidence in a purchase — even if the updates are very small.
Alternatively an unstable branch that showed changes over time would have probably sufficed.
This probably makes your development life a tiny bit more complicated in that you’d maintain a separate branch for the biggest changes, but as someone who started doing that in my own stuff I’ve found that the extra discipline and organization this imposes is actually improving the final output of my work.
I was reading this Oculus review and I noted this:
The Rift (or rather its SDK) does lens correction via post-processing. First, the virtual world is rendered into a “virtual” camera image, which is then resampled using a simple radial undistortion formula based on a quadratic polynomial. The fundamental problem with this approach is that it has to resample a 1280×800 pixel image into another 1280×800 pixel image, which requires very good reconstruction filters to pull off. The SDK’s fragment shader simply uses bilinear filtering, which leads to a distinct blurriness in the image, and doesn’t seem to play well with mipmapping either (evidenced by “sparkliness” and visible seams in oblique textures). The SDK code shows that there are plans to increase the virtual camera’s resolution for poor-man’s full-scene antialiasing, but all related code is commented out at the moment.
How does VorpX do this? Can you do better than the SDK here?