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:

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

ShadingZen 3D Engine open sourced!

I’m showing you the code!

I have decided to open source my 2D/3D engine for Android and it is currently available at GitHub under the MIT License [put random reason here].

The goals behind ShadingZen is to offer a simple framework on which you can build mobile games easily, but without leaving behind performance reasons like stressing out multicore mobile CPUs found in modern phones/tablets. I have borrowed some ideas found at Cocos2D that I just find really useful, like Actions and Transitions.

Go clone it!

I’m using my spare time to create some HOWTOs and examples. I would also like to write down some core concepts of the engine. For more info keep an eye to future changes at the GitHub wiki here.

Some notes I’m preparing for future documentation sections.

GPU Compute Slides

Some interesting slides on GPU compute aimed to 3D engine programmers: It goes beyond rendering and how it can be useful in other situation to offload work to the GPU. It also contains some smart ideas on how to improve overall algorithm performance. Worth a read.

Nikon F4

I don’t know why but looks like software people also likes photography. Must be there something about brain cells organization thats leads you to go down the software path that also determines your chances to like photography…who knows…

So that’s me, one of those out there that love photography and spent some time trying to improve it at any chance.   This post is about the Nikon F4, one of the most innovative cameras in history, and why I find it great.

I bought mine about one year ago, at ebay. My dad had one when I was a child and I was fascinated ever since, and I’m still are. In fact, I have never used my Nikon D80 again. Nikon D80 viewfinder cannot top with Nikon F4 one and composing is just not the same.

The Nikon F4s (the one with the MB-21 battery grip) weights a ton but feels strong and has all knobs at the right positions (yeah, it had knobs and I miss them in moderns cameras!). I just hope it never falls, and if it does, do NOT fall on my feet. It was built like a tank and it feels that way.

My flickr’s stream

This camera introduced many features that we used everyday today, for example integrated autofocus motor drive, matrix metterring, shutter balancer to reduce shutter-shake…you can read some history at this Nikon’s web page.

For me, the camera has the right buttons and knobs at the right place and you won’t need to deal with obscure menus and sub-menus, it’s User Experience is perfect 😉 Add on top of that a great viewfinder with 100% coverage.

There just one thing that is not right but shouldn’t be a problem 99% times you use the camera. The built-in LCD that is used to display shutter’s speed is not back-lit, which makes it almost imposible to read in low-light conditions. But probably in such situation you can’t even take photos unless you are using a 800+ ISO film. It not a big hassle for me.

If you ever consider buying a film camera, think on getting a Nikon F4.


EDIT: As commented below by @tonutunnelõnu the LCD is backlit.

Development of Kids 3D Cube

I’m happy to announce that I have release my newest creation, Kids 3D Cube for Android:

For this game a new 2D/3D engine optimized for multi core phones was created, targeting OpenGL ES 2.0, so It won’t run on old Android versions (below 3.2.).

A few interesting things about the 3d engine: It employs an smart task scheduler to parallelize work among all cores. It also has a lazy resource loader and few other interesting functionalities that I believe are a good starting point for upcoming titles.

I have to confess that mobiles GPUs are challenging for the limited set of resources, but high rewarding when your little phone starts showing up your glorious shaders on screen! 😉 A tip: minimize bandwidth usage, keep us much on GPU side and reuse it as much as possible. This is a big win on low-end phones.

I’m actively working on solving a few issues and adding new content to the game, stay tunned!

You can visit Kids 3D Cube fan page at Facebook here:

Necesidad de APIs en España

Ayer Hacks&Hackers Madrid (@HacksHackersMAD) hizo una presentación en el Centro de Innovación del BBVA sobre Apertura de APIs y de las oportunidades que esto representa para los medios de comunicación y para cualquier empresa española. Hay multitud de servicios que usamos día a día desde nuestros navegadores o móviles que están accesibles no como una front-end directo donde consumir el contenido, sino como un API que nuestro navegador accede continuamente para recuperar el contenido que demandamos.

La mentalidad española es clara, miedo a abrir el contenido a terceros. Pero lo claro es que hay multitud de grandes (o conocidas) empresas que antes no lo fueron, y como se vio ayer en la conferencia, se hicieron grandes gracias a suministrar un API sencillo y potenciar un ecosistema de aplicaciones o servicios de terceros que consuman los datos. Nos falta entender que la información es donde está el negocio, no el cómo se le hace llegar a los usuarios.

Un uso muy actual y con gran crecimiento son los servicios de backend en la nube. Muy enfocado para aplicaciones móviles o web, que además de ofrecer un base de datos escalable, añaden a la ecuación una API sencilla y una serie de librerías clientes para consumir esas APIs. De esta forma se externaliza la construcción del API, su matenimiento y escalado , y tan solo debes preocuparte de generar el contenido que va a ser consumido por terceros, ya sea desde aplicaciones móviles, televisores inteligentes, páginas web, etc. En España tenemos algunos proveedores de servicios de API en la nube como ProtoAPI.

Side note: Conceptos que iremos más y más en el futuro serán BaaS (Backend as a Service), PaaS (Platform as a Service) e IaaS (Infrastructure as a Service).

En la web de Hacks&Hackers Madrid podeis echarle un ojo al video la presentación.

Android MediaRecorder with Camera

Our animated gif and stopmotion maker application (Gifagram) relays heavily on the Android camera support. Two good starting points for Camera and Video recording on android are:

The first link is the Android SDK MediaRecorder class and the second one is a lengthy example.

Unfortunelly SDK information on camera and video is poor, and hidden behavior is quite undocumented.

For instance, MediaRecorder.setProfile(‘HIGH’) sets an invalid video size in Samsung Galaxy SII (1080 height, instead of 1088 as hardware requires). The same code on HTC Wildfire throws an exception although on other HTC phones, everything works great. This is heavily hardware dependent which can run you crazy.

Video recording using a Camera object

The following code snipplet setups the camera:

boolean setupVideoRecording(int use_profile){
    	boolean ret = true;
    		if(recorder != null){
    			recorder = null;

    		if(camera != null){
    		} else{
    			camera =;


    		CamcorderProfile profile;
    		if(use_profile == 0){
    			profile = CamcorderProfile.get(CamcorderProfile.QUALITY_LOW);  			
    			profile = CamcorderProfile.get(CamcorderProfile.QUALITY_HIGH);

			Camera.Parameters params = camera.getParameters();
			List sizes = params.getSupportedPreviewSizes();

			//List formats = params.getSupportedPreviewFormats();
			Size optimalSize;
			optimalSize = getOptimalPreviewSize(sizes, profile.videoFrameWidth, profile.videoFrameHeight);

			params.setPreviewSize(optimalSize.width, optimalSize.height);

			setCameraDisplayOrientation((Activity)context, 0, camera);


			recorder = new MediaRecorder();


			if(use_profile == 2){
				recorder.setVideoSize(optimalSize.width, optimalSize.height);
				//recorder.setVideoSize(profile.videoFrameWidth, profile.videoFrameHeight);
			} else{

    	} catch(Exception e){
    		String message = e.getMessage();
	    	ret = false;

    	return ret;

We pass a use_profile integer to choose some hardware dependent code. But for almost everything the use_profile == 2 is the right one for you.

And the following prepares the media recorder. Both functions can be called one after the other to completely setup the camera for video recording.

boolean initializeMediaRecorder(){
			return true;
    	} catch(Exception e){
    		String message = e.getMessage();
	    	return false;

This code is quite simple but I hope it can be the foundation of something more elaborated for someone. Please feel free to leave a comment if you have a tip that you would like to share with everyone.