Android 3D and 4D vector classes

Started by
1 comment, last by clb 11 years, 10 months ago
Hi people,

I noticed there's a nice android.opengl.Matrix class with a lot of helper functions. However, there is no stock Vector class that would support 3D and 4D vectors (compatible with those matrices). I want to be able to perform basic operations on my vectors on CPU, too, that means that having simple float[] everywhere really isn't an option. So before I head on to writing a couple classes for this, I wonder if there isn't a ready library for this kind of simple algebra for Android Java, perhaps somehow optimised for fixed-point or something? Writing that again in Android Java is no big deal, just possibly a waste of time.

I must have been asking google wrong questions so far...
Advertisement
Last I did Java-GL work in Android, I rolled my own vector library.

However, I would suggest using C/C++ for any graphics work. All OpenGL calls on Android are JNI calls which are quite expensive (even with a JIT). Dalvik overhead (Dalvik is the VM on Android devices) can become quite noticeable with programs requiring good response time, particularly in regards to GC.

Past that, if you use native code, you can write an optimized version using NEON extensions. It's highly unlikely that Dalvik's JIT (assuming Froyo or later) is going to be able to figure out that your vector code can be better written with NEON.
If your game code is in Java, you want to have your math library in Java. If your game code uses Android NDK, you want to have your math library in C/C++. Crossing the interop barrier is more trouble than the small performance difference with Java and C++. This is because for most primitive operations, a single cache miss or a function call is already way more costly than doing the operation inlined in code of same language.

If your game code is in Java, the only benefit for having C++ math code is in batched math operations: transforming a vertex array by a matrix, or doing CPU-side skinning in batches, batch-testing primitives for intersection, and so on. As commented already above, using NEON here can offer even more performance.

This topic is closed to new replies.

Advertisement