When constructing a C++ class a good practice is to never have any member variables in public scope and this includes containers. In this little article we will discuss how to have a C++ container as a private member and be able to expose its contents without exposing the container itself.
Continue reading “C++ Class: Accessing contents but not the container” »
Multithreading is a concept that exist for many decades in computer science, nevertheless, only in recent years it become a trend in game development with the arrival of multi-core CPUs in our home PCs. In this small article we will discuss how AnKi utilizes the power of multiple processors. Also the source code of an example can be found at the end of the article.
The concept of multiple threads offers many advantages in applications that execute many uniform jobs at the same time, for example a webserver needs to serve multiple hosts at the same time and without a host waiting for a previous request to finish. A game application though used to have a very standard and linear flow. For example, we first update the AI, then the physics, then we update the world, we do visibility determination and lastly we render, then we repeat the same again. Sometimes its difficult to execute some of these distinctive steps in parallel because the data of the previous step will be used by the next. I bet high class development studios have found ways to blend these steps but in AnKi we use a more simple approach. We use multiple threads to run uniform jobs in parallel.
One good example to illustrate how AnKi uses the power of multiple threads is the visibility determination algorithm. One step of visibility determination is the test for every renderable scene node against the camera’s view frustum. If we have N nodes to test and M threads we can roughly assign for testing the first N/M nodes to the first thread, the next N/M nodes to the next thread etc.
C++ Standard Template Library (STL) offers a smart pointer called auto_ptr. auto_ptr is a template class that acts as a wrapper for a single dynamically allocated class instance. Its purpose and its usefulness is to deallocate the memory when this smart pointer gets out of scope. Its a way to do automatic garbage collection in C++ by saving us from the extra code writing. One extra reason to use auto_ptr is that it makes the code less error prone simply because it doesn’t rely on the programmer to do the memory dealocation.
In this short article we will discuss a case where auto_ptr fails to do what its supposed to do….
Ok, the title sounds a little bit pompous and promises allot, many fellow programmers will disagree with the described methodology and others may find it useful. After many changes and rewrites of the AnKi logging system we’ve gained some experience of how a proper logger should be designed and work. The purpose of this article is to pass this knowledge to anyone who is interested.
Continue reading “The perfect logging system for C++ apps” »
After a few weeks of coding I’ve moved the renderer from OpenGL 2.something to OpenGL 3.3 core. This process proved to be a not so easy task mainly because I had to modify a few shaders and change the way the meshes get rendered. One thing to note about 3.3 is the way of rendering geometry. It doesn’t support immediate mode ofcource, it doesnt support vertex arrays and it doesnt support the use of vertex buffer objects (VBOs) outside vertex array objects (VAOs). The changes in the shaders were not that difficult. The modifications were to remove the varyings and replace them with in/out variables, remove the gl_FragColor and add a few layouts for some attributes. The shaders worked without causing major headaches.
With the transition to 3.3 core I found an opportunity to change the organisation of meshes and materials. The meshes now contain only the VBOs and the materials do not have any information about the depth passes. A mesh can now have multiple compatible materials. The container that has meshes, materials, skeletons and animations is called model.
The work in the renderer is not yet complete. I have to rewrite the debug rendering stage and for that I need think of an optimal way to draw debug primitives (mainly lines).
One more thing is the new file format for materials. I’ve moved away from the custom formats and its now the materials are in XML. To parse the XML AnKi uses the boost property_tree container. The model files are in XML as well and only the lights are left to be done.
For the future AnKi has quite a lengthy TODO list
Continue reading “Status report: OpenGL 3.3 core & XML files” »
Every game engine, at some level, needs to be able to compile and run code at runtime. You need, for example, to trigger a custom event when the hero pushed a button. The button should contain a bunch of code that may call an elevator or/and open a door or/and even kill the hero. All these custom events are possible by embedding a scripting language on top of the native language the game uses. Most of the game developers use native languages like C/C++ (very popular), Objective C (iPhone) and Java (other mobile platforms and rarely on PC). As for the scripting languages, the developers face many more choices with custom scripting languages (Unreal Script), lua, javascript (through various implementations), Python, Squirrel and more.
AnKi, just like every other game engine, needed a scripting language and the searching/prototyping started almost a year back. We have made prototypes for lua, javascript (V8 and SpiderMonkey), squirrel, Qt script, Python and others. Lets see why we chose boost python over others…
Continue reading “Why boost python for AnKi?” »
Loading ...