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.
My short summary for non static data members initialization from modern C++. A very useful feature. Should we use it or not?
Intro Non-static data member initializers Paper N2756 Visual Studio Since VS 2013 GCC Since GCC 4.7 Intel Compiler Since version 14.
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.
OpenGL 4.5 has just arrived!
Since Siggraph 2014 is happening right now, we could expect a new version of OpenGL. And it happened! Khronos announced OpenGL 4.5! Not a major update, but still adds some nice features to the API. What about OpenGL 5.0? Is there any news here?
I am very curious about the D language and its community. Although, I do not have lot’s of experience with this language, I try to track news and important updates. Recently, I’ve noticed that there is another book released regarding the language: D Cookbook, by Adam D. Ruppe
Let’s see what’s inside this book
It’s time to start improving the particle code and push more pixels to the screen! So far, the system is capable to animate and do some basic rendering with OpenGL. I’ve shown you even some nice pictures and movies… but how many particles can it hold? What is the performance?
