Monday, 17 December 2012

Audi A5 3.0 TDI test laps at the Circuit of Navarra

20 min. drive at the Circuit of Navarra, with a stock Audi A5 3.0 TDI.


Lap         Traffic         Yellw. Flag    Overtakes     Time
Warm up    Yes                No                3           2:37:80
2              No                 No                1           2:19:01
3              Yes                No                1           2:19:61
4              Yes                No                3           2:25:05
5              No                 No                1           2:18:84
6              Yes                Yes               2           2:23:35
7              Yes                Yes               1           2:17:34
8              Yes                No                0           2:21:37
9              Yes                No                1           --
     Total overtakes:    13 
     Best time:          2:17:34 

Wednesday, 12 December 2012

New XNA 4 book by Kurt Jaegers [Packt Publishing]

Kurt Jaegers has a new book on XNA 4 Game Development. I´ll review it in a few days, by now, I paste here some word from the author itself:

“This book follows the same style as my previous books on 2D game development with XNA, bringing three different 3D games to life. I cover items such as:
- The basic concepts behind 3D graphics and game design
- Generating geometry with triangles
- Converting height map images into terrain
- An introduction to HLSL, including writing shaders that handle lighting and multi-texturing
- Building a 2D button-based interface to overlay on your 3D action
- Implementing skyboxes for full 3D backgrounds”

More info here and here.

Tuesday, 20 November 2012

Simax City Bus Simulator video Released

Today, we have released the first video of the Simax City Bus Simulator. Featuring a Mercedes Benz Citaro bus, it allows drivers to safely practice driving with such vehicles, with an extremely affordable cost compared to other professional training tools.

More info at:

Tuesday, 30 October 2012

Wednesday, 24 October 2012

Memory limits in a .Net process

This article tries to be an introduction on .Net memory management and about the memory limits both the Runtime and the platform establish for each process. We will also give some tips about dealing with the problems you will face when reaching those limits.

Available memory for a process

As you already know, no matter how much physical memory you install in a computer. Your application will face several issues that will limit the actual memory available for it.
For instance, a 32 bit system cannot have more than 4 GB of physical memory. Needless to say that 2^32 will give you a virtual address space with 4.294.967.296 different entries, and that’s precisely where the 4GB limit comes from. But even having those 4GB available on the system, your application will actually be able to see 2GB only. Why?
Because on 32 bits systems, Windows splits the virtual address space into two equal parts: one for User Mode applications, and another one for the Kernel (system applications). This behavior can be overridden by using the “/3gb” flag in the Windows boot.ini config file. If we do so, the system will then reserve 3GB for user applications, and 1 GB for the kernel.
However, that won’t change the fact that we will be able to see only 2GB from our application, unless we explicitly activate another flag in the application image header: IMAGE_FILE_LARGE_ADDRESS_AWARE. The combination of both flags on a 32bit Operating System is commonly known as: 4GT (4 GigaByte Tuning).
Surprisingly on 64 bit environments, the issue is pretty similar. Even though these systems don’t suffer from the same limitations about physical memory or reserved address space for the kernel (in fact, in those systems the /3gb flag doesn’t apply), processes hit with the same wall when trying to address more than 2 GB. Unless the same flag is set for the executable (IMAGE_FILE_LARGE_ADDRESS_AWARE), the limit will be always the same by default.


  • In native, Visual C++ application, it’s pretty straightforward to set that flag, as Visual Studio have an option for that. You just need to set the /LARGEADDRESSAWARE Linker parameter, and you are ready to go.
  • In C#, .Net applications:
  1. Applications compiled as 64bit will have that flag set by default, so you will already have access to a 8TB address space (depending on O.S. versions)
  2. Applications compiled as 32bits will need to be modified with the tool called EditBin.exe (distributed with Visual Studio). This tool will set the appropriate flag to your EXE, allowing your application to access a 4GB address space if running in a 64bit Windows, or to a 3GB address space if running in a 32bit Windows with the 4GT tuning enabled.
Next table (taken from here), summarizes the limits in virtual address space, depending on the platform and on the kind of process we are running:
This page has much more info on the issue.

System memory limits. Closer than you expect

Nowadays, memory is cheap. However, as explained in the previous chapter, there are many situations where you will end up having only 2 GB available, despite the total amount of physical memory installed in your PC.
In addition to that, if your application is being developed in .Net, you will find that the Runtime itself introduces a remarkable memory overhead (around 600-800 MB). So, it’s not strange to start receiving OutOfMemory exceptions when reaching 1.2 or 1.3 GB of memory used. This blog talks further about this.
So, if you are not in one of those cases, where the address space is expanded beyond 2 GB, and your are developing in .Net, your actual memory limit will be around 1.3 GB.
That’s more than enough for 99% of applications, but others, like intensive computing apps or those related to databases, may need more. Way more…

And things get even worse…

To make things even more complicated, you will soon learn that one thing is having some amount of memory available, and another, completely different story is to find a contiguous block of memory available.
As you all know, as a result of O.S. memory management, techniques like Paging and the creation and destruction of objects, memory gets more and more fragmented. That means that even though there is a certain amount of free memory, it is scattered through a bunch of small holes, instead of having a single, big chunk of memory available.
Modern Operating Systems and the .Net platform itself apply methodologies to prevent fragmentation, like the so called Compaction (moving objects in memory to fuse several free chunks of memory into a single, bigger one). Although these techniques reduce the impact of fragmentation, they do not eliminate it completely. This article describes in detail the .Net Garbage Collector (GC) memory management, and the compaction task it performs.
In the context of this article, fragmentation is a big issue, because if you need to allocate an 10 MB contiguous array, even if there’s 1 GB of free memory available for your process, you will receive an OutOfMemory exception if the system cannot find a contiguous chunk of memory for the array. And this happens more frequently than you may expect when you deal with big arrays.
In .Net, fragmentation and compaction of objects is tightly related to object’s size, so let’s talk a bit about that too:

Allocation of big objects

Maybe you don’t know it, but all versions of .Net until the last one (1.0, 2.0, 3.0, 3.5 and 4.0) have a limit on the maximum size a single object can have: 2 GB. No matter if you are running in a 64bit or 32bit process, you cannot create anything bigger than that, in a single object. It’s only since version 4.5 when that limit has been removed (for 64 bit processes only). However, besides very few exceptions, you are very likely applying a wrong design pattern to your application if you need to create such a big objects.
In the .Net world, the GC classifies objects into two categories: small, and large objects. Where you expecting something more technical? Yeah, me too… But that’s it. Any object smaller than 85000 bytes is considered small, and any object larger than that is considered large. When the CLR is loaded, the Heap assigned for the application is divided into two parts: the SOH (Small Objects Heap) and the LOH (Large Objects Heap). Each kind of object is stored on it’s correspondent Heap.
It’s also remarkable to say that Large object’s compaction is very expensive, so it’s directly not done in current versions of .Net (developers said that this situation might change in the future). The only operation similar to compaction done with Large objects is that two adjacent dead objects are fused together into a single chunk of free memory, but no Large object is currently moved to reduce fragmentation.
This fantastic article has much more information about the LOH.

C# Arrays when reaching memory limits

Simple Arrays (or 1D arrays) are one of the most common ways of consuming memory in C#. As you probably know, the CLR always allocates them as single, contiguous blocks of memory. In other words, when we instantiate an object of type byte[1024], we are requesting 1024 bytes of contiguous memory, and you will get an OutOfMemory exception if the system cannot find any chunk of contiguous, free memory with that size.
When dealing with multi-dimensional arrays, C# offers different approaches:

Jagged arrays, or arrays of arrays: [][]

Declared as byte[][], this is the classical solution to implement multi-dimensional arrays. In fact, it’s the only approach natively supported in languages like C++.
With regards to memory allocation, they behave as a simple array of elements (one block of memory), where each one of them is another array (another, different block of memory). Therefore, an array like byte[1024][1024] will involve the allocation of 1024 blocks of 1024 bytes memory each.

Multi-Dimensional Arrays: [,]

C# introduces a new kind of arrays: multi-dimensional arrays, declared like byte[,].
Although they are very comfortable to use and easy to instantiate, they behave completely different with regards to memory allocation, as they are allocated in the Heap as a single block of memory, for the total size of the array. In the previous example, an array like byte[1024, 1024] will involve the allocation of one single, contiguous block of 1 MB.
In the next chapter we will make a quick comparison of both types of arrays:

Comparison: [,] vs [][]

2D array [,] (allocated as a single block of memory):
  • Consumes less memory (no need to store references to all N blocks of memory)
  • Faster allocation (allocating a bigger, single block of memory is faster than allocating N, smaller blocks)
  • Easier instancing (enough with one single line: new byte[128, 128])
  • Useful tool methods, like GetLength(). Cleaner and easier usage.
  • Finding a single block of contiguous memory for them might be a problem, specially if dealing with big arrays, or when reaching memory limits for your process
  • Accessing elements in the array is slower than in jagged arrays (see below)
Jagged arrays [][] (allocated as N blocks of memory):
  • It’s easier to find available memory for this kind of arrays, because due to fragmentation, it’s more likely that there will be N blocks of smaller size available than a single, contiguous block of the full size of the array.
  • Accessing elements in the array is faster than in 2D arrays, mostly because the optimizations in the compiler for handling simple, 1D arrays (after all, a jagged array is composed of several 1D arrays).
  • Consumes a bit more memory than 2D arrays (need to store references to the N simple arrays).
  • Allocation is slower, as it needs to allocate N elements instead of a single block
  • Instancing is uncomfortable, as you need to loop through array elements to instantiate them too (see below for tip)
  • Doesn’t provide with tool methods, and might be a bit more complex to read and understand
This blog have a great comparison about them too.


Each user should decide which kind of array fits best the specific case he is dealing with. However, a developer that usually needs big amounts of memory, and who cares more about performance than comfort, ease of use or readability, will probably decide to use Jagged arrays ([][]).

Tip: code to automatically instantiate a 2D, jagged array

Instancing a multi-dimensional jagged array can be disturbing, and repetitive. This generic method will do the work for you:
        public static T[][] AllocateArray2D<T>(int pWidth, int pHeight)            
            T[][] ret = new T[pWidth][];
            for (int i = 0; i < pHeight; i++)
                ret[i] = new T[pHeight];

            return ret;
Hope it helps !!

Los límites de la memoria

Este artículo trata de servir como introducción a la gestión de memoria en .Net, los límites que el Runtime y la plataforma establecen para cada proceso, así como algunos Tips para lidiar con los problemas a los que nos enfrentamos al acercarnos a esos límites.

Memoria disponible por proceso

Como muchos de vosotros sabéis, por mucha memoria RAM que tenga instalada un ordenador, existen varias barreras impuestas a la cantidad de memoria usable en nuestras aplicaciones.

Por ejemplo, en un sistema de 32 bits no se pueden instalar más de 4GB de memoria física, evidentemente, porque 2^32 (dos elevado a 32) nos proporciona un espacio de direcciones con 4.294.967.296 entradas distintas (4GB). Pero incluso cuando el sistema cuente con 4GB de memoria física, nuestras aplicaciones se encontrarán con una barrera de 2GB impuesta por el sistema.

En estos entornos de 32 bits, cada proceso puede acceder a un espacio de direcciones de 2GB como máximo, porque el sistema se reserva los otros 2 para las aplicaciones que corren en modo Kernel (aplicaciones del sistema). Este comportamiento por defecto puede cambiarse mediante el uso del flag “/3gb” en el boot.ini del sistema, haciendo que Windows reserve 3GB para las aplicaciones que corren en Modo Usuario y 1GB de memoria para el Kernel.

Aún así, el límite por proceso permanecerá en 2GB, a no ser que explícitamente activemos un flag determinado (IMAGE_FILE_LARGE_ADDRESS_AWARE) en la cabecera de la aplicación. A esta combinación de flags en sistemas x86 se le denomina comúnmente: 4GT (4 GigaByte Tuning).

En sistemas de 64 bits sucede algo parecido. Aunque no tienen la misma limitación en cuanto a memoria física disponible, ni la impuesta por la reserva de direcciones para el kernel (y por lo tanto el flag /3gb no aplica en estos casos), el sistema también establece un límite por defecto de 2 GB para cada proceso, a no ser que se active el mismo flag en la cabecera de la aplicación (IMAGE_FILE_LARGE_ADDRESS_AWARE).

  • En el caso de aplicaciones nativas (C++), establecer dicho flag es fácil, ya que basta con añadir el parámetro /LARGEADDRESSAWARE a los parámetros del Linker dentro de Visual Studio.
  • En el caso de aplicaciones .Net:
    1. Si están compiladas para 64bits, este flag estará activado por defecto, por lo que podrán acceder a un espacio de direcciones de 8 TB (dependiendo del S.O.)
    2. Si están compiladas para 32bits, el entorno de Visual Studio no nos ofrece ninguna opción para activar dicho flag, por lo que tendremos que hacerlo con la utilidad EditBin.exe, distribuida con Visual Studio, la cual modificará el ejecutable de nuestra aplicación (activándole dicho flag).

La siguiente tabla, obtenida de esta página, muestra de forma resumida los límites en el espacio de direcciones de la memoria virtual, en función de la plataforma y del tipo de aplicación que estemos desarrollando:


Esta página tiene mucha más información sobre los límites de memoria según las versiones del S.O.

Los límites del sistema, más cerca de lo que crees

Hoy día, la memoria es barata, pero como ya se ha explicado en el apartado anterior, hay un buen número de casos en los que, por mucha memoria que instalemos en el PC, nuestro proceso solo podrá acceder a 2GB de la misma.

Además de esto, si vuestra aplicación está desarrollada en .Net, os encontraréis con que el propio Runtime introduce un overhead importante en cuestiones de memoria (suele decirse que está en torno a los 600-800 MB), por lo que en una aplicación corriente, es usual empezar a encontrar OutOfMemoryExceptions alrededor de los 1.3 GB de memoria usados. En este blog se discute el tema.

Por lo tanto, si no estamos en uno de esos casos en los que podemos direccionar más de 2GB, y además desarrollamos en .Net, independientemente de la memoria física instalada en el sistema nuestro límite real estará en torno a 1.3 GB de memoria RAM.

Para el 99% de las aplicaciones diarias, es más que suficiente, pero otras que requieren cálculos masivos, o que se relacionan con bases de datos, muy frecuentemente superarán ese límite.

Y lo que es peor…

Para complicar todavía más el asunto, una cosa es tener memoria disponible, y otra muy distinta es tener bloques de memoria contiguos disponibles.

Como todos sabéis, fruto de la gestión que el Sistema Operativo hace de la memoria, de técnicas como la Paginación, y de la creación y destrucción de objetos, la memoria poco a poco va quedando fragmentada. Esto quiere decir que, aunque tengamos suficiente memoria disponible, esta puede estar dividida en muchos bloques pequeños, en lugar de un único hueco con todo el tamaño disponible.

Los Sistemas Operativos modernos, y la propia plataforma .Net, tratan de evitar esto con técnicas de Compactación, y aunque reducen notablemente el problema, no lo eliminan por completo. Este completo artículo describe en detalle la gestión de memoria del Garbage Collector de .Net, y la labor de compactación que realiza.

¿En qué afecta la fragmentación? En mucho, ya que si vuestra aplicación necesita reservar un Array contiguo de 10 MB, y aunque todavía haya 1GB de memoria disponible, si la memoria está muy fragmentada y el sistema no es capaz de encontrar un bloque contiguo de ese tamaño, obtendremos un OutOfMemoryException.

En .Net, la fragmentación y compactación de objetos en memoria guarda una estrecha relación con el tamaño de éstos. Por eso, el siguiente apartado hablará un poco sobre este tema.

Grandes objetos en memoria

A la hora de reservar memoria para un único objeto, la plataforma .Net establece ciertos límites. Por ejemplo, en las versiones de .Net 1.0, 2.0, 3.0, 3.5 y 4.0, ese límite es de 2GB. Tanto para plataformas x86 como x64, ningún objeto único puede ser mayor de ese tamaño. Es así de simple. Únicamente a partir de .Net 4.5 este límite puede ser excedido (en procesos x64 exclusivamente). Aunque sinceramente, salvo rarísimas excepciones, si necesitas reservar más de 2GB de memoria para un único objeto, quizá deberías replantearte el diseño de tu aplicación.

En el mundo .Net, el Garbage Collector clasifica a los objetos en dos tipos: objetos grandes y objetos pequeños. Es una división bastante gruesa, la verdad, pero es así. ¿Qué considera .Net como un objeto pequeño? Todo aquel que ocupe menos de 85000 bytes.

Cuando el CLR de .Net es cargado, se reservan dos porciones de memoria diferentes: un Heap para los objetos pequeños (también llamado SOH, o Small Objects Heap), y otra para los objetos grandes (también llamado LOH, o Large Object Heap), y cada tipo de objeto se almacena en su Heap correspondiente.

¿En qué afecta todo esto al tema que estamos tratando? Sencillo, compactar objetos grandes es costoso, y a día de hoy, simplemente no se hace. Los objetos considerados “Grandes”, y que se introducen en el LOH, no se compactan (aunque el equipo de desarrollo advierte que pueden hacerlo algún día). Como mucho, cuando dos objetos grandes adyacentes son liberados, se fusionan en un único espacio de memoria disponible, pero ningún objeto es “movido” para realizar tareas de compactación.

Este fantástico artículo contiene muchísima más información acerca del LOH y su funcionamiento.

Arrays C# en los límites de la memoria

En C#, los Arrays Simples (de una dimensión) son una de las formas más comunes de consumir memoria, y debes saber que el CLR los reserva siempre como bloques continuos de memoria. Es decir, cuando instanciamos un objeto de tipo byte[1024], estamos solicitando al sistema un único bloque continuo de 1KB, y se generará un OutOfMemoryException si no encuentra ningún hueco contiguo de ese tamaño.

Cuando es necesario utilizar un Array de más de una dimensión, C# nos ofrece distintas opciones:

Arrays anidados, o arrays de arrays

Declarados como byte[][], suponen el método clásico de implementar arrays multi-dimensionales. De hecho, en lenguages como C++, es el único tipo de array multi-dimensional soportado de forma nativa.

En lo relativo a memoria, se comportan como un array simple (un único bloque de memoria), en el que cada elemento es otro array simple (esta vez del tipo declarado, y que también es un bloque único en memoria, pero distinto a los demás). Por lo tanto, en lo que a bloques de memoria se refiere, un array de tipo byte[1024][1024], utilizará 1024 bloques de memoria distintos (cada uno de 1024 bytes).

Arrays Multi-Dimensionales

C# introduce un nuevo tipo de Arrays, soportado de forma nativa: los arrays multi-dimensionales. En el caso de 2 dimensiones, se declaran como byte[,].

Aunque son muy cómodos de utilizar (disponen entre otras cosas de métodos como GetLength, para saber el tamaño de una dimensión), y su instanciación es más sencilla, su representación en memoria es diferente a la de los arrays anidados. Éstos se almacenan como un único bloque de memoria, del tamaño total del array.

En el siguiente apartado estableceremos una comparativa entre ambos tipos:

Comparativa: [,] vs [][]

El array 2D [,] (se almacena en un solo bloque):


  • Utiliza menos memoria total (no tiene que almacenar las referencias a los n arrays simples)
  • Su creación es más rápida: reservar un bloque grande de memoria para para un solo objeto es más rápido que reservar bloques más pequeños para muchos objetos.
  • Su instanciación es más sencilla: una sola línea basta (new byte[128,128]).
  • Proporciona métodos útiles, como GetLength, y su uso es más claro y limpio.


  • Encontrar un solo bloque de memoria continuo para el array puede ser un problema, si éste es muy grande o nos encontramos cerca del limite de RAM.
  • El acceso a los elementos del array es más lento que en arrays anidados (ver abajo)

El array anidado [][] (que se almacena en N bloques):


  • Es más fácil encontrar memoria disponible para el array, ya que requiere de n bloques de tamaño más pequeño, lo cual debido a la fragmentación, suele ser más probable que encontrar un único bloque más grande.
  • El acceso a los elementos del array es más rápido que en los arrays 2D, gracias a las optimizaciones del compilador para manejar arrays simples (en definitiva, un array de arrays se compone de muchos arrays 1D).


  • Utiliza más memoria total (tiene que almacenar las referencias a los n arrays simples)
  • Su creación es más lenta, ya que hay que reservar N bloques de memoria, en lugar de uno solo.
  • Su instanciación es un poco más molesta, ya que hay que recorrer el array instanciando cada uno de sus elementos (ver Tip más abajo).
  • No proporciona los métodos disponibles en los arrays 2D, y su uso puede ser un poco más confuso.

Este blog explica muy bien esta comparativa.


Cada usuario debe escoger el tipo de array que más le convenga en función de su experiencia y el contexto concreto en el que esté. No obstante, un desarrollador que habitualmente utilice gran cantidad de memoria, y preocupado por el rendimiento, tenderá a escoger siempre arrays anidados (o arrays de arrays [][]).

Tip: código generico para instanciar arrays anidados

Dado que instanciar un array de arrays es un poco molesto y repetitivo (y ya dijimos aqui que no conviene duplicar código), el siguiente método genérico se encargará de esa tarea por vosotros:

        public static T[][] Allocate2DArray<T>(int pWidth, int pHeight)            
            T[][] ret = new T[pWidth][];
            for (int i = 0; i < pHeight; i++)
                ret[i] = new T[pHeight];

            return ret;

Espero que os Sirva !!!

Thursday, 11 October 2012

De radares, y otros sinsentidos

Conste por adelantado que la labor de la policía me parece indispensable. Nunca aviso al resto de conductores (con la típica ráfaga) cuando veo un control de cualquier tipo, ya que me parece importante que detecten y neutralicen a los que no van en condiciones. Diré también que tengo todos los puntos del carnet. Me considero un conductor prudente y sensato.

También diré que estoy plenamente de acuerdo con la colocación de radares. Eso sí, totalmente visibles y anunciados. No existe método más efectivo para asegurarse de que todo el mundo frena en un punto determinado especialmente peligroso.

Dicho esto, creo que es de recibo salirme de mi norma habitual, y denunciar un par de radares ocultos en los que el objetivo claro no es salvar vidas, sino poner unas cuantas multas de más.

Dos ejemplos flagrantes, en Pamplona:

Calle del Muelle

Me acabo de enterar que últimamente suelen estar con el radar móvil en la Calle del Muelle de Pamplona. Totalmente ridículo y absolutamente recaudatorio. ¿Por qué? Pues porque es la calle paralela a las vías del tren, al lado de la estación de la Renfe. Es decir, salvo en la estación (donde sí me parece apropiado un límite acorde a los pasos de cebra), en el resto muy poca gente cruza la calle, puesto que no hay ningún sitio donde cruzar (solo una valla metálica que delimita las vías). Ver foto:


El primer problema es que, incomprensiblemente, esa es una de las calles escogidas por el Ayuntamiento para establecer el limte reducido de 30 Km/h. Conste también que me parece un límite adecuado para algunas calles del centro, extremadamente estrechas y peligrosas. Pero... ¿ahí?.

Pues bien, los señores policías han escogido ese punto para ponerse a menudo con el radar móvil bien camufladito. Vamos, que estarán rellenando las arcas públicas a ritmo frenético... Así que mucho cuidadín con esa calle, que no invita para nada a ir a 30, y con ir a 70 ya es delito (de cárcel)...

Autovía del Camino

En Cizur Mayor, debajo del Arco de Luz en la Autovía del Camino, también se rebajó recientemente el límite de velocidad. Es una cuasi-autovía (dos carriles en cada sentido), pero en este punto el nuevo límite es 80 kmh, ya que a horas punta, se generan muchísimos atascos, con los consiguientes accidentes por alcance. Imagen del punto exacto:


Dejo para otro momento la verdadera causa de esos atascos (una desastrosa planificación en las conexiones de dicha autovía con el resto de rondas de Pamplona, que obligan a TODOS los conductores a confluir en un semáforo, aunque su destino sea Paris).

Volviendo al tema de los radares, tengo que decir que entendería que la policía colocara el radar en esos momentos de atasco: a las 7 y 9 de la mañana, etc. Pero no, el momento que escogen es: TODOS los sábados, de madrugada (a eso de la una o las dos de la mañana).

Suele tocarme pasar, al volver del pueblo, y doy fe de que a esas horas pasa un coche cada minuto. Eso sí, el 80% de ellos, pasan a más de 80, ante la evidente carencia de peligro (dos carriles para ti solo, y ni un solo coche alrededor, ni en tu sentido ni en el contrario).

Así que ya sabéis, si entráis a Pamplona por ese punto, y veis un coche (generalmente un Peugeot 407 oscuro) subido a la acera con las luces de emergencia, vigilad vuestra velocidad. Ya que si seguís vuestro sentido común, tranquilamente circularéis a 120…

Saturday, 29 September 2012

Boot time comparison: All generations of iPhone vs Nokia Lumia 800

This video completes the boot time comparison made by iClarified with an additional contender: the Nokia Lumia 800 with Windows Phone 7.5, which beats even the very last iPhone 5 in terms of boot time.


Please note: This video is a second version of another one published 3 days ago. It has been remade to fix a small fps conversion error present in the previous version (the iPhone part was treated as if it was 30 fps, when it was 24 fps). That involved it being displayed faster than it should, and therefore showing a wrong boot time measurement for the Lumia (which was displayed correctly, at 30 fps). Nokia Lumia 800 boots in 18 seconds, not 22.


The boot time results are awesome:

          • Nokia Lumia 800: 18.17 secs
          • iPhone 5: 24.88 secs (6.5 seconds slower !!)

I ♥ Nokia        -        I ♥ Windows Phone

Wednesday, 26 September 2012

Top evil stuff

Now that the September Fail Compilation is out…

… might be a good moment to remind our Governments the list of top evil things, sports and places… Maybe it was a good idea to set special taxes for all of them. After all, they are responsible of 80% of broken bones at hospitals… Sonrisa

Top evil THINGS

Lunch Tables: In all possible forms, they have something special. People try to jump over them, to grind them, to skate them… Everything !


Treadmills: There some kind of magnetic attraction between these things and clumsy people…


Zip lines and tirolines: No, it won’t probably support your weight… And even if it does, your arms won’t be strong enough… It’s just a matter of physics…


Motorbikes (specially in snow, water, or motocross): Too many “pro-pilots” out there…


Diving boards: It was just not a good idea to invent this evil thing… (including epic comment by the father… “help him!”)


Pole-dancing bars: Why girls have some kind of magical attraction to this thing?

Trampolines: Pure evil….


Skateboard: a.k.a, the widow-maker… (warning! explicit content)



Top evil PLACES

What about places? No need to say that bike and skate parks are in the top ranking positions. But what about weddings?

And playgrounds?

Top evil SPORTS

Again, anything with wheels is on the top of the ranking, specially skateboarding. But what about Parkour?

I just can say… Ouch !!!!!

Thursday, 20 September 2012

Cine y Series Españolas –un desastre muy evitable-

En este post voy a tratar de explicar por qué no me gustan las series Españolas, salvo contadísimas excepciones. Dejando a un margen las comedias facilonas y absurdas (donde no hace falta esmerarse mucho en ningún aspecto, solo hacer reír), y excepciones como “Cuéntame”, que no lo hace tan mal en muchos de los aspectos que comentaremos aquí, las demás son un puñetero desastre. Por muchos motivos.


1 - Temática

En primer lugar, la originalidad de la temática es, generalmente, nula. Cuando no aprovechan vergonzosamente el tirón de tragedias como la de “Niños Robados”, se limitan a plagiar lo que se hace en USA (tanto en el cine como en la televisión). Este magnífico post deja bien claro de qué hablo. Su autor ha hecho un trabajo genial que me voy a permitir fusilar parcialmente y completar aquí:

Downton Abbey y Gran Hotel

"Downton Abbey" –> "Gran Hotel"

Cheers vs Cheers española

"Cheers" –> "Cheers"

Las chicas de oro originales y las españolas

"Las chicas de oro" –>"Las chicas de oro"


Piratas del Caribe –> "Piratas"… Hasta el cartel y el logo son plagios…

Series policiacas

"CSI", "El mentalista" –> "Génesis: en la mente del asesino" u "Homicidios"


"Falcon Crest" –> "Gran reserva"

Los protegidos = Héroes + Los Serrano

"Héroes" –> "Los protegidos"

Ángel o Demonio vs Crepúsculo

"Crepúsculo" –> "Ángel o demonio"

Doctor Mateo vs Doctor en Alaska vs House

"House" + "Doctor en Alaska" = "Doctor Mateo"

"Urgencias" –> "Hospital Central"


"Prison Break" –> "La fuga"


"Perdidos" + "Waterworld" = "El barco".

Roma vs Hispania

"Roma" –> "Hispania"


"Los Borgia" –> “Los Borgia”


"Los Tudor" –> "Toledo"


Assasin’s Creed –> Águila Roja


Mr. Selfridge –> Galerías Velvet


Revenge –> Sin identidad

En fin, ¿algo que añadir? Yo me quedo sin palabras al ver esto…

2 – Actores y guionistas

En cuanto a series británicas y americanas, muchas veces las veo en versión original. Pero incluso cuando no es así y a la interpretación del actor le han calzado por encima la voz de otro, incluso en esos casos suelo creerme lo que veo. Por lo general, los actores americanos y británicos se meten muchísimo más en el papel. Para ellos, lo primero es que la interpretación resulte creíble, por encima de su imagen. Estudian el personaje, la forma de hablar de la época, la forma de moverse y expresarse. Se asesoran, y se concentran plenamente en ello. Los actores españoles, salvo excepciones, dejan mucho que desear en todos estos aspectos. Y eso resta realismo.

Si a eso le sumamos que los guiones muchas veces son de risa, pues poco podemos hacer. Cuando veo algún episodio de series como Aguila Roja y compañía, me muero de risa al ver cómo hablan los personajes. Parece que están en el “insti”, colega…

Señores, es muy poco probable que en la antigua Roma, o incluso en el siglo XVII, se hablara así. Y eso resta realismo.

3.- Estética

Yo entiendo que un actor vive de su imagen, y que le joda que le saquen feo. Pero señores, esos peinados seguro que no existían hace 600 años. Esa ropita inmaculada, esas manos de manicura y ese cutis impoluto (con una media barba cuidada para engañar), ese cuero recién salido de la tienda. Esos tejidos modernos que no encajan hace 2000 años. Es que no tienen ni una mancha, oigan… Y eso resta realismo.

Mientras que en EEUU han evolucionado de esto:


a esto:

En España seguimos igual que estaban ellos hace 50 años. ¿Os fijáis en la imagen de Russel Crowe? Pelo desaliñado, sudado y sangrando, con las manos llenas de mierda y la ropa rota y sucia.


Casi casi igual que en Águila Roja:

Camisa blanca inmaculada, manicura perfecta (leñe, hasta hoy en día la gente tiene más roña en la uñas), capa de tejido industrial que SEGURO no existía en el XVII… En fin, que parece que va disfrazado de carnavales. Y eso resta realismo.

4 - Luz, color y formato

Todo lo mencionado en el apartado 3 sería disimulable si las productoras españolas eligieran mejor los formatos y se aplicaran un poquito en la etapa de post-producción.

Entiendo que no tenga sentido en “Los Serrano” o en “La que se avecina”, pero si quieres rodar una serie de aspecto cinematográfico como “Hispania” u otras, por el amor de Dios, rueda SIEMPRE en 16:9 o mejor aún, en 21:9.

Y lo que es aún más importante: la luz y el color. Es necesario trabajar muchísimo la iluminación. Y esto es, muchas veces, bastante asequible, de hecho. Solo hay que empeñarse, y tener un mínimo de conocimientos.

Un ejemplo: el siguiente video muestra parte de los decorados de Rivendell, en El Señor de Los Anillos. Como está grabado in-situ, con una cámara normal y sin post-producción, podréis apreciar que, de hecho, son bastante cutres. Se nota a la legua que son de cartón piedra o de papel pintado, muy al estilo de las series españolas. Entonces, qué marca la diferencia?

La luz. El color. La ambientación. Los planos. La post-producción. Como veis, no se trata de construir un castillo o un palacio de verdad, piedra a piedra. Y para muestra, un botón:

5.- Ejemplo

Vamos a coger todos los aspectos mencionados en los anteriores apartados, y vamos a aplicarlos a un fotograma de Águila Roja. En concreto a éste:

Es un plano triste, en el que el muchacho parte cabizbajo con un saco al hombro, con sus pertenencias. El formato es correcto (16:9), pero sin embargo, la ambientación, la luz y el color escogidos para el rodaje denotan todo lo contrario a lo que se pretende: alegría, verano, naturaleza, limpieza, aire fresco.

imageSi os fijáis en alguien que sabe hacer las cosas, como Peter Jackson… ¿En qué planos de El Señor de los Anillos utilizó este tipo de luz? ¿Acaso cuando Frodo partía de casa de Bilbo en medio del drama que se le venía encima? No. La utilizó en los primeros planos, en los que se muestra la comarca como un lugar idílico. Cuando todavía no hay problema alguno, y todo va bien. Con una música jovial y risueña, con todos los personajes pasándolo bien y sonriendo. Ahí sí encaja esa puesta en escena (ver a la derecha). Pero no aquí. Han escogido una configuración que no ayuda absolutamente nada a transmitir el dramatismo del momento. En definitiva, están restando credibilidad. Por muy bien que lo haga el chaval. Por muy bien que actúe. No hay nada que hacer, la escena está perdida solo por no tener cuidado con éstas cosas.

En este caso, lo ideal hubiera sido rodar en un día nublado, o mejor aún, con una lluvia que aumentara el dramatismo. Pero dado que ya no es posible cambiar eso, nos fijaremos en lo demás: queremos transmitir tristeza, frialdad. Por lo que habrá que usar colores mucho más azules y fríos, como éstos:


Además, añadiremos algo que debería estar presente en TODOS los planos de un rodaje que pretende aparentar ser del siglo XVII: imperfecciones. Las imperfecciones deben estar por todas partes (peinados, ropa, ambientación), y añadirlas a los fotogramas como un proceso de post-producción también ayuda. Sin estar reñido con rodar en FullHD, o resolución 4K, si la imagen está un poquito sucia, un pelín “vieja”, ayudar a transmitir la sensación adecuada. Por eso, añadiremos un par de filtros para acrecentar este efecto:


También vamos a romperle un poco la ropa y ensuciarlo, que todos los días veo niños que salen del colegio más sucios que eso… Si la comparas, verás que esta imagen es muchísimo más triste que la inicial (incluida de nuevo abajo):


El original:

6 - Otro ejemplo

Con las caras pasa más de lo mismo. No importa cómo de bueno sea el actor, si la ambientación y el maquillaje no ayudan, no tiene nada que hacer. Lo siento, pero Francis Lorenzo, por muy buen actor que sea, no tiene una cara extremadamente dramática.

El peinado tampoco ayuda. Ni el maquillaje. Ni la ausencia total de manchas e imperfecciones. Nuevamente, ¿qué buscan los productores? ¿Que el señor Lorenzo salga fantástico, o que su serie resulte creíble?

Para saber cómo dotar a una cara de más personalidad, o de más fuerza, solo hay que ver este vídeo:


La HBO y la NBC están demostrando que se puede hacer series realmente alucinantes, con calidad cinematográfica, y que se puede ganar mucho dinero con ello. No hay más que ver Juego de Tronos, Érase una vez, o la inminente Revolution:

No creo que en España no haya actores o guionistas de calidad. Si se empeñan, saben hacerlo. Pero hay que escoger al actor adecuado, escoger un guión adecuado, y olvidarse de salir guapos en la foto. Un guerrero romano era un bárbaro, por definición, y seguro que iba muy sucio. Además, Llongeras todavía no había abierto sucursal en Roma, así que el pelo se lo cortarían a machete… Si cuidamos esas cosas, nos exigimos el máximo, y trabajamos bien la post-producción, sin duda que en España podremos hacer cosas como éstas:


O los alucinantes efectos especiales de la segunda temporada:

Creo sinceramente que los productores harían bien en tratar de hacer un único buen proyecto, que les reporte muchos millones, que empeñarse en hacer muchas pequeñas versiones abaratadas, plagiadas y cutres de lo que hacen los demás. Se gastan millonadas para obtener un rédito muy dudoso, haciendo un producto que podría mejorarse notablemente simplemente con poner un poquito de atención.

Una pena…

Monday, 17 September 2012

Properly calculating the diffuse contribution of lights in HLSL Shaders

It’s been many years since Vertex and Pixel Shaders came out, and several years too since the Fixed Pipeline is deprecated, but there are still many questions in the forums out there asking about how to properly calculate the diffuse contribution of Lights. This paper has a great tutorial about the issue, and includes a whole Shader that mimics the Fixed Pipeline behavior. However, we will see here how to perform just the basic calculations, just in case you don’t need to emulate the full pipeline.
First thing is to write some D3D9 code that allows you to switch from the old Fixed Pipeline and your own Shaders, using the same parameters. Doing so, you will easily find any behavior differences in light calculations. You can read more about how D3D9 Fixed Pipeline calculates lighting in this page.
When writing shaders, people tend to calculate the diffuse contribution like:
Out.Color = (materialAmbient * lightAmbient) + (materialDiffuse * lightDiffuse * dot(Normal, L));
Where L is the vector from the vertex position (in world coordinates) to the light.
Apart from not doing any specular or emissive calculations (which could not be necessary in many cases, depending on your scenario), there are several mistakes in that approach:
1.- You don’t want the dot to return negative values, because it will black out colors wrongly. So, you need to clamp it to the 0..1 range, using the saturate operator: saturate(dot(Normal, L))
2.- In order to get the same results as the Fixed Pipeline, you should include Attenuation calculations, because they modify the intensity of light with the distance between the point being lit and the light source. Attenuation (as opposed to what its name suggests), not only attenuates light, but also can increase intensity in some circumstances. (See below how to properly calculate attenuation factors)
3.- Once you are calculating attenuation, you should remove the materialDiffuse factor from the previous equation, as you don’t want it to be attenuated too. You will apply it later, when the entire lighting contribution is properly calculated and attenuated.
Keeping those 3 things in mind, the final calculation in a vertex shader would be:
    float4 LightContrib = (0.f, 0.f, 0.f, 0.f);
    float fAtten = 1.f;

    // 1.- First, we store the total ambient light in the scene (multiplication of material_ambient, light_ambient, and any other global ambient component)
    Out.Color = mMaterialAmbient * mLightAmbient;

    // 2.- Calculate vector from point to Light (both normalized and not-normalized versions, as we might need to calculate its length later)
    float pointToLightDif = mLightPos - P;
    float3 pointToLightNormalized = normalize(pointToLightDif);
    // 3.- Calculate dot product between world_normal and pointToLightNormalized
    float NDotL = dot(Nw, pointToLightNormalized);        
    if(NDotL > 0)
        LightContrib = mLightDiffuse * NDotL * mLightDivider;     
        float LD = length(pointToLightDif);        
        if(LD > mLightRange)
            fAtten = 0.f;
            fAtten = 1.f/(mLightAtt0 + mLightAtt1*LD + mLightAtt2*LD*LD);
        LightContrib *= fAtten;
    Out.Color += LightContrib * mMaterialColor;
    Out.Color = saturate(Out.Color);



First image is the Programmable version. You can slightly tell it by the reflections on the windows.
Second image is the Fixed Pipeline version (no real time reflections on windows):

Tuesday, 24 July 2012

Simax Simulator to be used by the DGT as a diagnostic tool for brain damage

The DGT (Dirección General de Tráfico, the Spanish organization in charge of traffic legislation and the Imserso (, the Spanish Institute for the third age and social services, are using one of our Simax Simulators to test the ability to drive on people suffering from some kind of brain damage. The simulator allows them to safely drive through a real environment and to interact with other drivers, while the system automatically monitors and evaluates the way they drive, presenting a complete report with possible failures. Then, experts process that information, along with the results of other tests, to determine if the driver should be suggested to continue driving or not.

More info at:

[Please navigate to minute 36 to access to the info]


Simulador Simax como herramienta de diagnóstico para personas con daño cerebral (minuto 36)

La DGT (Dirección General de Tráfico), así como el Imserso (Instituto de Mayores y Servicios Sociales), están utilizando uno de nuestros simuladores Simax para evaluar la habilidad para conducir en personas que han sufrido algún tipo de daño cerebral. El simulador permite a dichas personas conducir de forma totalmente segura por un entorno real, e interactuar con otros conductores, mientras evalúa y monitoriza automáticamente el modo en que conducen, para presentar finalmente un completo informe con los posibles fallos cometidos durante el proceso. Entonces, expertos en la materia analizan dichos resultados, conjuntamente con los de otros tests realizados, para determinar si es aconsejable que esa persona siga conduciendo o no.

Más información en: