There are an increasing number of resources about different ways of running Python on Android. Kivy (and its subprojects) are commonly mentioned, as one of the most mature and popular ways to do so, but one thing that gets less attention is the details of what you can do with Python itself once it’s running on the device – what are the limitations of this? Can we use any Python module? What about calling Android APIs, can we perform all of the functions of a Java application? These are all somewhat leading questions, they are things addressed by Kivy or its associated projects, and in this post I’ll summarise some of the most interesting and important details.
The specification and drivers for Vulkan, Khronos’ next generation graphics API, are expected to be released later this year. However, we can get a head start on learning how this new API will work by learning from the project that it evolved from: Mantle.
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 closedaxis-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 auto keyword, 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.”
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.
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.