Add '.gitignore'.
Create and add '.gitattributes'.
Add an empty project file to house code.

As well as creating a blank Visual Studio project file '.gitignore' and
'.gitattributes' are both modified to modify the way Git interacts with
the project and any extra generated files.
Modify project properties.

Modifications include the following:

 - Create a 64-bit configuration so that the project can be deployed on
   both 32- and 64-bit platforms;

 - Add the folders 'bin', 'include', 'lib', and 'src' to the build path
   of the project;

 - Remove all libraries that are included by default by Visual Studio;

 - Force output of all warnings generated by the compiler and move to
   make all warnings of both the compiler and the linker errors;

 - Distance the project from .NET Framework libraries by disabling
   run-time options and run-time extensions;

 - Disable exceptions and run-time identification because they are
   unlikely to be used in the near future;

 - Generate XML documentation files;

 - Enable code analysis using recommended native rules.
Create and add an entry point to the project.

This can be found as 'WinMain' in 'src/winmain.c' on line 7.

The generation of documentation (using '/doc') is also disabled because
of the inability to ignore command-line warnings (specifically 'D9035').
Create a method of demonstrating project version.

Making use of resource files, and standard headers it is possible to
segregate the counter for the version components and file read by Visual
Studio ('ocarina.rc') to embed the version into the generated
executable.
Add an icon to be embedded into the executable.

The current file is simply a place holder until a later period in time.

The icon is part of a pack that was compiled by KlydeStorm on deviantART
(the pack can be found here:
http://klydestorm.deviantart.com/gallery/#/d2ze9gi). Specifically the
file used is "Ocarina of Time.ico".
Define the macro 'NDEBUG' during release builds.

'NDEBUG' is listed by the C and C++ as a define that controls the
behaviour of the function 'assert'. Within release builds it isn't
desired to immediately bail upon an issue and so 'assert' is disabled.
Define macros to differentiate between builds.

The macros 'OCARINA_DEBUG_BUILD' and 'OCARINA_RELEASE_BUILD' are defined
during their respective builds.

Preferably it would be better to only refer to debug builds for
simplicity in source code however, in the event that other builds are
created it could be useful to refer to only release build(s).
Update 'ocarina.rc' to differ based on builds.

Also, remove the unnecessary redefinition of 'VS_VERSION_INFO'. It is
already defined via 'windows.h'.
Fix missing build macros when compiling resources.
Swap from include guards to 'pragma once'.

From a purely standard-compliance perspective this is a bad idea.
However:

 - The code base is written completely with Visual Studio's compiler in
   mind;

 - There are already pragma pre-processor statements that are specific to
   Visual Studios compiler anyway;

 - A large number of compilers support pragma once anyway; and

 - It may improve compile time in the long run.

And from a really nit-picky point of view not using include guards
prevents the IDE explaining that there is a random definition of a
constant in the object browser.
Make a formatting modification to 'src\winmain.c'.
Remove disabled warnings around 'windows.h'.

Rather, prefer to just drop the warning level to a value that means that
the header will actually compile. Such a construct looks neater and is
simpler to understand.
Begin work on an internal version tracking system.

Because the project's version is tracked using Semantic Versioning the
it makes sense to create an internal representation of this as well.
Remove unnecessary name addition to class scope.
Create a method of accessing version components.

Because version components are stored in an array of characters inside a
union (this is done to simplify direct comparisons between objects) it
is slightly awkward to access to individual components.

The definitions 'm_ma', 'm_mi', and 'm_pa' are used to hide access
complications through being false members. Through a series of macro
definitions it is possible to account for endianness
(http://en.wikipedia.org/wiki/Endianness) without slowing access times.

If all is correct, the only drawback to this method (opposed to relying
on three separate data members is the artificial limit of 2^CHAR_BIT - 1
on each component and a single byte that is never used.

The function 'm_SetVersion' is a helper function that should be used in
shared initialisation steps of each constructor.
Strip out and reconstruct 'SemVer'.

During attempts to write a complete set of special member functions
(according to section 12 of ISO/IEC 14882:1998) for 'SemVer' it became
apparent that previous work created a structure that was hard to work
around.

In the interests of writing more robust code over micro-level
optimisations 'SemVer' has been rewritten in a simpler way.
Allow the game to access its version information.

The function 'Ocarina::GetCurrentVersion' provides and interface with
the lower level pre-processor definitions that are used for the
generated executable's meta-data.
Bump the version number for the Deku Baba release.