Blueshift is a high performance game engine written for the modern game industry. It must be held to high standards, as it will serve as the engine for Titan Interactive's flagship game, NoxAstra.
Kyle will stream Blueshift/NoxAstra development almost daily. There's no set time yet, so just check it out occasionally.
We have an IRC channel on irc.oftc.net at #blueshift. Drop by and say hi! If no one is around, anyone is welcome to ping kyle__.
Blueshift seeks to minimize dependencies in order to maximize portability and keep the codebase size down. Right now, we're using the following dependencies:
For all libraries with compiled binaries in the repository, one may expect binaries compiled for x64 systems in debug and release mode with MSVC 2015 build tools.
###64-bit Blueshift is currently 64-bit only. This might change if absolutely necessary, but it's unlikely. Most of the engine is optimized for x86-64 and wouldn't run very nicely on 32-bit systems.
###Code Style Blueshift's codebase exemplifies the best practices in modern C++. Everything must be exception-safe, const-correct, and free of memory leaks. Raw pointers are not shyed away from, but their use in the public API is minimal and ownership is well-documented.
For more information, see the Code Style file under Documentation in the repository.
###Coordinate System We're using a left-handed coordinate system where +X is to the right, +Y is up, and +Z is away. If the camera is moving in the positive Z direction, it is moving forward. The sine of a 45 degree angle up from the camera's Z axis is positive. Unreal Engine 4 is wrong. There is no debate. End of discussion.
###Matrix Operations Blueshift uses row-major matrices. There's no real reason to choose one or the other unless you're using plain old C-style multidimensional arrays (row major by specification.) Blueshift uses a C union to provide multiple ways to access the contained data, so row-major makes sense. Here's what our matrices look like laid out:
Index order:
0 1 2 3
4 5 6 7
8 9 10 11
12 13 14 15
This means the base vectors are laid out like so:
X.x X.y X.z 0 //right-vector
Y.x Y.y Y.z 0 //up-vector
Z.x Z.y Z.z 0 //forward-vector
P.x P.y P.z 1 //position
There is some confusion in how much this actually matters. The real answer is that it really doesn't matter that much, but it does carry some implications when dealing with multiplication order. Recall that matrix multiplication is not commutative, so a * b is not the same as b * a. Usually, you'll want to multiply a parent space by the local transform to get the local transform into world space:
Matrix4 world_transform = parent_transform * local_transform;
or
Matrix4 new = to * from;
###SSE Optimizations
One might also notice that the math library no longer includes any type of vector aside from a 4-component type, and support for double-precision has been dropped. Believe it or not, working with a Vector4 class can be much faster than a Vector2 even if you only need two components. The 8 wasted bytes are completely worth it; you can turn some 4-instruction operations into one using Blueshift's SIMD optimizations.
This optimization also filters into matrices, which use unioned Vector4s to perform some operations such as multiplication. Don't try to sidestep this; it will be slower.
If for some crazy reason your target CPU doesn't support SSE, you'll have to look elsewhere. There is no alternative code at this time. This might change in the future, though, as the API is written to fully encapsulate the optimizations in the cleanest fashion possible.
###Documentation We have automatically generated documentation here. It is generated using doxygen and is run every time a commit happens.