It’s been one year since the first posts about my particle system: a demo in March and then an introduction in April. Last time I wrote about renderer updates and this was the last planned post for the series. I think most of requirements were achieved and I can be quite happy about the results.

Programmers are not machines that just write code. We have feeling and emotions as well! ;) We all need to learn a lot of new things, sharpen the saw, focus, make good choices about our career path, and simply, have fun. While most books describe the technical side of coding, not many address the psychological/business/economic side of our profession.

At GDC 2015 in San Francisco, Khronos announced new API for graphics and compute, previously it was called glNext… but now the official name is “Vulkan”! I could not resist to write some comments about this new and intriguing standard that can potentially “replace” OpenGL. Bunch of links   khronos.org/vulkan - the official site for Vulkan API.

Finally, I managed to finish the adventure with my particle system! This time I’d like to share some thoughts about improvements in the OpenGL renderer. Code was simplified and I got little performance improvement. The Series   Initial Particle Demo Introduction Particle Container 1 - problems Particle Container 2 - implementation Generators & Emitters Updaters Renderer Introduction to Software Optimization Tools Optimizations Code Optimizations Renderer Optimizations Summary The most recent repo: particles/renderer_opt @github

Since the beginning of January I’ve had a chance to play with a nice tool called Deleaker. Its main role, as can be easily decoded, is to find leaks in your native applications. I often had problems creating and maintaining custom code that tracks leaks, so Deleaker seems to be a huge relief in those situations.

In part 2 of the article about persistent mapped buffers I share results from the demo app. I’ve compared single, double and triple buffering approach for persistent mapped buffers. Additionally there is a comparison for standard methods: glBuffer*Data and glMapBuffer. Note: This post is a second part of the article about Persistent Mapped Buffers,

It seems that it’s not easy to efficiently move data from CPU to GPU. Especially, if we like to do it often - like every frame, for example. Fortunately, OpenGL (since version 4.4) gives us a new technique to fight this problem. It’s called persistent mapped buffers that comes from the ARB_buffer_storage extension.

I’ve finally got my copy of “Effective Modern C++”! The book looks great, good paper, nice font, colors… and of course the content :) While skimming through it for the first (or second) time I’ve found a nice idea for a factory method. I wanted to test it. The idea   In the Item 18 there was described how to use std::unique_ptr and why it’s far better than raw pointers or (deprecated) auto_ptr.

This was a good year for C++! Short summary (language features): Clang supports C++14 GCC supports C++11 and most of C++14 (Full support in upcoming GCC 5.0) Intel 15.0 supports C++11 (some features on Linux/OSX only) Visual Studio tries to catch up with C++11, but it also introduces C++14 features as well… and it become (almost) free!

Some time ago I’ve seen an inspiring talk from CppCon 2013: “C++ Seasoning” by Sean Parent. One of the main points of this presentation was not to use raw loops. Instead, prefer to use existing algorithms or write functions that ‘wraps’ such loops. I was curious about this idea and searched for nice code examples.

You’ve just started a new job and landed in front of a huge code base. Great! What a challenge! It would be nice to quickly get a general understanding of your project and be able to comfortably move around in the code. How do you do it? In the article you can find my list of three set of tools from Visual Assist that might help with this problem.

After playing with the tools we have some more options to improve the performance of the particle system. This time, we need to rewrite some parts of the code. In total, the particle system runs almost twice as fast as initially! Read more to see what pieces of code were changed.