Lanzamos Cell·SDK1.1

Hace unos días publicamos la nueva versión de Cell·SDK. Podéis descargarlo totalmente gratis y probarlo aquí.

En esta versión hemos incluido un montón de nuevas características que nos facilitan aún más la vida y podéis verlas aquí. Entre otras características nuevas tenemos:

–          Status API: Esta API unifica la forma de acceder a la información de todos los dispositivos Android, iOS y Windows Phone, como por ejemplo al estado de la batería, el ID del dispositivo, la plataforma y un largo etcétera. Podéis descargar Cell·SDK ahora y aprender cómo usarlo en el tutorial de la Status API aquí.

–          Acceso a la cámara: Ahora podemos jugar de manera unificada en todas las plataformas con el nuevo sensor de cámara de una manera sencilla. Leed el tutorial, es muy sencillo.

–          Sistemas de análisis: Hemos incluido una API preparada para integrar diferentes sistemas de analítica para poder ver cómo los usuarios usan las aplicaciones. A día de hoy tenemos disponible la opción que ofrece Localytics pero pronto habrá más. Aquí podéis aprender a usarlo.

Aún hay más características nuevas pero en el post de hoy vamos a ver en detalle las nuevas funcionalidades añadidas con el ScreenManager.

Y es que a la hora de hacer un juego o aplicación es muy importante ofrecer una forma atractiva de crear los diferentes menús que vamos a mostrar. Con la experiencia y el feedback que nos habéis aportado hemos decidido incluir este ScreenManager que muchos os lo habréis implementado varias veces. Pues ahora ya no tenéis que implementarlo ya que lo ofrecemos de fábrica.

El uso es bien sencillo, para verlo en acción descargaos el ejemplo que tenemos en GitHub llamado ScreenManager aquí.

Vamos  a ver el código:

En la clase StaticContent tenemos una nueva variable estática llamada ScreenManager. Esta variable es la que nos va a permitir pasar de una pantalla (o Screen) a otra en nuestro juego o aplicación. Consiste en una colección de las diferentes pantallas que vamos a tener disponibles y que debemos ir añadiendo para poder ir de una pantalla a otra.

Cuando creamos un proyecto nuevo con la plantilla de Cell·SDK se crea la primera pantalla MainScreen.cs y se añade a esta colección por defecto en el archivo Application.cs

///
<summary> /// The main method for loading controls and resources.
/// </summary>
public override void Initialize()
{
    base.Initialize();

<pre><code>StaticContent.Graphics.IsFullScreen = true;
StaticContent.Graphics.ApplyChanges();

StaticContent.ScreenManager.GoToScreen(new MainScreen());
</code></pre>

}

Vamos a ver cómo se usa directamente en la clase MainScreen del ejemplo. En la clase MainScreen.cs hemos definido unas cuantas variables del tipo Image que nos permitirán cargar los diferentes recursos del ejemplo para usarlo luego  como fondo de pantalla y como imágenes de los botones que tendremos en nuestra aplicación.

Pantalla de Inicio

Pero lo que realmente nos interesa es el uso de la variables StaticContent.ScreenManager así que veamos los eventos de release de los diferentes botones. Empezemos por el botón de opciones:

///
<summary> /// Go to options screen.
/// </summary>
///
private void bOptions_Released(Component source)
{
    StaticContent.ScreenManager.PushScreen(new OptionsScreen(), StaticContent.TransitionFactory.FadeBlackTransition);
}

Estamos añadiendo al ScreenManager una nueva pantalla, en este caso la de opciones, y con una transición FadeBlackTransition.Hay un montón de transiciones y añadiremos más en un futuro.

Ahora, en la pantalla de opciones (OptionsScreen.cs):

Pantalla de Opciones

Para seguir el flujo de navegación que estamos haciendo hemos añadido un botón para volver al a pantalla de inicio y en el evento Pressed hemos hecho un PopScreen, para eliminar la pantalla de la colección:

public override void BackButtonPressed()
{
    StaticContent.ScreenManager.PopScreen(StaticContent.TransitionFactory.FadeBlackTransition);
}

¡También con una transición!

Resumen

Hemos visto cómo podemos añadir diferentes pantallas a nuestra aplicación de una manera muy sencilla. Con este ScreenManager ya no tenemos que implementarnos nosotros mismos este tipo de mecanismos. Además tenemos un conjunto de transiciones por defecto bastante interesante que cubre la mayoría de efectos que podemos añadir a la hora de pasar de una pantalla a otra.

Os animo a que os descarguéis el código y probéis las diferentes transiciones que vienen por defecto y si tenéis alguna sugerencia sobre alguna transición que creéis podría aportar valor a las que ya vienen por defecto no dudéis en abrir un hilo en el foro sobre ello y lo estudiaremos.

Espero que sirva.

Juan María Laó Ramos (sígueme en twitter @juanlao)

Resumen Open Space Sevilla

Open Space SevillaHa sido un placer compartir las poco más de 16 horas del fin de semana pasado con tantos Profesionales, con mayúsculas y en negrita, hablando sobre tecnologías webs, metodologías, testing, seguridad, arquitecturas, tablets, marketing, usuarios (flame: esos malditos bastardos), organizaciones, jefes, clientes. Y mejor paro aquí.

Lo mejor del evento ha sido, sin dudarlo en ningún momento, el haber podido asistir.

Si me lo permitís os pondré un pequeño resumen de cada una de las sesiones a las que asistí y las conclusiones que saqué:

  • Seguridad: Pues, al igual que la calidad no es negociable. Los sistemas que diseñamos o implementamos deben tener en cuenta la seguridad desde el comienzo hasta el fin. Para evitar el “ya os lo dije” y asegurarnos una posición con respecto a nuestros competidores. Como dije al principio, es igual que la calidad, no es negociable. Sobre todo a la hora de usar frameworks o herramientas de terceros, debemos auditarlas.
  • Adicto al verde: Si, adicto a que los test que hacemos se pasen, pero claro, para ello hay que hacerlos. Ya sean unitarios, de integración, etc … Yo defino el arte del testing  como un seguro para no acabar en alcohólicos anónimos después de dos intentos fallidos de puesta en producción, y la calidad en principio da igual, lo que quiero es vivir tranquilo y llegar a casa a una hora decente y con la sensación de un trabajo bien hecho.
  • Garajes en Andalucia: Jmbeas quería saber cómo estaba el tema de los emprendedores en Andalucía y se enteró ;). Por lo que vimos no está extendida la cultura del pelotazo, sino la del “quiero lo suficiente como para poder sacar al perro por las mañanas”. Manuel Recena ha resumido muy bien y lo comparto. Espero que nadie lo entienda como una falta de ambición, es todo lo contrario, plantear un plan de negocio basado en un pelotazo es como correr con el coche a 120 por las calles de una urbanización, te la vas a pegar, te vas a hacer daño y lo peor de todo es que vas a hacer daño a mucha más gente.
  • Yo te la mido (La campaña):  Nos presentaron http://twittalicious.com/ una herramienta opensource para análisis de métricas sobre twitter y conocer el impacto de una persona, campaña, empresa  en esta red social. La verdad es que no está nada mal.
  • Rendimiento de aplicaciones PHP: Un debate/charla, en la que vimos una arquitectura bastante completa y buscamos entre todos cómo podríamos mejorarla con componentes y herramientas que nos ayudan según qué eslabón de la cadena queremos optimizar.  Me gustó particularmente ya que el enfoque de cómo mejorar se puede aplicar a cualquier otra tecnología como .NET, Java, Ruby, etc..
  • “Trucos” para rentabilizar un blog: En esta fuimos poquitos, y es que los frikis trabajamos por amor al arte ;).  Sin embargo estaba bastante interesado y surgieron muchas ideas: desde buscar anunciantes en otros blogs de la misma temática que el tuyo, ponerte en contacto con el anunciante y ofrecerte, montar una tienda online de algo relacionado con tu blog y buscar tus proveedores, buscar empresas que mantengan redes de blogs y proponer, por ejemplo, que te hosteen el blog a cambio de generar contenidos y un porcentaje de la publicidad.
  • Inspección continua: Vimos cómo integrar Jenkins, Maven y Sonar para hacer que en cada commit del subversión/github se lancen procesos de análisis estático de código vigilando que se cumplen las métricas que estimemos necesarias. Un par de conclusiones que me gustaron mucho son:  1 esta información se puede usar en las sesiones de revisión de código para seleccionar  aquellas clases que incumplan más métricas como candidatas a analizar y 2 si introduces un sistema de este tipo en un proyecto que ya ha comenzado, más te vale relajar alguna regla e ir poco a poco corrigiendo y manteniendo las métricas tal y como están para por lo menos no empeorar.

De nuevo gracias a tod@s por compartir vuestras experiencias y a la organización por este evento tan espléndido.

Juan María Laó Ramos.

Aliasing en formas geométricas

Aquí tenéis la octava entrega de la serie sobre aliasing

En el post de Multisampling vimos que la GPU “era lenta”, así que el procesado de triángulos también. Las formas curvas complejas se aproximaban por un pequeño número de triángulos, donde cada uno de ellos era lo suficientemente grande como para cubrir varios píxeles de la pantalla.

 Esto creó una situación extraña en los primeros artículos sobre multisampling que se centraban en cómo suavizar los dientes que le salían a los triángulos. Nos acostumbramos tanto a esa forma de ver gráficos que hasta nos parecía hermoso, sin siquiera pararnos a pensar “¡Hey, la cabeza de este tipo sólo tiene 5 triángulos!”

Pero el hardware mejoró. El número de triángulos subió. Un juego moderno usa entre 4000 y 6000 triángulos para un personaje.

Fijaos en la situación:

  • El personaje se pinta de manera que ocupa 1/8 del alto de la pantalla.
  • El juego se renderiza a 720p, así que la imagen resultante es de 90 píxeles de alto.
  • Es decir que se cubren unos 2000 píxeles de la pantalla.
  • Suponiendo que la mitad de los triángulos están detrás de la cara.
  • Tenemos 3000 triángulos en total, cubriendo tan sólo 2000 píxeles de la pantalla.

Con tanto detalle en nuestros modelos, la geometría facial es algo del pasado. En su lugar tenemos un nuevo problema: ¡Hemos sido Nyquistados!

Recordad: para evitar el aliasing debemos tomar al menos dos veces más muestras de salida según la frecuencia más alta de la señal de entrada. Pero resulta que tenemos menos píxeles de salida que triángulos de entrada. Es bastante obvio que esto va a causar aliasing. Con menos píxeles que triángulos, algunos triángulos no aparecerán en la imagen de salida:

Juanma Pixelado

A medida que el objeto se mueva, los triángulos que sean afortunados y tengan un pixel irán cambiando aleatoriamente, así que la imagen se irá distorsionando a medida que los triángulos vayan apareciendo y desapareciendo.

En realidad existe un truco para suavizar el número de triángulos que un modelo debe contener. Para la mejor calidad, querremos que cada triángulo cubra exactamente dos píxeles de pantalla. Si los triángulos son más pequeños que esto, cruzaremos el límite de Nyquist y aparecerá el aliasing. Si son mayores, tu silueta saldrá “poligonizada”.

NO es totalmente intuitivo que el truco sean dos píxeles por triángulo en lugar de uno, pero es verdad. Imaginad un círculo que es aproximado por una serie de segmentos de líneas. A medida que incrementamos el número de segmentos, el círculo se vuelve más y más perfecto. El momento en el que cada segmento va alcanza la longitud de dos píxeles, el círculo se convierte en perfecto. Por lo que añadir más segmentos a partir de aquí no hará ninguna mejora sobre la curva del círculo.

No es práctico tampoco mantener todos los triángulos con el mismo tamaño en la pantalla, ya que nuestro modelo se tiene que pintar a diferentes tamaños a medida que el jugador se mueve por el mundo.

Así que ¿cómo podemos pintar una geometría con muchos detalles sin tener aliasing?

Multisampling (o supersampling si podemos permitírnoslo) nos ayuda a alejar de nosotros el límite de Nyquist, pero sólo con eso no es suficiente para evitar el aliasing en geometrías.

Normalmaps puede ser una técnica poderosa. Tenemos bastantes opciones para evitar el aliasing cuando reconstruimos texturas, de manera que cada vez que podamos tendremos qie eliminar los detalles de nuestra geometría y reemplazarla con un normalmap, que nos ayudará a controlar el aliasing. Solemos pensar que estas técnicas de normalmaps son tan sólo una optimización del rendimiento (reemplazando geometrías caras con una textura) pero también pueden mejorar la calidad visual.

Por último, es importante considerar que el nivel de detalle del modelo puede variar. Cuando el objeto está muy lejos, cambiar un modelo de 6000 triángulos por uno más simple de 1000 o 500 triángulos es una opción que no sólo aumentará el rendimiento, sino que reducirá el efecto de aliasing en geometrías.

Moraleja: cuando hablamos de números de triángulos, más no siempre es lo mejor. Ten cuidado de no pintar más triángulos de los píxeles que ves en pantalla. Ese camino lleva al mundo del aliasing.

Artículo original.

P/D: Síguieme en twitter: @juanlao

Nuevo aspecto

Hola a tod@s.

Después de unos días buscando inspiración y sacando al artista que llevo dentro os presentamos el nuevo aspecto de este amado blog.

Ahora más participativo, más bonito, más todo.

Pero aún no acaba la cosa, esto es sólo el principio. Estad atentos ya que incluiremos nuevas funcionalidades más 2.0.

Gracias a los chicos de Mecus por su inestimable ayuda y profesionalidad.

Mecus