sábado, 1 de diciembre de 2007

Dale aire al navegador exprimiendo el Javascript

Una parte muy importante de la Web actual es la visualización de animaciones. Ofrecen un añadido importante a cualquier interfaz de usuario siempre que se usen en su justa medida. En el ámbito Web podemos utilizar principalmente GIFs animados para el keyframing o generar animaciones de forma dinámica orientadas, en principio, a movimiento de objetos. Ésta segunda opción es muy interesante y flexible, aunque requiere codificar un pequeño Framework.

Las animaciones dinámicas requieren como mínimo de un Timer para ir notificando las actualizaciones de cada objeto. Javascript tiene este soporte aunque la resolución del Timer en la mayoría de los navegadores deja bastante que desear. De cualquier modo, si se utiliza una estrategia inteligente podemos aprovechar sus recursos de manera óptima.

Cuando se precisa animar algo siempre recurrimos al socorrido setInterval o setTimeout. Tendemos a crear uno por cada grupo de objetos que se van a mover al unísono. Esto no es beneficioso para el comportamiento del navegador principalmente porque se empieza a saturar la ejecución de hilos por cada Timer instanciado (ésto también depende del intérprete del navegador y su gestión interna de hilos).

A mí me gusta siempre extrapolar el diseño de algunas partes de una aplicación (sea Web o de escritorio, orientada a gráficos o incluso bases de datos) al campo de los videojuegos y en este caso tengo una buena piedra de toque. La idea es utilizar una clase manager que notifique a todos los objetos afectados del momento en que tienen que actualizar su estado interno. Este manager utilizará únicamente un Timer, con el ahorro de procesamiento para el navegador que eso conlleva. Si piensas que puede ser lento o no sincronice correctamente los objetos visuales afectados, permíteme que te diga que funciona como un reloj ;-)

La base del diseño lo forman simplemente una interfaz IAnimatable (debería darle una vuelta a este nombre :-D ) y una clase AnimatorManager. IAnimatable debe implementarla toda clase que necesite actualización en base a una frecuencia. Por su parte, AnimatorManager será la clase maestra encargada de manejar a su antojo a todos los implementadores de la interfaz, notificando cuando corresponda.


//Interfaz para todo componente susceptible de ser animado vía Timer
WebDock.IAnimatable = function() {}
WebDock.IAnimatable.Prototype = {
    onTick: function(){}
}
WebDock.IAnimatable.registerInterface('WebDock.IAnimatable');
 
//Manager de animación que controla el Timing de todos los implementadores de IAnimatable
WebDock.AnimatorManager = function(fps) {
    this._items = new Array();

    this._frameTime = 1000/fps;

    this._isprocessing=false;
    _oThis = this;
}

WebDock.AnimatorManager.prototype = {
    run: function() {

        this.timerID = setInterval(this.pump, this._frameTime);

    },
    
    add: function(animatable) {
        this._items.push(animatable);
    },
    
    remove: function(animatable) {
        for (var i=0;i<this._items.length;i++)
        {
            if (animatable==this._items[i])
            {
                this._items.splice(i, 1);

                i=this._items.length; //es más rápido que 'break'
            }
        }
    },
    
    //llama a la actualización de todos los componentes de animación registrados
    pump: function() {
        if (!_oThis._isprocessing) //establecemos contención para mantener sincronización correcta de cada frame
        {
            _oThis._isprocessing=true;
            for(var i=0;i<_oThis._items.length;i++)

            {
                var animatable=_oThis._items[i];
                animatable.onTick();
            }
            _oThis._isprocessing=false;
        }

    },
    dispose: function() {
    }
}
WebDock.AnimatorManager.registerClass('WebDock.AnimatorManager', null, Sys.IDisposable);


Por si a alguien le resulta raro el código Javascript anteriormente expuesto, simplemente apuntar que está desarrollado utilizando el Framework AJAX de ASP.NET. Éste permite herencia, interfaces, enumeraciones, eventos, etc. muy útiles a la hora de orientar a objetos en Javascript.

domingo, 25 de noviembre de 2007

Balancea tu Software

¿Cuántas veces hemos pensado que el diseño de nuestra aplicación, que en un principio era cojonudo, ahora no lo es tanto? ¿Cuántas otras nos hemos dado cuenta que después de un tiempo sin tocar nuestros desarrollos es complicado su entendimiento y mantenimiento?

Dependiendo del tipo de aplicación o componente Software que estemos diseñando, debemos tener en cuenta qué prima en el desarrollo del mismo. Por un lado tenemos el crear un buen diseño que permita desarrollos futuros sin desestabilizar lo ya realizado. Por otro está el siempre desquiciante tema de las optimizaciones que todo programador "tunea" de forma continua para hacer el algoritmo más rápido o el sistema más eficiente. Ésto es especialmente notable en tecnología gráfica y Networking.

El tema del rendimiento normalmente implica un pequeño caos en el desarrollo debido a que se tiende a concentrar mucho las operaciones que realiza una tarea determinada. Cuantas menos llamadas a funciones mejor; cuantas menos capas de clases mejor, etc. Prefiero tratar directamente con tipos primitivos locales que con Wrappers o adaptadores que no hacen otra cosa que llamar y llamar a otros de su calaña para obtener un mismo resultado a costa de una pérdida de rendimiento... Bien, todo esto está muy bien para secciones críticas del código y/o pequeños programitas pero no es muy recomendable en desarrollos de cierta envergadura.

Sólo hay que pensar un poco en el desarrollo en equipo de cualquier empresa del negocio del Software para darse cuenta que se precisa el trabajo coordinado de muchos para que cada parte/componente del sistema se integre correctamente y sea fácilmente mantenible por cualquier otro que esté especializado en ese área de desarrollo concreto. Aún así, sobrediseñar tampoco es bueno pues tiende a complicar un sistema que podría resolverse con menos abstracciones/subclasificaciones y yendo al grano en ciertas partes del mismo.

¿Dónde está el umbral entre un buen diseño y un código eficiente? Las mejores armas que tenemos a nuestro alcance es la experiencia y el profundo conocimiento de las herramientas utilizadas para lograrlo.

Ahí va una pildorita.

domingo, 18 de noviembre de 2007

Singleton: el Gentleman

También conocido en mi ambiente de trabajo como chicletón :-D es quizá uno de los patrones de diseño más utilizados. Como muchos sabréis, asegura que una clase tenga una única instancia además de poseer la característica de ser un punto global de acceso a ella para toda la aplicación. Todo un caballero, sí señor...

En C# la forma más eficiente y segura de aplicar este patrón es la siguiente:
public sealed class Singleton 
{
    private Singleton() {}
    public static readonly Singleton Instance = new Singleton();
}

Es segura porque es el propio compilador el encargado de asegurar el Thread-Safe en la inicialización de la clase. Es eficiente porque evitamos la pérdida de rendimiento si utilizáramos una implementación mediante la cláusula volatile aplicando, por ejemplo, otro patrón interesante: Double Checked Lock. Veamos cómo:

public sealed class Singleton 
{
   private Singleton() {}
   private static volatile Singleton instance;
   private static object syncRoot = new object();
 
   public static Singleton Instance 
   {
     get 
     {
        if (Singleton.instance == null) 
        {
           lock (syncRoot) 
           {
              if (Singleton.instance== null) 
              {
                 Singleton.instance= new Singleton();
              }
           }
        }
        return Singleton.instance;
     }
   }      
}

Otra implementación podría aplicarse en genéricos a partir de Framework 2.0, ya que versiones anteriores no soportan esta característica en el lenguaje.

martes, 13 de noviembre de 2007

PagedGeometry: poderoso Add-on para Ogre3D

Echando un ojo hace unos días a la actualidad del motor gráfico OGRE3D se anunciaba la v1.0 de PagedGeometry, un espectacular plugin que renderiza zonas abiertas endiabladamente rápido.

La cantidad de árboles y hierba que representa en pantalla, incluyendo animación, es impresionante. Soporta LOD, geometría paginada (incluso dinámicamente), diferentes capas de texturas para el terreno...



Podéis ampliar más información aquí.

miércoles, 7 de noviembre de 2007

Brainstorming de Game Engine

Estoy dedicando esfuerzos en mi tiempo libre (que no es mucho) en la creación de un "modesto" motor de juegos para prototipado rápido. Cogiendo ideas de aquí y allá he decidido basar el Core del sistema en servicios; muy similar a como está diseñado XNA pero yendo un poco más allá en aspectos como la abstracción o la multitarea. Cada servicio gestionará un aspecto concreto del motor (servicio gráfico, red, dispositivos de entrada, etc.). Lo interesante y desafiante desde mi punto de vista, del diseño de una arquitectura orientada a servicios, es el desacoplamiento de cada uno de ellos en el sistema pero con una posible interacción entre ellos de manera "transparente" (léase Interfaces conocidas evitando así la reflexión en la medida de lo posible).

Además, el Framework tiene que ser flexible y cómodo de extender para poder correr cada servicio implementado dentro del hilo principal de la aplicación (el juego) o en hilos adicionales. Todo ello sin que el programador (en principio yo mismo) requiera de conocimientos extensos sobre procesamiento en paralelo y demás hierbas. Un servicio implementado para la física del juego, por ejemplo, puede ser interesante que corra en un hilo aparte, de igual modo que el servicio de red.

Para que el código del juego en sí sea totalmente independiente de la implementación de cada servicio, será necesario crear adaptadores mínimos para los diferentes servicios que utilice el juego. Este punto tiene el inconveniente que nuevos servicios levantados "en caliente" en principio no podrán ser utilizados por el juego ya que no se ha definido el adaptador apropiado para él en tiempo de compilación ni código que lo gestione. Esto me lleva a pensar que toda la arquitectura orientada a servicios podría no tener mucho sentido pues cada uno de ellos debe ser conocido por el código del juego en sí. De todos modos, le daré vueltas a este asunto con más calma.

Para los servicios de gráficos y físicas tengo pensado utilizar Ogre3D y Newton (en concreto mediante los Wrappers de Mogre para .NET). En principio el de red lo intentaré implementar yo mismo (hay temas muy interesantes ahí como la latencia, dead reckoning ...) si tengo tiempo y buen ritmo de desarrollo.

Según avance iré desembuchando acerca de cómo llevo este asunto.

domingo, 4 de noviembre de 2007

Proyecto GeoMadrid

GeoMadrid es el proyecto en el que he estado trabajando últimamente. Mis responsabilidades han abarcado desde el análisis al despliegue de la aplicación (vamos, todo el ciclo de desarrollo). Por citar algunas de las tecnologías y Software aplicado:
  • .NET Framework 2.0, HTML, CSS, ASP.NET, AJAX, Web Services, Sql Server, etc.
  • Lenguajes: C#, Javascript y SQL

Por supuesto, para hacer posible el desafío tecnológico que representa un servicio como el que ofrece GeoMadrid en esta Web, en la empresa disponemos de un potente servidor Geoespacial que sirve peticiones como un rayo, junto con una Suite de componentes orientados al desarrollo GIS bajo la plataforma .NET de Microsoft.

Os animo a que le echéis un ojo. ¡Oye, sin compromiso!

Todo inicio es complicado...

Y es que el título de esta entrada no es menos cierta cuando se trata de diseñar y crear Software de calidad. Después de varios años trabajando en lo que me apasiona, la creación de Software (sobre todo, lo relacionado con los videojuegos y tecnologías gráficas aplicadas), he decidido publicar este blog más que nada para exponer mis chiskes (léase paranoias), ideas, locuras y demás engendros que se me vienen a la cabeza a la hora de enfrentarse al diseño y desarrollo.

Trabajo principalmente sobre la plataforma .NET de Microsoft, en la cual me siento como pez en el agua y en los últimos años centro mis esfuerzos en la programación Web.

Saludetes.