Posted on May 17, 2013 by Sol

The code for this post is on GitHub: https://github.com/sol-prog/OpenGL-101.

This is the third article from my OpenGL 101 series. In the first two articles we’ve seen how we can open a window and draw OpenGL primitives: points, lines and triangles. We’ve also seen how we can assign a particular color to a vertex and use this to paint a two-dimensional surface with a smooth color.

Suppose now that we want to draw something more complex like the ruins of an ancient building, think a bit about how we can draw something as close as possible to what we can see in the real world. Theoretically, we can model everything with triangles and calculate the colors corresponding to each vertex, but this quickly gets out of hand - we are limited by the memory of our graphics card and by the speed of our graphics processor. A much practical approach to create the illusion of reality is to use textures that can be glued on the geometrical representation of our computer world.

In this article, we will concern ourselves only with two-dimensional textures, OpenGL can use other type of textures: 1D, 3D, cube textures etc … Technically a texture is just a container for data, you can store any numerical values in a texture, usually color values, and process this data in your shaders, usually in the fragment shader.

Posted on May 13, 2013 by Sol

The code for this post is on GitHub: https://github.com/sol-prog/OpenGL-101.

This is the second article from my OpenGL 101 series. In the first article we’ve seen how to open a window for our OpenGL application with the GLFW library and how to compile and run the code on Windows, OS X and Linux. It is time to actually draw something using OpenGL.

First, let me mention that OpenGL is a low level API, this means that it has no support for drawing complex geometrical objects. It is the programmer’s job to combine the geometrical primitives from OpenGL in complex shapes and bodies. The basic geometrical primitives that the core OpenGL profile provide to us are points, lines and triangles.

Posted on May 10, 2013 by Sol

The code for this post is on GitHub: https://github.com/sol-prog/OpenGL-101.

This is the first in a series of articles that will get you up to speed with programming in modern OpenGL. I have no claim about being an expert in the area, this is an edited version of the notes I took working on various OpenGL projects in the last year. I think the best way to really understand a subject is to try to teach it to another person. Constructive comments are welcome and I will update this series based on your comments.

First step in creating an OpenGL code is the creation of a window, using the underlying OS, and to attach an OpenGL context to it, OpenGL by itself can’t open a window. Using a particular OS APIs to create a new window will make our code non-portable; the usual approach is to use a library that abstracts the process of creating/destroying windows on a given OS and also manages the user’s inputs through mouse, keyboard or touch. There are a number of libraries that can abstract the process of creating an window for us, like, in no particular order, GLUT, Freeglut, SDL, GLFW and many others.

In these notes, we are going to use GLFW because it is a small, flexible and modern library, portable on all major operating systems.

Other useful libraries that we are going to use are GLEW - this will let us use the latest OpenGL functions in a portable way, GLM - a small mathematical library and FreeImage for reading and writing images in various formats.

Posted on February 28, 2013 by Sol

The code for this post is on GitHub: https://github.com/sol-prog/Mandelbrot_Set.

Yet another how to draw the Mandelbrot set article ? Well, yes and no, on the one hand fractals are fun and on the other hand, it could be instructive to play with complex numbers and lambdas in C++11. Also, the article presents a not so common continuous coloring procedure based on a slight modification of the Bernstein polynomials.

Please note, that calculating the Mandelbrot set can be done more efficiently if one uses the GPU (using OpenGL shaders for example) and not the CPU.

Posted on February 7, 2013 by Sol

The code for this post is on GitHub: https://github.com/sol-prog/Sort_data_parallel/tree/TBB in the TBB branch.

This is a sequel to my last article in which we’ve shown that you can, relatively easily, implement a parallel merge-sort algorithm using only functions from the standard library of a programming language, C++11 in this case. We’ve also compared our implementation with a state of the art sorting function from the CUDA 5.0 SDK thrust::stable_sort.

Following some concerns, raised by a commenter - snk_kid, I’ve made a new set of tests based on a state of the art CPU parallel sorting function from Intel’s TBB. His main these was that my previous comparison between CPU and GPU was misleading, because the use of raw threads in merge-sort is not efficient and, in general, I should refrain myself from writing about this subject unless I use task based parallelism or high level parallel libraries.

Posted on February 4, 2013 by Sol

The code for this post is on GitHub: https://github.com/sol-prog/Sort_data_parallel.

For many programmers sorting data in parallel means implementing a state of the art algorithm in their preferred programming language. However, most programming languages have a good serial sorting function in their standard library. It appears to me, that the obvious thing to do is to first try to use what your language library provides. If this approach is not successful, you should try to find an existing library that is used, and consequently well debugged, by other programmers. Only as a last resort, you should implement a new sorting algorithm from scratch.

In the case of C++, we have a well tested sorting function in the STL, std::sort, unfortunately std::sort will use only a fraction of the processing power available in a modern multicore system.

Posted on January 17, 2013 by Sol

Clang with libc++ represents today a viable alternative to GCC for C and C++ programmers. I make no claim that Clang with libc++ is necessarily superior to GCC with libstdc++, but it is definitely a more feature complete C++11 alternative. According to the libc++ website, libc++ is 100% complete C++11 implementation on Apple’s OS X and, from my tests, works equally well on Linux. Even if you plan to ship your C++ application compiled with GCC, I think it is a good test to check your app for errors by building it with a different compiler and library.

In this short post, I’m going to show you how to build the latest Clang and libc++ on a Linux box. I’ve tested this procedure on Ubuntu 12.04.1, Ubuntu 12.10 and Linux Mint 14.

Posted on January 12, 2013 by Sol

If you want to build yourself the latest Lua on OS X there is a simple recipe for this:

• Open a Terminal and navigate to the Lua source code:
 1 2 cd Downloads cd lua* 

Posted on October 24, 2012 by Sol

The code for this post is on GitHub: https://github.com/sol-prog/Sort_benchmark.

A good sorting routine is a building block for many numerical algorithms and, because of this, most modern programming languages provide one or more sorting algorithms in their standard library. C++ is not an exception. What varies, from one C++ implementation to another, is the performance of the sorting algorithm.

C++11 lets you use three sorting functions std::qsort, std::sort and std::stable_sort. While std::qsort comes from the C roots of C++, std::sort and std::stable_sort are provided by C++’s Standard Template Library. The new C++11 standard requires that the complexity of std::sort to be $O(n \cdot \log (n))$ in the worst case. Historically, in the C++98 standard std::sort was defined as $O(n \cdot \log (n))$ on average, with a possible worst case scenario of $O(n^2)$.

Posted on October 17, 2012 by Sol

For a few years now, we live in a multiprocessor world, starting from the phone in my pocket to the parallel quad-core beast I have on my table. Today, you could easily buy a six or twelve core machine that is several orders of magnitude more powerful than the super computers from a decade ago.

As programmers, we need to be able to use at full capacity the available computing power, you can’t buy a new computer and expect that your serial code will run faster. You need to write code that can run on multiple core machines or you will deliver a low quality product to your potential clients.

The new C++11 standard allows us to maximize the use of the available hardware directly from the language. Today, you could write portable multithreading code using only the standard library of the language.

Posted on October 14, 2012 by Sol

Prior to the release of the C++11 standard, there was no standard way in which one could accurately measure the execution time of a piece of code. The programmer was forced to use external libraries like Boost, or routines provided by each operating system.

The C++11 chrono header file provides three standard clocks that could be used for timing one’s code:

• system_clock - this is the real-time clock used by the system;
• high_resolution_clock - this is a clock with the shortest tick period possible on the current system;
• steady_clock - this is a monotonic clock that is guaranteed to never be adjusted.

Posted on October 10, 2012 by Sol

If you are a regular reader of this blog you’ve probably noticed that I tend to use the command line to compile, test and execute my C++ code. I do this even when I code on operating systems without a strong command line usage culture like Windows. Yesterday I’ve received an email from Zsolt, one of my readers, asking if it is possible to create a C++11 project directly in Xcode. The answer was, obviously, yes! I think this topic could be of interest for more than one coder, so I’ve decided to write a short post about this.

Let’s start with something simple, like filling a vector with some values and printing the result on screen:

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 //Demo program to test the new C++11 initializer lists #include #include using namespace std; int main() { // Test initializer lists and range based for loop vector V({1,2,3}); cout << "V =" << endl; for(auto e : V) { cout << e << endl; } return 0; } 

Posted on September 2, 2012 by Sol

11 September 2012 update

The last revision of Cling, r45925, doesn’t need any modifications in order to compile on Cygwin, I’ve removed some outdated instructions about manually editing the libcling.exports file.

3 September 2012 update

After a discussion with the main developer of Cling I’ve removed a paragraph about adding some hard codded paths in the Clang sources, this was an unnecessary complication. I’ll keep updating this article if we’ll find any other simplifications.

In my last article I wrote about Cling, the C and C++ interpreter. If you want to have a taste of what Cling can do for you, read my earlier post or this one. In short, Cling is a C++ REPL that uses Clang and LLVM for just in time compilation and parsing of your code. Currently, Cling can be officially compiled only on Unix like operating systems (e.g. Linux or OSX). What if you can’t, for various reasons, use a Unix like OS ? Well, this post is for you, the Windows user!

In principle, you could use Visual Studio to compile Cling, however because of the incompatibilities between Clang and Visual Studio, the resulting interpreter will let you use only C code. At the time of this writing, a Visual Studio compiled Clang is not able to build C++ executables … A C only interpreter, while useful, is not so attractive, at least not for me.

Posted on August 14, 2012 by Sol

A C++11 REPL may sound strange, after all C++ is generally seen as a compiled language. However, any programming language can be implemented as a compiler or as an interpreter and Cling happens to be an interactive C++ interpreter based on LLVM and Clang.

If you’ve ever programmed in a language that can be used in a Read-eval-print-loop or REPL you already know what productivity boost can be to be able to test an idea without waiting for your build system to compile your code. Even with tools like make you need sometimes to wait from a few seconds to a few minutes just to see the effects of some small change in a particular piece of code.

Posted on August 1, 2012 by Sol

The code for this post is on GitHub: https://github.com/sol-prog/roguelike.

Last time we’ve added a real map to the game, generated with a Perlin noise function. But where is the fun in a roguelike game without a monster ? In this post, we are going to add a rudimentary monster to our game, that will chase the main character. The player task will be to dodge the monster and stay alive …

Our monster will be dumb, all he knows is to chase the main character on the map. Because I’m more interested in testing an idea for a chasing algorithm, we are not going to create a separate class for the monster, we’ll refactor the code and add some AI to our monster in a future tutorial. For now we could use the Character class to initialize our monster:

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 int main() { ... // Initialize the main character. We are going to put this in the middle of // the game map (for now) Character main_char('@', game_map.height()/2, game_map.width()/2); // Add a dummy monster to the game (we start with a hard coded monster position defined // relatively to our main character position) Character monster('M', main_char.row() + 7, main_char.col() + 22); ... // Start the game loop game_loop(game_map, viewport, main_char, ch, monster); return 0; }