Something that was long overdue… the new developer console of AnKi. It can execute LUA scripts and view the log. More importantly, it’s bound to the tilde key (~) like all consoles should. Built using Dear ImGui.
Designing good C++ game middleware
For many years I’ve been evaluating and using various game specific open source libraries and at the same time I was designing and implementing my own. Despite the fact that many libraries are quite competent on what they do, their overall design leaves a few things to be desired. Some of the concepts described here sound naive but you can’t imagine how many libraries get them wrong. This article focuses on a few good practices that designers/implementers of performance critical libraries should be aware of.
This article is built around five pillars:
- How public interfaces should look like.
- Data oriented design.
- The importance of thread-awareness.
- Memory management.
- And some general concepts.
Who is the target audience:
- People who want to create performance critical libraries/middleware.
- People who want to attract serious users and not only hobbyists.
- Mainly directed to opensource.
Who is not the target audience:
- People who want to create middleware solely for their own amusement.
- C++ purists.
Optimizing Vulkan for AMD and the tale of two Vulkan drivers
The first GPU AnKi run, almost a decade ago, was in fact an ATI Radeon 9800 Pro. The first version of the deferred shading renderer run in that GPU and not only that. AnKi was running on Linux and the fglrx driver. I don’t remember experiencing many game breaking bugs back then, but then again, AnKi was quite simplistic at the time. One thing I remember was some depth buffer corruption that I had to workaround using a copy. Many years later I understood that this was a driver bug.
The love with ATI didn’t last long and AnKi end up being developed exclusively using nVidias. For many years AMD’s OpenGL driver didn’t have the quality or the features I wanted. Fast forward to today, things are looking far better. Firstly, Mesa has a quite decent OpenGL implementation, secondly, there is a very competitive Mesa Vulkan driver (RADV) and on top of that there is an second opensource Vulkan driver directly from AMD (AMDVLK). The cherry on top is a very good profiler for Vulkan and AMDVLK called Radeon GPU profiler. AMD regularly releases lots of documentation and optimization tips as part of their GPUOpen initiative. This is a great period to own AMD hardware for graphics development that’s why I had to get my hands on an AMD GPU.
In this post I’ll focus on some AMD specific optimizations and I’ll be comparing the two opensource Vulkan drivers.
Continue reading “Optimizing Vulkan for AMD and the tale of two Vulkan drivers”
Vulkan’s coordinate system
One of the key differences between OpenGL and Vulkan -and something that needs careful consideration when porting to Vulkan- is the coordinate system. Khronos’ Vulkan working group decided not to use GL’s commonly used coordinate conventions in favor of something more widely used and accurate and that’s the main reason behind this shift.
Clustered volumetric fog
I’ve written an article on how volumetric fog works in AnKi. You can read it at ARM’s developer portal. This is still in progress but for now the performance is acceptable.
Porting AnKi to Vulkan part 2
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.
Volumetric lights/fog test
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.
One decade working on AnKi. Uploaded the first snapshot I found in my archive
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.