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!

Open code and you

doom

Moving some of my projects to the wild, I mean to GitHub, has made me realize what others already knew, much of the software we use everyday is open source or has some roots there. Be honest, peeking to someone else’s software is great. As to my own experience I started learning programming as a child reading the source code of the Doom Editing Utilities (and that probably shifted and twisted my understanding of computers for my entire life). This concepts of seeing others work and learning from it is a hidden fact that affects our life in for example every gadget we use (read Android/iOS). But not only to learn but to understand what a piece of software does, its source code is the ultimate documentation. If you are using a third party library, ask for its source code and peek at it when needed. At Video Stream Networks we made a similar approach, we had our domain logic code written in C++ every time we had to tune it for every customer’s workflow it made us feel miserable. After we moved our domain logic into Casper, a Domain Specific Language for the media and broadcast world, our customer can not only peek at what our app does but understand and fine tune it themselves.

Thanks to GitHub and the Open Source Community, ShadingZen Engine is slowly maturing. The GitHub repo received a pull request with some great changes. The project now has Maven build, the structure is more clear with all the examples and documentation centralized in just one repository and the eclipse requirement has been removed (This last point allowed me to try out IntellIJ IDEA which so far I find as a really good java IDE).

Yes, open source level editors as well a robust designed and extensible engine was behind the success of DOOM, the very same that made some of us programmers.

Android development tips – Gifagram project

For the past months I have been reading the Android SDK, trying out it’s OpenGL ES 2.0 capabilities (check my Github project ShadingZen) and was really impressed with the overall API quality. It’s easy to get things done, and its integration with Eclipse helps too. Current top devices are computing crunchers!

I went thinking I could play a bit higher by developing some application for Android, and that’s how we came with the idea of Gifagram app.

Gifagram.com promo image

The idea behind it is to enable the user to create stop-motion or animated GIFs directly from her Android device. GIFs are easy to share, doesn’t take much bandwidth and some very creative people manage to communicate really stunning stories in this format.

Not everything was easy tho. The camera API in android is really quite undocumented and its behaviour relies completely on the underlying hardware implementation. Retrieving useful information from the beta-tester devices was also cumbersome (to the point that was much easier to just take the terminal to the mac and just debug it directly than to take and read the logs).

Some tips on android development:

  • Think the user workflow within the application and minimize user taps and input steps. Make it simple, vertical application vs “The killer app”.
  • Prototype the application with simple buttons and don’t waste time until the domain logic is really working.
  • Try your software on every android device you can get. This probably should go on top of your list.
  • If you plan to create a free and a paid version, develop with a single application and when you are ready to go to market, convert the project to library and reference it from your free and paid android projects (check this: http://developer.android.com/guide/developing/projects/projects-eclipse.html).
  • Android market share is growing, but it’s fragment in devices and versions. Android 2.2 and 2.3 are currently in almost 90% of the devices out there, develop with this in mind.
  • Avoid NDK unless you are really sure about any performance boost that may gain. For gifagram we had to use it no matter what and was a bit tricky at some points.
Side note: There are a lot of useful resources, for example stackoverflow.com is a great place to look.