Updating external libpng download url in dependencies cmake script

* appears to have been moved to "history" folder
* this is not yet reflected on the main libpng site, their links to this mirror are broken as well
* the 1.5.11 release appears to be the new stable, but this has not been announced on the libpng site yet
Added winxp/vista fallback for multitouch functions

* the "GetTouchInputInfo" function in "user32.lib" is only available on windows 7 or greater, see: http://msdn.microsoft.com/en-us/library/windows/desktop/dd371582(v=vs.85).aspx

* polycode will still build on winxp, but any code that uses it fails at runtime with the error: "The procedure entry point GetTouchInputInfo could not be located in the dynamic link library user32.lib"

* using a preprocessor directive wouldn't be helpful here, as that would require always building two release of polycode and any games that use it (one with multitouch support and one without)

* instead, we can check for the existence of any multitouch functions at runtime and fall back to null behavior if they are not available, as described here: http://msdn.microsoft.com/en-us/library/ms683212(v=vs.85).aspx

* removed WINDOWS_TOUCH_SUPPORT preprocessor directive

* added initTouch() for determining multitouch support at runtime

* added check to handleTouchEvent() to return immediately if multitouch is not supported (this may be not be needed, as multitouch events probably won't fire on a system that doesn't support it, right?)
Fix for multiply defined symbols fatal error in polyimport.cpp on win32

* the assimp libraries appear to be compiled with zlib support already, so including them again when linking polyimport results in a multiply defined symbols error on visual studio 2010

* removed zlib from the list of link libraries for polyimport on win32 only

* not sure if this needs done on other platforms or not

* verified that polyimport.exe still works after this tweak

* full text of error:

assimp.lib(inflate.obj) : error LNK2005: _inflateInit2_ already defined in zlib.lib(zlib.dll) [Polycode\Build\Tools\Contents\polyimport\polyimport.vcxproj]
assimp.lib(inflate.obj) : error LNK2005: _inflate already defined in zlib.lib(zlib.dll) [Polycode\Build\Tools\Contents\polyimport\polyimport.vcxproj]
assimp.lib(inflate.obj) : error LNK2005: _inflateEnd already defined in zlib.lib(zlib.dll) [Polycode\Build\Tools\Contents\polyimport\polyimport.vcxproj]
Polycode\Build\Tools\Contents\polyimport\Release\polyimport.exe : fatal error LNK1169: one or more multiply defined symbols found [Polycode\Build\Tools\Contents\polyimport\polyimport.vcxproj]
Sound duration and position getters
Added TYPE_UNCAPPED_CYLINDER scene mesh type
Fixed soundmanager crash on winxp, upgraded to openal-soft 1.14

* there is an issue with openal when statically compiled on some win32 platforms, in which the openal dll is unloaded before the public destruction methods can be called (this looks to be a flaw in the original openal spec)

* when this happens, openal crashes on application exit, as it tries to free memory that has already been freed during the dll unload and its own internal cleanup routines

* this always happens on winxp, sometimes on vista, and never on windows 7 (from a cursory google search)

* one workaround is to just not use any of the public destruction methods, and hope openal cleans itself up using its internal "atexit" cleanup routines (though this seems unwise)

* this was fixed in openal-soft 1.14, by making sure the handle to the dll stays open until the application fully exits when openal is statically compiled.  see: http://repo.or.cz/w/openal-soft.git/commitdiff/1a4a0abd1a1fd9a20345db54efef6587bec67197

* now when you call the openal destruction methods from soundmanager (alcCloseDevice, etc) they actually kick off destruction instead of just silently failing or causing a crash (depending on the system)

* added check to soundmanager destruction method to make sure a context exists before trying to destroy it (in case openal init failed and we never created one)

* added call to set "alcMakeContextCurrent" to null before destroying the current context, as per openal spec
Adding winmm and ws2_32 system libraries to default win32 c++ template

* winmm.lib (multimedia) is required for joystick related functions

* ws2_32 (winsock) is required to initialize sockets

* if not included in the additional dependencies section, the following functions cannot be resolved:

Polycore.lib(PolyWinCore.obj) : error LNK2001: unresolved external symbol __imp__joyGetDevCapsW@12
Polycore.lib(PolyWinCore.obj) : error LNK2001: unresolved external symbol __imp__joyGetPosEx@8
Polycore.lib(PolyWinCore.obj) : error LNK2001: unresolved external symbol __imp__joyGetNumDevs@0
Polycore.lib(PolyWinCore.obj) : error LNK2001: unresolved external symbol __imp__WSAStartup@8
Template\Release\PolycodeTemplate.exe : fatal error LNK1120: 4 unresolved externals
Added new "Polycode.props" file to default win32 c++ template

* This property sheet file contains common defaults for building a polycode project

* Now, a user can just load the Polycode.props file in a fresh visual studio project and get a lot closer to building with fewer manual steps

* Added "PolycodeDir" variable to Polycode.props that can be pointed at the installed polycode framework directory.

* This currently points to the same relative path that the old template did, need to find a clean way to let users override this.  Environment variable?  One of the manual steps when setting up a new project?  Some voodoo to find the current polycode install dir?

* The "VC++ Directories" config now live in Polycode.props, and are relative to the "PolycodeDir" variable.  The proper include and lib dirs will now inherit by default in a new project.  This wouldn't be possible if polycode was still installing to seperate Release/Debug dirs (maybe it is supposed to and the cmake defaults in git don't do this?)

* Added user variables for the static libraries needed for both Release and Debug targets.  All libraries are then rolled up in to a single "PolycodeLibsDebug" and "PolycoreLibsRelease" variable, which the user will need to manually add to their "Linker/Input" properties.  This is the only manual step required on a fresh visual studio project.

* The static library variables are as follows:

  * PolycodeLibs[Debug|Release]: Shortcut to all below libraries
  * PolycodeCoreLibs[Debug|Release]: The polycore library
  * PolycodeDependLibs[Debug|Release]: All dependency libraries (freetype, libpng, etc)
  * PolycodeWinLibs[Debug|Release]: All windows libraries needed by polycode (opengl, glu32, winsock, etc)

* Added "WIN32" and "_WINDOWS" preprocessor definitions to Polycode.props, so that all projects will pass those on.  Now, only "_DEBUG" and "NDEBUG" are left configured in the Debug|Release targets, and I assume the user can safely leave those out?

* Added "Windows" as the default subsystem to use for linking to Polycode.props

* Added the following other misc configs to Polycode.props, not sure if these should be there or if they just happened to be helpful common defaults in the current template solution:

  * Compile/Warning Level: Level3
  * Linker/Generate Debug Info: True

* Set all of the above configuration values to "inherit" in the project solution (as they would be in a vanilla project) and left behind only the existing tweaks unique to Debug|Release targets.

* TODO:

  * Better way to get PolycodeDir?

  * Verify whether or not the new polycode release will push to discrete Debug|Release dirs for the lib and include directories?

  * Custom post-build step to always push pak and dll files to project Debug|Release build dirs?  (This would cut down on forum posts from people who forget to do this, and could be disabled by anyone who wants to do this themselves or use an alternate dll etc)
Added post-build script to copy pak and dll files, fixed PolycodeDir variable

* Tweaked PolycodeDir variable so that it matches visual studio conventions (includes a trailing slash)

* Added post-build event script to copy default.pak and hdr.pak if they don't already exist in the solution directory

* Added post-build event script to copy the release or debug openal32 and zlib dlls to built target directory if they don't already exist
Slight material speed improvements and additional sound stuff
Merge branch 'master' of github.com:ivansafrin/Polycode
Fixed a stupid mistake
Merge pull request #115 from dannywarren/openal_exit_crash_fix

Fixed soundmanager crash on winxp, upgraded to openal-soft 1.14
Merge pull request #113 from dannywarren/polyimport_assimp_symbols_fix

Fix for multiply defined symbols fatal error in polyimport.cpp on win32
Merge pull request #112 from dannywarren/multitouch_winxp_compatibility

Added winxp/vista fallback for multitouch functions
Merge pull request #111 from dannywarren/4cff0b458f

Updated external libpng download url in dependencies cmake script
Merge pull request #116 from dannywarren/win32_cpp_template

Improvements to win32 c++ template
Fixes for new AppStore XCode, updated year in license, added icon to template
Fixes for binding build on Mac OS X, removed lua files from repo
Require CMake 2.8.8 due to new Xcode