Last time, we discussed collision detection in general and surveyed some techniques for narrow phase collision detection. In this article we will go into more detail on broad phase collision detection for closed axis-aligned boxes. In the late 1970’s and early 1980’s, this problem attracted an enormous amount of attention due to its applications in VLSI design, resulting in many efficient algorithms and data structures. Here we survey some of the general approaches to this problem and review some analytical results.
Once you start working with some of the handy new C++11 features, it is a bit difficult to stop using them simply because you want to work on an Android project. Fortunately, the Android NDK supports C++11 features, although they are not enabled by default. The default Android NDK configuration provides only a minimal C++ runtime support library and doesn’t include the necessary flags to activate available C++11 features. In this article, I explain how set up a project to use C++11 features, relying on Eclipse and the latest available Android NDK, version r9d.
Consider a very common scenario in which you want to create a new Android app by reusing existing C++ code. In these cases, a typical solution is to develop the UI in Java and use the Java Native Interface (JNI) to make calls to the C++ code from Java (and the other way around if necessary). If your existing C++ code has been written taking advantage of C++11 features, you certainly would not want to create a new version removing all these C++11 features just to make it fit with the default Android NDK configuration. Fortunately, you can activate the NDK’s C++11 features to allow you to work with modern C++ amenities, and you can go on using the
autokeyword, lambda expressions, and other useful C++11 features.
I’ll assume that you have basic experience working with Eclipse, Android Development Tools (ADT), and the Android NDK; hence, I won’t provide specific instructions for the basic setup of these tools. You will need ADT and NDK installed on your system in order to test the examples. Because ADT and NDK have important changes in each new release, it’s important to note that I am using ADT Build v22.6.2-1085508 and NDK Revision 9d. This way, I can focus on the necessary configurations and tweaks related to C++11 and the related features. I’ll use a simple example Android app that employs a few C++11 features combined with some use of the Standard Templates Library (STL). Finally, I’ll explain additional options and configurations that you might need to consider.”
For the entire article, follow this link.
In case one’s interested in cross-platform development, here is a nice article about various strategies of implementing POSIX condition variables on Win32. Quoting from the article:
The threading API provided by the Microsoft Win32 [Richter] family of operating systems (i.e., Windows NT, Windows ’95, and Windows CE) provides some of the same concurrency constructs defined by the POSIX Pthreads specification [Pthreads]. For instance, they both support mutexes, which serialize access to shared state. However, Win32 lacks full-fledged condition variables, which are a synchronization mechanism used by threads to wait until a condition expression involving shared data attains a particular state.
The lack of condition variables in Win32 makes it harder to implement certain concurrency abstractions, such as thread-safe message queues and thread pools. This article explores various techniques and patterns for implementing POSIX condition variables correctly and/or fairly on Win32. Section 2 explains what condition variables are and shows how to use them. Secion 3 explains alternative strategies for implementing POSIX condition variables using Win32 synchronization primitives. A subsequent article will describe how the Wrapper Facade pattern and various C++ language features can help reduce common mistakes that occur when programming condition variables.
From http://www.g-truc.net/post-0704.html – a nice article about translations in C++ using tables with zero-based enums:
Few months ago, I got annoy that we had some code that translate API independent enumerations to OpenGL enumerations, back and forth, with basically no consideration at what happens when we add a new enumeration value in the API independent enumerations and no consideration of how this translation would perform within the rendering loop, where performance is critical and it’s typically going to be called. Considering the high number of translations per frame, probably it starts to matter.
For the entire article and more information, follow this link.
From the article:
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!