HN user
About a year ago I took a look at rust, but I didn't particularily like it. It enforces a single approach to programming stuff (which sounds an awful lot like the golden hammer antipattern) and lacked essential tools - notably an IDE, an actual debugger and profiling tools.
Also, for gamedev you'd pretty much need either directX or openGL bindings. And proper Windows support. I'm not sure where Rust stands on any of these things lately.
Well, I know for a fact that the Unreal Engine doesn't use STL. There used to be quite a large variance in the quality of any STL implementation and when you care about each single instruction that gets passed to the CPU, you turn a bit into a control-freak.
Some gamedev's also dislike interacting with STL code because of the metaprogramming in there and the associated error messages produced. Heavy template use makes compilation terribly slow, which is undesirable when you're trying to do a couple of quick iterations of code.
These are issues that can be avoided simply by just not using STL and templates in general, or very sparingly. The downside is that you need to roll your own of everything, with all of the bugs and devtime implied...
Pretty nice, although the library is a bit small for my tastes. No planes, no intersections... interesting, but I'd like to see a more complete feature set.
The DK1's resolution is way too low for reading large amounts of text, and I'm somewhat skeptical that the DK2 is good enough to be used as a monitor replacement.
Different applications that place less emphasis on text may be a better fit for VR - think photoshop and autocad for a start.
This is exactly the difference between VR and AR. With VR you yourself become convinced that you are present in a virtual reality, while AR convinces you that the virtual has a presence in reality.
Graphics programming for VR is only slightly more difficult than normal. Some screenspace techniques don't work as well, and everything is done in a stereo pipeline. The Oculus also requires some distortion and calibration of the distance between the eyes is very much preferred. Basically that's it.
Replicating the real world is still very far off, but there is an estimate where the resolution offered by the screen matches the average density of receptors in the eye. I don't recall exact numbers, but I seem to remember Michael Abrash having said something about it. Probably somewhere in the range of 8k displays per eye.
This reminds me of another DIY digital camera project based around the raspberry pi camera module - http://robofun.ro/create/the-sprite-raspberrypi-camera/