Visual Studio 2013, 3D SBS rendering and 2nd screen

[atlaste]

First and foremost:

• Added support for Visual studio 2013
• Fixed TR1 -> std. Modern compilers give conflicts with std:: and boost::
  when 'using namespace'.

I've also added 2 small features (you can find them if you search for 'STEREOGRAPHIC' and 'second screen'):

• a stereographic camera that renders 3D SBS images. Why stick to 2D images in a 3D program anyways...
• added support for using a second screen in Windows. Basically if you have a multi-screen setup, it'll use the second screen as a rendering target.

[c-lipka]

Please be aware that your attempt to placate VS 2013 regarding TR1 vs. std totally breaks compatibility with C++03/TR1, which is the language dialect we stick with for now. Therefore we can't pull your changes in the current form.

[c-lipka]

I suspect that your issues regarding TR1 vs. std can be solved as follows:

• In windows/povconfig/syspovconfig.h, remove the following lines:

  #include <boost/tr1/memory.hpp>
  

  and:

  using std::tr1::shared_ptr;
  using std::tr1::weak_ptr;
  

  Instead, add the following after the inclusion of the compiler-specific configuration (syspovconfig_msvc.h and its siblings):

  #ifndef TR1_MEMORY_HEADER
      #define TR1_MEMORY_HEADER <boost/tr1/memory.hpp>
  #endif
  #ifndef TR1_NAMESPACE
      #define TR1_NAMESPACE std::tr1
  #endif
  #include TR1_MEMORY_HEADER
  using TR1_NAMESPACE::shared_ptr;
  using TR1_NAMESPACE::weak_ptr;
  

• In windows/povconfig/syspovconfig_msvc.h, extend the test for MSVC 2013 as follows:

  #elif _MSC_VER >= 1900 && _MSC_VER < 2000
     #define COMPILER_VER                      ".msvc13"
     #define METADATA_COMPILER_STRING          "msvc 13"
     #define TR1_MEMORY_HEADER <memory>
     #define TR1_NAMESPACE std
  #else
  

While we're at it, please remove the tests you added for MSVC 2011 and 2012, unless you are familiar with these versions and know they don't need any special treatment.

As for the replacement of "boost::bind" with "std::bind", that one might need further investigation; as it is right now, it's a no-go as well.

[c-lipka]

Recent changes to the master branch might have fixed the namespace issue for good in an entirely different manner; could we encourage you to test it?

Some of the magic is in changes to the project settings, so you'll probably have to re-generate the VS2013 projects from the VS2010 ones again.