Game level video demonstration

A demonstration of moving around in a real game level. Actually this is a small part of a bigger level. The complete level may be released at some point. Enjoy the video:

PS: Music by almighty Varathron.

Posted in Uncategorized | Tagged | Leave a comment

Squashing bugs in AnKi

There are some universally accepted truths in software and one of those truths is that all software has bugs. Some people are more careful than others but nobody is perfect and nobody can write 100% bug free code. Another truth is that hunting bugs is rarely a fun job. It shifts the focus and sometimes it forces a mental context switch (graphics guys know that context switches can be slow). I always considered AnKi as a playground. A codebase where I can experiment, learn and have fun. Since the inception of AnKi I knew that bugs and debugging in general will spoil that fun so I had to find a way to have a robust codebase so I can focus on the fun parts. I think to some degree I’ve managed to avoid the endless pains of debugging by using the tricks I’ll describe in the following lines.

The first and, in my opinion, the most powerful tool against bugs is the almighty assertions. AnKi has a ton of assertions. To put it into perspective, there are 852 assertions throughout the code and it’s roughly 1 assertion every 84.8 lines of code. Some subsystems like util (AnKi’s equivalent of STL) have to be extremely robust so this particular subsystem has 1 assertion every 37 lines of code. In practice AnKi almost never segfaults when assertions are enabled. In the majority of cases an assertion is triggered and finding out what’s wrong is a mater of minutes.

Another thing I’ve tried early on and improved over the years is based on the idea that the commonly used subsystems have to be as robust as possible. One of these subsystems is util (contains a list, something like std::vector, hashmap, memory management, strings and other). Util is a widely used subsystem and it’s extremely important to be reliable. As I mentioned earlier, util is rigged with assertions. On top of that there are quite a few unit and performance tests. So unit tests is another weapon against bugs. In AnKi’s case unit testing is not that excessive but they cover some commonly used cases.

AnKi loves wrappers. To protect against common mistakes there are some wrappers that have debug capabilities. One example is anki::Array (something like std::array). anki::Array wraps constant size arrays and it asserts on out of bounds access (unlike std::array). Also, there is SArray that is constructed using a pointer to some memory and a size. SArray will also assert on out of bounds assess. These wrappers, and more, ensure that stupid mistakes will be caught.

The last weapon is the excellent valgrind and more precisely valgrind’s memcheck tool. Once and a white I run a demo on top of valgrind just to make sure that everything is in order. There were some occasions where all of the above methods failed but valgrind found the culprit. Unfortunately in complex workloads valgrind can be quite slow.

Of course C++ bugs are not the only source of bugs. Half of the bugs in AnKi are graphical glitches and rendering problems. Graphics related bugs heavily depend on the GPU and the driver and debugging those can be painful. Spending a whole week debugging can be kind of painful. There are some tools that help graphics related problems but those will not be covered by this article.

To sum up, what worked for AnKi is tons of assertions, robust core subsystems, some unit testing and quality code.

That’s all for now.

Posted in Uncategorized | Tagged , | Leave a comment

Status report: Demo, physically based rendering, cluster based deferred shading, preparing for Vulkan

It’s been a while. AnKi’s development is continuing with some slowdown (I am a dad now). Some of the new features that landed in the codebase since the last update:

  • Physical based rendering. Seems everyone is using it and now I can understand why.
  • Cluster based deferred shading. Changed the (CPU hybrid) tile based with a brand new one that divides the space into clusters. It’s CPU hybrid once again. Avalance is (was) using something similar.
  • Added tone mapping with eye adaptation.
  • The lighting is fully HDR now.
  • Added support for particles that react to lights. The new cluster based renderer allows me to do that which is pretty cool.
  • Reworked the graphics backend to make it Vulkan friendly. I’ll start with the Vulkan backend when the drivers become a bit more stable (now they are in early beta state).
  • Finally I worked with an artist for a few months to produce a game level. This level is helping me optimize the engine for real life scenarios. Ultimately I’ll produce a tech demo with it.

For the future:

  • Continue creating a UI library (boring).
  • Expand on a new idea for reflections.
  • Expand on a new idea for global illumination
  • Integrate Newton Game Dynamics even further (create joints and other stuff).
  • Start on the Vulkan backend.
Posted in Status Reports | Leave a comment

Vulkan: The next Khronos graphics API… that is not OpenGL

This year’s GDC proved to be quite exciting. New technologies, new ideas and some heavyweight announcements. According to the press one of the most exciting presentations was Khronos’ Vulkan API and the demos running on top of it. That really depicted the momentum, the support and the commitment behind the new API.

This article gathers all the publicly shared information behind the new API and adds some personal thoughts in the mix. The fact that I had the pleasure to follow the development of Vulkan API very closely (I was involved early on in the development of a prototype Vulkan driver for ARM’s GPUs) will give some credibility to my personal views. But that doesn’t mean that my views reflect those of my employer. So, whatever you read in the following lines doesn’t necessary reflect the views of my current employer.

Continue reading

Posted in Uncategorized | Tagged , | 3 Comments

Status report: github, OpenGL 4.4 and multithreaded renderer

The first important change is the new home of AnKi. From now on AnKi’s source code lives on github and the address is In the technical side of things there is a brand new OpenGL 4.4 backend with a multithreaded rendering thread. In this new concept there is a dedicated thread exclusively serving OpenGL work. Other small features are the screenspace local reflections effect, removal of C++ exceptions, some steps towards a complete removal of STL (new string, dynamic array etc).

For the future we have plans to add Windows support. Steps have been made with AnKi compiling on Windows. Unfortunately there are some bugs that we need to address before declaring full Windows support. Another planed feature is integration with Newton Dynamics physics engine. Compared to bullet Newton seems less buggy, with more features and the most important for me is that its interface is superior (a simple C API). Other small features is an improved tile base deferred renderer, improved transparency, cascaded shadowmaps, OpenGL ES 3.1 support and other.

Posted in Status Reports | Leave a comment

Screen-space local reflections

AnKi supports a new modern effect for realtime reflections. Enjoy the video:

Posted in Uncategorized | Tagged , | Leave a comment

C++11 spinlock

Apart from mutexes, spinlocks provide another way of protecting critical sections from multi-threaded access. Spinlocks perform the same job as mutexes but in a different way.

Continue reading

Posted in Uncategorized | Leave a comment

Porting AnKi to Android

After months of careful planning, reading the GL specs and waiting for Google to add OpenGL ES 3.0 support, AnKi was finally ported to Android. This article presents the result and briefly expands on the challenges of porting a game engine to Android. More precisely, there is a video showing a demo running on an Android tablet, the second is a pre-build .apk of that demo that you can download and install to your Android device and the third is a few thoughts on Android development and mobile GPUs.


The video is showing a flyby demo running on a Samsung/Google Nexus 10 tablet equipped with Mali T604 GPU. Please note that the demo is a bit slower because of HDMI. The resolution is 720p, the FPS (without HDMI) ~17 and the lights are in the worst case ~10.

Continue reading

Posted in Uncategorized | Tagged | Leave a comment