Experiment #2 : c++11 multithreaded raytracer

Hello everyone! A few weeks ago I got a read at The C++ Programming Language 4th Edition in order to refresh my knowledge about c++11 , since I'm not using it at work. I was particularly curious about the built-in threading support. I thought that features like packaged task and lambda function, plus applying concept from functional programming paradigm should make relatively easy to make truly cross platform multi-thraded applications. Of course you have less control over it, thing such as lightweight thread or mutex and even set affinity or thread pools, so If you are looking for maximum performance probably they are not optimal. Keep in mind that most of efficiency of a multithreaded application depends on how you design your application...less read-write data is shared across thread means less lock/mutex and less waiting time for you thread to acquire the resource it need. I decided to make a little multithreaded test application and since I've a passion for graphic programmer I decided to go for a multithreaded simple raytracer application, also because is a kind of problem that can be easily it features the following:

• colored planes and sphere
• multiple coloured lights
• shadows

That's it! no specular, no reflections, no texure and no anti-aliasig. They are actually very easy to implement and maybe I will extend the demo in future, but for now I preferred to keep the code lines at minimum in order to be better readable in this post. The ray test routines are word of wisdom from real time collision detection by Christer Ericson.

our simple raytracer output

At first, I implemented a single thead version. To convert in multithread I had literally to had 20 lines more of  code. basically I had to decide what to feed to each thread, my option was to divide the screen in in 2 rows and and a number of columns equal to the half of the number of cores the host cpu has and to feed each portion of screen to a thread. This is not optimal since there can be portions of the screen that are "easy" to compute while other ones require more work. So our bottleneck here is the thread that have to do more raycast than others. A better strategy would be having a pool of thread, and assign each of them a job a fairly little portion of the screen that our main thread will keep feeding them until they are finished. This would have required more work and the use of std::thread , std::packaged_task and std::promise and std::future. My program simply run the code assign a color to the screen buffer in a lambda function, which is given as argument to std::async. We then store an array of futures and we keep  checking whether or not all threads are finished. We don't need any thread synchronization mechanism since most shared structure the thread uses are read only and the only one you write to (the color buffer) is written in separate location by each thread. 

this is the code:

you can find instead the single thread version here

I deliberately used only POD structure with a data oriented approach, so don't criticize my class design.

How does it perform?

Creating a thread have its cost, also the speed depends on how the code is written and on the CPU architecture. Even if you don't have race condition an synchronization issues, your algorithm could spent most of the time fetching and writing data from RAM that is very slow compared to cache.

This is an histogram of the perfomance of single thread vs multithread algorithm tested on my cpu, an AMD FX-8320, an 8 core cpu.

when the data to process became significant we reach a peak of 5x faster than a a single threaded option, not bad at all!

Experiment #1: simple c++/html5 cross platform 2d engine

Some time ago, when I read that epic ported citadel demo on html5 , I decided to have an in depth  look on how they did that and give it a try. The company I was working for, playerthree  make also html5 web enabled games, so for me the possibility to write a game for the web and for native mobile device in c++ seems just a dream.

Epic were using emscripten, a cross compiler from c++ to javascript  that promise that everything that can be compiled by CLANG, it can be ported in javascript. In fact the main principle behind this tool is that bitcode generate by llvm can be easily translate  in some sort of assembler virtual machine running on javascript. In particular , it uses a javascript language subset known as asmjs. It sounds like this solution would bloat a lot of code by translate object  files in some sort of ASCII version of compiled assembly code but turn out that since asmjs can be easily mapped to machine code, javascript engine can perform ahead of time compilation (AOT) and gain a massive performance gain. The asmjs guys declare that there is only a 2x performance slowdown when compared to  native code on some javascript engine.

The whole toolbox you need for emscripten can be directly installed and configured using EMSDK . Once installed you only need to recompile your project using emcc command, the same way you'd compile your application with a normal compiler.

So, back to us I decided to write a small 2d engine to see if I was able to compile with emscripten, it support the following features:

• Sprite batching
• Texture atlas (Texture Packer and glideros format)
• Interpolators
• Timed callbacks
• font support (glideros format)
• touch input
• OpenGL 2.0
• basic memory management 
• basic containers
• audio (only on windows at the moment)

it support windows, iOS and Android, plus html thanks to emscripten, it doesn't depend on many library, just glfw for rendering window management and input on windows side and libpng.

On top of that I did a game, during a gamejam organized by playerthree to test if a full game could be done... and it worked. The web version even run on iOS8 and chrome mobile browsers!

in "the only way is up" you have to make your way from the bottom of the ocean to the surface. Simply move your mouse/finger to make the character strafe. You can play the web version here.
All the game design, graphics and audio were made by Gravy,  playerthree creative director and co-founder.  

If you are interested, I've made the engine and the game code available on github. Apology for the game code since is something made during an 8 hour long jam, and if you have any question , feel free to ask.

Greetings

Hello everyone and welcome to Dr. Glitschen's blog. 

Please allow me to introduce myself: I'm a professional video game programmer living in UK for almost 4 years now. English is not my native language so I hope you will excuse me if sometimes I make some mistakes. 

My principal interest are new technologies, programming, playing videogames and board games, cooking, sleep and 80's stuff in general. Sometimes I'm lazy. The idea to have a blog came to me at least a couple of years ago, but as I just told you, I'm lazy :D. With the beginning of 2015 among with a new job, I thought that this was the right moment to do it and , of course , I'm already a few days late :D I will talk mainly about programming ideas, graphic programming and c++ in general, but I don't exclude it will evolve in something different in future and I'll try to post often and keep the blog updated. Hope you will enjoy the ride and you will participate numerously and actively in my post. Oh, I almost forgot... happy 2015!