Main goal of the KiloEngine project is providing easy-to-use but featureful C++ multimedia support SDK.
Unlike many other projects KiloEngine aims also to provide fully abstracted OpenGL 3.3+ based 2D Game Engine for beginers and pure convience.
The project is written mostly in basic C++03 and newer code features.
To get hang of the status of this project I counted few magnitudes of the source code:
The KiloEngine source code has accumulated slowly over the years and is now over approx ~180000 LOCs in 795 files! For comparison with same ad-hoc counting SFML 2.4 is approx ~110000 LOCs in 445 files. Oops. :D and KiloEngine does not even have NetworkSubSystem nor AudioSubSystem yet! Bummer, but this will hopefully change.
Kind of advantage that KiloEngine currently has is that it is still in draft-phase development and yet it already has tons functional features. You can help me (JATothrim) to reach the things you want the KiloEngine to do for you!
If you any any questions about this project please just ask on the facebook page: https://www.facebook.com/KiloEngine/
Main features are:
- CMake build system.
Copy-Pastable dependencies directory.
Low-level cross-platform system API (Memory, Thread and IO Management)
KiloEngine provides some basic Memory and Threading managment with BaseCore to abstract away platform C++ standrad library differences.
E.g. ksMalloc, ksFree for memory allocation, ksMutex,ksConditionVar for thread syncronization and ksThread for thread creation.
High level Thread managment system.
Register ThreadTask instances that make your class instance launchable in thread.
Non-intrusive and fast OpenGL 3.0+ and up window management with robust multi-context + multi-thread support.
KiloEngine supports all modern OpenGL functionality with very flexible windowing API.
The OpenGL API context is handled explicitly by the "WindowSubsystem" and the API has quite good multi-display support.
The gl3w OpenGL extension loader inspired gl3w_mod generates OpenGL API definitions on build time for up-to-date OpenGL functionality support. gl3w_mod is built-in to the rendering context managment code. Opening fully OpenGL 4.5 capable window is just few lines. The windowing code is very simple to use and yet it can do all things the lower-level API can that it simplifies. With cross-platform support! (After Linux port) Windowing code is partly transtparent so you can hook into it: get raw win32 HWNDs or (after Linux port) xcb_connetions and other implementation detail.
Fully multi-threaded: KiloEngine based Applications can feel snappy because slow OS API is handled in dedicated GUI thread.
Queue + Event-based Input system.
Events are retived from a queue per window or source device.
Event arrival and retirement is tracked with timestamps.
Stable HID-SCANCODE based KeyLabels.
Additionally the "current" state of input devices e.g. mouse, keyboard and other Buttons can be actively polled.
OpenGL C++ rendering component kit: Get full 3D rendering app running easily without ever touching the raw OpenGL C API!
- KiloSprite 2D game rendering engine for begingers and convience.
Overall The Engine basic utilities bring up immense ease of writing and prototying C++ code.
It does the boring stuff for the developer.
I have seen C++ projects where you have no clue what does that and this - there is no explanation inthe code.
The KiloEngine source code is very verbosely commented, nearly every function and class definition has explanation what it does and why. Some times too verbosely.
Another complete mass of code is the KiloSprite 2D Hardware-Accelerated Graphics and GameEngine. The KiloSprite can render thousand KILOs of sprites with OpenGL shader based Materials. It uses all OpenGL 3.3 features from VBOs, FBOs, GeometryShaders to TrasformFeedback. Hence the name of the project: KiloEngine.
I'm also excited about the Khronos Vulkan Graphics API. KiloEngine should definetly provide support for it.
The project code is divided into library/ helpper project to build third party dependencies like-boost, the main project source is located in kiloengine/src and project testing code in enginetests/.
The library project is builded and installed once after the project repo has been cloned with commands
hg clone https://JATothrim@bitbucket.org/JATothrim/kiloengine hg update draft_nocxxnew
Note that the mercurial repo 'draft' branch is usually unstable (may not even compile) at tip so see specially tagged versions for more stable functionality. I resently cleaned the repos obsolete branches so that only two remains: draft and draft_nocxxnew. draft branch includes all bleeding-edge code and features integrated while draft_no*** branches exclude some work-in-progress functionality. The draft_nocxxnew does not fully replace C/C++ global heap functions, but still provides ksMallocAlign, ksMalloc and ksFree.
After cloning and selecting stabeleyish version, build the libray project. The library CMake build script will require at least: boost version 1.61, Eigen 3.2 and Python 3. I suggest using non-GUI-based generator/build-system in CMake. The library sub-project will install into SUPER_INSTALL_DIR which is by default: '../extlibs/'
The draft_nocxxnew does not include the KiloHeap global memory allocator system. It should be more stable than the draft branch.
Next, CMake-gui is started and kiloengine/src project is configured. SUPER_INSTALL_DIR is required to set into same value as in previously builded library project.
Then select what KiloEngine components to be builded with BUILD_KILOxxx prefixed boolean vars. Defaults are usually okay.
After satisfied with the settings hit generate in CMake-gui.
NOTE: Currently KiloEngine can't be builded with any Microsoft Visual Studio compiler. MSVC compiler C++11 support is simply broken.
I have written a Precompiled headers feature for KiloEngine. It is very experimental and may be unstable. It can be enabled by toggling off CMake option PRECOMPILE_DISABLE_ALL and toggling on PRECOMPILE_xxx options like PRECOMPILE_KiloEngineCore. If for some reason Header precompilation breaks just reset it by toggling PRECOMPILE_DISABLE_ALL on and reconfigure the project. Speed-up depends on the compiler. MSVC has very noticeable speed-up and gcc may not work at all. Clang is not supported.