ShadingZenCpp

A few days ago I released an initial “approach” to a 2D/3D computing library written in C++ with the ultimate idea to optimized ShadingZen (a java 2D/3D Engine). In its current state you can find various generic templates and some SSE specializations for 3 and 4 component vectors, matrices, quaternions and soon rays and bounding boxes. Those are the foundations for various common spatial queries algorithms too.

The source compiles against Boost 1.53 (its only dependency so far) on some semi-compliant C++11 compilers (cross-platform library!):

  • Linux GCC 4.7.20121109 (probably works with 4.6)
  • MacOSX Clang 3.2 (using libc++)
  • MSVC 2012

Supported SIMD instruction sets:

  • SSE: Yes, 4.1
  • NEON ARM: No
  • AVX: No

I have spent some hours this weekend tuning the Boost.Build2 scripts to ensure everything compiles in those various systems with unit testing and with just one command. I’m leaving android for some near future.

You can found the repository here: https://github.com/TraxNet/ShadingZenCpp Feel free to contribute!

Advertisements

Android Performance (Object Pools)

This is the second part of my series of post about avoiding some performance hit caused by dalvik GC, first entry is here: https://traxnet.wordpress.com/2013/02/25/android-game-development-tipstricks/

Object factories are quite useful in this context as they avoid object to be GC’ed and also avoid allocating new memory which also incurs in some overhead.

In java this is done quite easily. For our objects to be poolable we need them to conform to an interface:

public interface Poolable {
   public void initializeFromPool();
   public void finalizeFromPool();
}

We also need to create a pool which allocates new objects if needed, and keeps the pool moving. The soruce code can be best viewed at GitHub here: ObjectPool.java

There is one drawback with this implementation, we need one pool for each kind (or type) of object we want to be poolable. With some more code we can have a jack-of-all-trades pool which can create any kind of object. ShadingZen has an specialized pool that creates rendering task of any type (assuming they inherit from RenderTask), the code can also be found here.

A 3d rendering engine is huge loop creating and destroying objects, thus reusing some of them will make a huge difference on mobile platforms.

Happy coding!

Android Game Development Tips&Tricks

Kill the bugs

Kill the bugs

It has been several months since I first thought I should post here some of basic tips and tricks on android development, specifically game development. Sadly I have almost no free nowadays. But here it is, a new blog entry I hope I can expand into a little series. Everything posted here comes from my own experience developing ShadingZen, an open source 3D Engine for Android

This is all about java, dalvik and you. We well talk about java development and what little tricks you can do to make your game shine (ok maybe not shine, that depends on your graphics people, but to go faster and avoid slow downs). If you follow me on twitter you may recall me saying dalvik GC is slow…oh well, I was wrong, it is not dalvik but the mobile environment what is slow. If you don’t believe me, create a jni example and put a delete inside a loop, then profile.

Lastest versions of dalvik have done a huge leap towards a good-performance-all-around-vm. For gaming it was critical to release a non blocking garbage collector, prior to version 2.3 (Gingerbread) used to pause the whole application for more than 10ms. Let’s do some simple math: for a 30fps animation you need to rendering one frame in 33ms aprox. If the garbage collectors hits in, your animation will suffer.

Ok, so the garbage collector works as intended. so why do still need to use tricks and put more thoughts on the whole thing? Well….it is a mobile, all those Hires bitmaps need to be deleted and created during your application, if you do this very often, it is going to be slow, no matter what. This leads us to the number one tip, don’t allocate memory if you don’t need to.

1. Measure

A claim that something is slow need some proof. You need to start benchmarking your gameloop from day 0 of development and be sure nothing breaks your desired frame rate. A good resource for benchmarking is Caliper.

2. Avoid Allocating Memory

This tip may look like too simple, but it is true, you don’t have many spare memory, don’t allocate objects that you really don’t or have a more basic counterpart that would do the job.

3. Don’t release memory

– What?! – Yes, don’t release memory, it is slow, and furthermore, you will probably need to use it again, or a partial copy of it. Avoid having a huge for lop with hundred of iterations where you code creates and discards objects, that’s going to hurt you later, when the GC starts collecting that memory.

There is a very smart way to condense tip 2 and tip 3 into just one big idea, object factories. This will be may next tip, for the second part of this blog entries series. I will post some code for you all (although you can go right now to ShadingZen repository at GitHub and start taking a look!).

Resources

– There is great talk by Google’s Advocate Chris Pruett on some basic ideas, take a look at them: Writting Real-Time Games for Android

– Caliper. A benchmarking tool.

Towards ShadingZen 1.0beta2

Development of ShadingZen is approaching version 1.0 beta 2 and a new minor update has been rolled out and ready to be cloned/forked by you at ShadingZen’s GitHub repository.

The primary goal for this milestone (v1.0 beta 2) is to provide better documentation, ranging from API documentation to useful examples for the wiki.

Secondary goals are to improve performance, mainly in areas where we can use object pools to avoid garbage collection frame rate drops. In fact, RenderTasks have been refactored and now use a global shared pool manager which creates and reuses RenderTask objects. This gives a performance boost but increases memory usage.

ShadingZen is a 2D/3D Engine for Android OpenGL ES 2.0 and is open source under the MIT License.

Android realtime performance tips

Embedding programming has never been easier after the introduction of modern mobile APIs like Android SDK and iOS SDK. Nevertheless for realtime applications new areas for potential bottlenecks may arise as those extra layers add more complexity to your application.

A clear example may happen with the Dalvik GC (Garbage Collector), which coupled with a realtime 2D/3D Engine generating many objects for each frame, will (for sure) showcase frame drops when the GC hits in. This is hard to solve as Java makes really easy to create new objects that encapsulate your required functionality but hides from you how and when the memory will be collected. Hey! it creates objects everywhere, for iterators, enums, sorting alogrithms…I personally think Dalvik needs some improvement in memory management areas but meanwhile we just need to avoid those problems and minimize them as possible.

Dont create objects! No, seriously, don’t create new objects in your game loop. Use object pools as much as possible. This is an area ShadingZen engine is improving and is one of the reasons you should always create new actors using the “spawn” method.

Don’t call your own methods, use the objects properties within the objects code and use methods to access functionality from outside. Also avoid using getters and setters, but pack functionality in just one method call instead of using the getted property from outside. For example if you want to make an actor explode you may need to compute explosion velocity and actor final destination from outside. Instead create a “makeExplode” method for that and compute everything within the object code. Dalvik makes calling methods slow.

If you are using OpenGL ES avoid changing states, pack drawing calls sharing the same state and run them at once.

DDMS is your friend. I know how much you hate its awkward interface but you need it, profile often!

Check this paper as it contains basic guidelines to avoid performance bottlenecks in your realtime applications: http://dl.google.com/io/2009/pres/WritingRealTimeGamesforAndroid.pdf

Performance is an area the next version 1.0-beta2 of ShadingZen is receiving much love.