Maybe I’ll be boring with this note, but again I need to write that this was another good year for C++! Here’s a bunch of facts: Visual Studio 2015 was released with great support for C++14/17 and even more experimental features. Long-awaited GCC 5.0 was released at the beginning of the year.

Verify you assumptions about tools you use! Some time ago I was tracing a perf problem (UI code + some custom logic). I needed to track what module was eating most of the time in one specific scenario. I prepared release version of the app and I added some profiling code.

Several moths ago I’ve noticed there would be another version of OpenGL Superbible. This time the 7th edition! Without much thinking I quickly I pre-ordered it. Around two weeks ago the book appeared at my doorstep so now I can share my thoughts with you. Is this book worth buying? Is the new content described in an valuable way?

Let’s look at the following problem: We are designing a drawing application. We want some objects to be automatically scaled to fit inside parent objects. For example: when you make a page wider, images can decide to scale up (because there’s more space). Or if you make a parent box narrower image needs to scale down.

// how does it work? auto i = 0; // ?? C++11 brings us a very useful set of tools. It adds fresh air to the hard life of a programmer. The updated syntax makes the language a more modern and easier to use. In this post let’s take a quick look at a nice keyword ‘auto’ that, at first sight might seem very simple.

You’ve just recompiled a 3rd party library in Visual Studio, copied the .lib file into a proper directory, added dependencies into your final project… recompiled and it worked nicely! Good. So now you can commit the changes into the main repository. Then, unfortunately, you got a report from a build server (or from your colleague) that your recent change generated 10s of warning messages about some missing files from this new library… why is that?

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,