Vita is the logical amalgatmation of many related and dependent codebases, primarily written in C++ and C#.NET, which are produced and developed by Kornner Studios.

Vita began as a closed source project back in November of 2009 (so we predate the PS Vita). It wasn't until the beginning of 2014 when it was transitioned to an open source product. This is currently an ongoing task, not everything has been transition over to the open source repositories yet.

Etymologically speaking, "Vita" is the Latin word for "life". If you're reading this, then it is very likely that coding is a part of your life, as it is to Vita's developers.

KSoft is the codename of the C#/.NET-centric part of the Vita codebase.

Specifically, you're viewing the "KSoft.BCL" (Base Class Libraries) repository. This embodies many generalized systems that we have developed to supplement our specialized projects (which are located in external repositories).

Some are open source (eg, KSoft.Blam, for targeting the Halo engine), some closed (eg, KSoft.XDK, for targeting multi-generation Xbox Development Kits). This is part of the reason for not messing with sub-modules or the other such source-control mechanisms, but also because the developer writing this isn't experienced with such setups :o)

The default license of Vita projects is the MIT License

The BCL aims to provide a compartmentalized framework which provides functionality not present, or at least efficiently, in the .NET framework proper.

Compartmentalized in that non-critical systems like KSoft.Security are outside the actual root assembly, just named "KSoft".

Example functionality which you can't find in the .NET framework is a BitStream class. We also provide utilities for treating and using Enums as actual bit flags, in an optimized and complete manner.

We're also very, very reliant on using T4 Text Templates to generate most code which would otherwise be copy and pasted to fit the context of like-wise types. For example, our static KSoft.Bits (located in KSoft's Bitwise folder) class uses a single T4 template to generate the BitCount() method for the usual unsigned integer types (UInt32, etc)

You will actually be hard pressed to find a decent, comprehensive BitStream class for .NET anywhere on The 'Net. The most comprehensive one that I know of is featured in a CodeProject article. To compare the two:

• They require a complete, internal copy of the stream's bytes; KSoft supports actual streaming (using a BaseStream) and use a configurable (at compile time) cache 'word' (32 or 64 bits) where bits reside until being flushed to the BaseStream

• They were last updated in 2005 and have unpatched bugs; KSoft has a tried and tested class. Tested in both regular use and with Unit Tests to validate core operations. A patched version of the article is used in our Unit Testing to check compatibility

• They have a #region infested, monolithic .cs file; KSoft makes use of partial classes and code generation using T4 to keep the files bite-sized and copy&paste code to a minimum

The .NET framework offers a Enum.HasFlag() object method which you can use to test that an enum. Unfortunately, that method is far from efficient.

Using code generation (via Linq Expressions), we're able to address the inefficiencies found in .NET's Enum.HasFlag(). We don't perform any boxing and can operate on the underlying type (ie, integer) of the enum instead of using UInt64 as a catch-all.

We take this one step further still and provide functionality for Add, Remove, and Modify as methods. What's great about this is that you're able to add a new semantic level to bit flag operations in your code, instead of bleeding your enum values together with the normal bit-wise operators.

If we so desired (and we presently don't), we could even modify the code generator to add checks to DEBUG assemblies that validate the flags being used in bit operations (Test, Add, etc) have named members in the enum type.

If there are other .NET languages which don't (easily) offer bit flag operations on enum types, I'm sure our utilities would prove their use once again in adding such support.

Before you try building any of the projects, first read the requirements you may need.

KSoft.T4 should always be the first thing that gets built. It's the meta assembly used by many of the T4 documents that are found in all the other assemblies. It's only needed when building projects, not at runtime.

NOTE: The BCL contains some C++/cli projects, which cause the 'Win32' Platform to be defined. The only projects that get built with this active platform are these C++/cli projects. Instead, you should opt for the 'x86' Platform which will also build the .NET assemblies. Long story short, don't select 'Win32' for your active configuration.

However, at the time of this writing these C++/cli projects haven't been populated with meaningful code, so you're currently safe just building for 'Any CPU'