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.

In this post I will test several compiler options and switches that could make the particle system run faster. Read more to see how I’ve reached around 20% of 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 (this post) Code Optimizations Renderer Optimizations Summary Start   We are starting with those numbers (Core i5 Sandy Bridge):

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? Changes   GL_ARB_clip_control GL_ARB_cull_distance GL_ARB_ES3_1_compatibility GL_ARB_conditional_render_inverted GL_KHR_context_flush_control GL_ARB_derivative_control (GLSL) GL_ARB_direct_state_access GL_ARB_get_texture_sub_image GL_KHR_robustness GL_ARB_shader_texture_image_samples (GLSL) GL_ARB_texture_barrier As you can see, this list of changes is not that impressive.

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? Is it that bad?

When you write: char strA[] = "Hexlo World!"; strA[2] = 'l'; Everything works as expected. But what about: char *strP = "Hexlo World!"; strP[2] = 'l'; Do you think it will work correctly? If you are not sure, then I guess, you might be interested in the rest of article.

As I wrote in the Introduction to the particle series, I’ve got only a simple particle renderer. It uses position and color data with one attached texture. In this article you will find the renderer description and what problems we have with our current implementation. The Series   Initial Particle Demo Introduction Particle Container 1 - problems Particle Container 2 - implementation Generators & Emitters Updaters Renderer (this post) Introduction to Optimization Tools Optimizations Code Optimizations Renderer Optimizations Summary Introduction   The gist is located here: fenbf / ParticleRenderer