KiloEngine /

Filename Size Date modified Message
534 B
166 B
3.2 KB
267 B
1.3 KB
6.1 KB
1.9 KB
435 B


Main goal of the KiloEngine project is providing general purpose multimedia support like the projects SDL or SFML do. The project is written mostly in basic C++03 and newer code features.

KiloEngine is quite similar in goal to SFML but has major big differences. First of KiloEngine has features. Kilo-TONs of features. Very opposite of unfeatureful. The engine code is written so the developer using the KiloEngine does not have to invent or workaround it. KiloEngine is more flexible in how you want it to operate and provides lower-level API access in case it cannot provide features you want. It tries to be very unrestrictive how you use its components.

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 that may bump up LOCs yet more by 10000+

KiloEngine supports all modern OpenGL functionality with very flexible windowing API. The gl3w OpenGL extension loader inspired gl3w_mod generating 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.

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!

I'm really serious about designing the KiloEngine robust, fast as possible and most importantly useful as possible. The Engine basic utilities bring up immense ease of writing and prototying C++ code. I find it annoying writing any C++ code without KiloEngine help. It does the boring stuff for the developer. I have seen C++ projects where you have no clue what does that and this. 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. The engine even has fairly speedy global memory allocator (malloc(), free() realloc() family and C++ new and delete). It's main benefit is scalability on multiple cores and cache locality.

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.

Main features are:

  • CMake build system.
  • Copy-Pastable dependencies directory.
  • Low-level cross-platform system API (Memory, Thread and IO Management)
  • High level Thread managment system.
  • Non-intrusive and fast OpenGL 3.0+ and up window management with robust multi-context + multi-thread support.
  • 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.
  • In future: OpenAL sound support.

I'm also excited about the Khronos Vulkan Graphics API being materialized, since it may actually be able to kill the $M DirectX off. KiloEngine should definetly provide support for it.

Brief How-To-Begin:

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
hg update draft

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.