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.
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.
The first important change is the new home of AnKi. From now on AnKi’s source code lives on github and the address is https://github.com/godlikepanos/anki-3d-engine. 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.
AnKi supports a new modern effect for realtime reflections. Enjoy the video:
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.
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.
Linux, or GNU/Linux as some people want to call it, was born 20+ years ago as an open source desktop operating system and despite its massive success on super-computers, servers, embedded and mobile devices it didn’t manage to gain the same traction on the space that was bred for, on desktop. Many people gave valid arguments on why desktop is a hard market to conquer but deep down I believe that video games is one of the most commonly desired features of a home computing system. Despite some notable efforts over the years Linux gaming never shared the same love as Windows PC gaming and console gaming but that may come to an end mainly due to Valve’s efforts to steer developers and gamers to Linux. As a Linux (game) developer for the past 6 years I think I can shed some light on the pros and cons of that system and who knows maybe some people will find this reading useful.
To be able to see and understand the big picture of developing on and for Linux we first need to identify the smaller areas that compose it. Things like tools (compilers, debuggers, libraries), hardware abstractions (graphics and sound APIs) and finally maintaining multiplatform capabilities are some key elements of that process. Keeping the multiplatform aspect of things in the back of our head is an interesting and sensible thing to do mainly because with careful planning and not that much effort a Linux application can be ported to other operating systems where the opposite may not be that easy.
In this article we will be discussing the whys and whats of the new AnKi texture format. First we will try to shade some light on the current texture formats and what are their limitations and later we will present the ankitex format in detail and how it solves these limitations.
The first thing we need do is to shed some light on OpenGL hardware, OpenGL drivers and how they need their textures served.