In my Porting AnKi to Vulkan post I went into detail describing how AnKi’s interfaces changed to accommodate the Vulkan backend and how this backend looked like. Eight months have passed since then and a few things changed mainly towards greater flexibility. This post describes what are the differences with the older interfaces, how is the performance currently and what new extensions AnKi is using now.
Short video of a test for volumetric lights. It is using the same information as the cluster deferred shading path. The shader iterates every cluster and samples at a random position inside the cluster. The result is too noisy at the moment, especially with shadows.
It’s almost 10 years of AnKi so I decided to to upload a very old snapshot of the engine I have lying in my hard drive. This early snapshot is a few years before I used any revision control. Browse the code here https://github.com/godlikepanos/anki-3d-engine-2007
Some interesting facts:
It started as a simple skeletal animation project and grow to what it is now.
Was featuring a blender 2.4 exporter for meshes, skeletons and skeletal animations.
It was running on OpenGL 1.1 with immediate mode.
The code is a weird mixture of (Microsoft-centric) C++ and C.
It was compiling only in ancient versions of VisualC++. Had to struggle to get it compile with GCC.
Different code style from what AnKi has now.
The first name of AnKi was Malice. Kept that name for a few months.
Someone once said “make it work, make it fast, make it pretty” and I’m happy (and at the same time relieved) to say that the effort of porting AnKi to Vulkan just hit the first major milestone! It’s working! I think this is a good time to share a few thoughts on how it was achieved, the pains and generally the overall experience. Disclaimer: Whatever you read in the following lines reflects my own views and not those of my current employer.
A few days back I decided to upgrade my Ubuntu 14.04 LTS to Ubuntu 16.04 LTS and the first thing I did, after the upgrade, was to re-build and test AnKi. Everything seemed to work fine except the fullscreen mode. In my dual-monitor setup and with 14.04 SDL was creating a fullscreen SDL_Window in my primary monitor and the second monitor was left alone. In 16.04 though the fulscreen window covered both the monitors and it was placed in a very odd position. This is the code I’m using to create the SDL_Window:
I spend quite a few hours trying to understand the issue and after some digging I found out that SDL was reporting only one display (SDL_GetNumVideoDisplays) with the resolution of my entire desktop. Obviously that was wrong. After trying different stuff I found out the culprit. Apparently SDL 2.0 is using libxinerama.so to query some information related to multi-monitor setups. Since my Ubuntu installation was brand new I didn’t have that library installed. That didn’t stop SDL from building but querying multiple monitors was not working properly.
Hopefully this sort post will help people that have similar problems. If you have multiple monitors and you are using SDL 2.0 install libxinerama-dev.