Acabo de ver una noticia sobre "el nuevo mando" que Microsoft incorporará a la 360. El mando eres tú, sin más cachibaches que tu propio body. Lo han presentado en el E3 con Spielberg a la cabeza (yo floto).
Viendo el vídeo realmente impresiona la tecnología, aunque ya saldrá el pavo de turno echando pestes XD
Más información aquí.
martes, 2 de junio de 2009
jueves, 21 de mayo de 2009
Diseñando un ThreadPool
Sin lugar a dudas, la base de todo Framework Multihilo pasa por tener un ThreadPool robusto y rápido, sobre todo rápido. Debe ser capaz de "tragarse" tareas como si estuviera endemoniado :-D
Si ya de por sí diseñar código Thread Safe de forma eficiente es jodido de cojones, lo puede ser más el efecto conocido como thread starvation.
Esta situación se provoca debido a que varios hilos solicitan de forma simultánea una tarea de la cola, generando sobrecarga en la sincronización y disminuyendo el rendimiento de forma notable. El mismo código que te funciona de puta madre en un equipo con DualCore puede ir de pena en un QuadCore o superior.
Otro asunto es el balanceo de carga entre hilos. No puede ser que haya algunos hilos con mucha carga de trabajo en espera mientras otros se rascan la barriga. Así se pueden ir sumando problemas que indican la complejidad que puede entrañar el diseño de un buen ThreadPool.
Para aliviar algunos de los problemas citados, se pueden emplear técnicas como el Work-Stealing Queue. Este patrón es una cola que permite encolar tareas de forma privada (sin bloqueos desde un mismo hilo) y robar tareas desde otros hilos (con alguna penalización en la sincronización).
Un detalle de implementación de un maestro del threading : Joe Duffy
Por cierto, en la nueva versión del CLR (la 4.0) de .NET se está rediseñando el ThreadPool para que sea más eficiente y se pueda enredar con él para variar su comportamiento interno.
Si ya de por sí diseñar código Thread Safe de forma eficiente es jodido de cojones, lo puede ser más el efecto conocido como thread starvation.
Esta situación se provoca debido a que varios hilos solicitan de forma simultánea una tarea de la cola, generando sobrecarga en la sincronización y disminuyendo el rendimiento de forma notable. El mismo código que te funciona de puta madre en un equipo con DualCore puede ir de pena en un QuadCore o superior.
Otro asunto es el balanceo de carga entre hilos. No puede ser que haya algunos hilos con mucha carga de trabajo en espera mientras otros se rascan la barriga. Así se pueden ir sumando problemas que indican la complejidad que puede entrañar el diseño de un buen ThreadPool.
Para aliviar algunos de los problemas citados, se pueden emplear técnicas como el Work-Stealing Queue. Este patrón es una cola que permite encolar tareas de forma privada (sin bloqueos desde un mismo hilo) y robar tareas desde otros hilos (con alguna penalización en la sincronización).
Un detalle de implementación de un maestro del threading : Joe Duffy
Por cierto, en la nueva versión del CLR (la 4.0) de .NET se está rediseñando el ThreadPool para que sea más eficiente y se pueda enredar con él para variar su comportamiento interno.
viernes, 24 de abril de 2009
Parallel Framework Design
El Visual Adrenaline de Intel acaba de publicar un artículo muy interesante acerca de cómo desarrollar un efectivo Framework orientado al procesamiento de juegos en paralelo. Con tanto Core suelto en estos días no está de más ojear este tipo de artículos para tomar ideas aplicables a cualquier tipo de desarrollo, no sólo juegos...
Visual Adrenaline: Designing the Framework of a Parallel Game Engine
Visual Adrenaline: Designing the Framework of a Parallel Game Engine
sábado, 7 de marzo de 2009
Bug en instalador de SQL Server Express 2008
Hace unos días, instalando ese producto de Microsoft, no había "webs" de hacerlo en un equipo que tuviera el mismo nombre de usuario y nombre de equipo. El caso es que cambiando a posteriori el nombre de usuario tampoco se podía. Al final tuve que cambiar el nombre de equipo ¡Tiene pelotas la cosa!
miércoles, 31 de diciembre de 2008
Happy 2009 ;-)
Mis mejores deseos para todos en este nuevo año que entra ya mismo. De hecho, como no espabile con la cena, me comen los liki-likis en las uvas!!!
martes, 11 de noviembre de 2008
LinQ: Yo LinQueo, tú LinQuearás...
Últimamente he estado Offline debido a que mi tiempo libre se ha tornado en dedicación exclusiva a la atención de mi pequeño retoño, nacido recientemente. Espero seguir posteando con más frecuencia a partir de ahora
;-)
Recientemente he empezado a trastear con LinQ principalmente por conocer la tecnología, no por necesidades de desarrollo. Habiendo leído algún libro interesante acerca del tema (LINQ Unleashed) he de admitir que me ha sorprendido gratamente, empezando por el soporte que le han metido a C# para dar cabida a este nuevo framework de consultas integradas:
- Métodos de extensión: Eso de meter funcionalidad añadida a cualquier tipo del CLR (ya sea definido en el lenguaje o propio) aumenta la potencia y riqueza del lenguaje hasta límites insospechados. De hecho, es una de las características me más me gustan.
- Tipos anónimos: Al principio me sonaba a los tipos de Javascript, pero una vez que 'LinQueas', ves rápido la necesidad, sobre todo cuando se trata de proyecciones de tipos con la cláusula Select.
- Expresiones Lambda: Una vuelta de tuerca más a los delegados anónimos.
Es importante recalcar que estas nuevas funcionalidades no son exclusivas de LinQ, de ahí que cualquier programador las recibirá con los brazos abiertos en cuanto empiece a soportarlas en su código.
Una vez empiezas a meter métodos de extensión en tus propias clases, sientes la necesidad de que necesitas más potencia y organización para ciertos retos. En este punto aparecen los proveedores para LinQ. Por defecto el Framework trae varios proveedores interesantes: LinQ to SQL, to Objects, to XML. Crearse uno propio ya es harina de otro costal... Googleando he visto un interesantísimo tutorial creado por el padre de LinQ (Matt Warren).
En principio se trata de implementar un par de Interfaces, pero tengo que admitir que sin ver algo de código, esto no era ni mucho menos fácil (no veía las cosas claras con la manipulación de las expresiones). De hecho, no hay más que ojear el tutorial citado para comprobarlo (atención especial a 'su implementación' del patrón Visitor para desglosar las expresiones).
;-)
Recientemente he empezado a trastear con LinQ principalmente por conocer la tecnología, no por necesidades de desarrollo. Habiendo leído algún libro interesante acerca del tema (LINQ Unleashed) he de admitir que me ha sorprendido gratamente, empezando por el soporte que le han metido a C# para dar cabida a este nuevo framework de consultas integradas:
- Métodos de extensión: Eso de meter funcionalidad añadida a cualquier tipo del CLR (ya sea definido en el lenguaje o propio) aumenta la potencia y riqueza del lenguaje hasta límites insospechados. De hecho, es una de las características me más me gustan.
- Tipos anónimos: Al principio me sonaba a los tipos de Javascript, pero una vez que 'LinQueas', ves rápido la necesidad, sobre todo cuando se trata de proyecciones de tipos con la cláusula Select.
- Expresiones Lambda: Una vuelta de tuerca más a los delegados anónimos.
Es importante recalcar que estas nuevas funcionalidades no son exclusivas de LinQ, de ahí que cualquier programador las recibirá con los brazos abiertos en cuanto empiece a soportarlas en su código.
Una vez empiezas a meter métodos de extensión en tus propias clases, sientes la necesidad de que necesitas más potencia y organización para ciertos retos. En este punto aparecen los proveedores para LinQ. Por defecto el Framework trae varios proveedores interesantes: LinQ to SQL, to Objects, to XML. Crearse uno propio ya es harina de otro costal... Googleando he visto un interesantísimo tutorial creado por el padre de LinQ (Matt Warren).
En principio se trata de implementar un par de Interfaces, pero tengo que admitir que sin ver algo de código, esto no era ni mucho menos fácil (no veía las cosas claras con la manipulación de las expresiones). De hecho, no hay más que ojear el tutorial citado para comprobarlo (atención especial a 'su implementación' del patrón Visitor para desglosar las expresiones).
domingo, 20 de abril de 2008
Paralelizando conexiones más allá de los límites del navegador
Últimamente he estado lidiando con el asunto del límite de conexiones de los navegadores trabajando bajo HTTP 1.1. En esta versión del protocolo no se permiten, en principio, más de 2 conexiones simultáneas. Ésto es un problema en aplicaciones que precisan sacar el máximo rendimiento de las descargas como puede ser el envío de imágenes, que ya de por sí es información pesada.
Aquí cuentan que un cliente no debería mantener más de 2 conexiones con cualquier servidor o Proxy. Muy bien; eso coménteselo a los de Google y su Google Maps, o a Microsoft y su Maps Live, a ver qué opinan del asunto (ellos lo resuelven como detallo más adelante). Y todo por seguir "el estándar", dicho sea de paso.
Microsoft ya ha tomado medidas con su 'Explorer 8' para aumentar por defecto el número de conexiones simultáneas a 6. El caso es que como siempre, cada navegador irá "a su bola" y al final nos tocará lidiar con estos problemas a los programadores (para ganarnos el sueldo, y tal...). Menuda chusta!
Googleando se puede encontrar cómo resolver este asunto de forma más o menos elegante (sin intervención por parte del usuario) con la inclusión de múltiples dominios que apunten a una misma IP encargada de resolver las peticiones al cliente. Con este "Hack" la verdad es que se consiguen unas velocidades de descarga potentes (siempre dependiendo del ancho de banda). Prueba de ello es el visor que tenemos publicado para GeoMadrid.
En diversos Blogs que he estado leyendo opinan que este tipo de triquiñuelas puede reventar Internet. Yo opino que todo en su justa medida... Los servidores deben estar preparados ofreciendo escalabilidad pues las aplicaciones de hoy demandan grandes volúmenes de información. La Web tiene su talón de Aquiles en el ancho de banda pero eso no debe ser un impedimento para desarrollar aplicaciones que saquen el máximo provecho de los recursos disponibles.
Aquí cuentan que un cliente no debería mantener más de 2 conexiones con cualquier servidor o Proxy. Muy bien; eso coménteselo a los de Google y su Google Maps, o a Microsoft y su Maps Live, a ver qué opinan del asunto (ellos lo resuelven como detallo más adelante). Y todo por seguir "el estándar", dicho sea de paso.
Microsoft ya ha tomado medidas con su 'Explorer 8' para aumentar por defecto el número de conexiones simultáneas a 6. El caso es que como siempre, cada navegador irá "a su bola" y al final nos tocará lidiar con estos problemas a los programadores (para ganarnos el sueldo, y tal...). Menuda chusta!
Googleando se puede encontrar cómo resolver este asunto de forma más o menos elegante (sin intervención por parte del usuario) con la inclusión de múltiples dominios que apunten a una misma IP encargada de resolver las peticiones al cliente. Con este "Hack" la verdad es que se consiguen unas velocidades de descarga potentes (siempre dependiendo del ancho de banda). Prueba de ello es el visor que tenemos publicado para GeoMadrid.
En diversos Blogs que he estado leyendo opinan que este tipo de triquiñuelas puede reventar Internet. Yo opino que todo en su justa medida... Los servidores deben estar preparados ofreciendo escalabilidad pues las aplicaciones de hoy demandan grandes volúmenes de información. La Web tiene su talón de Aquiles en el ancho de banda pero eso no debe ser un impedimento para desarrollar aplicaciones que saquen el máximo provecho de los recursos disponibles.
miércoles, 12 de marzo de 2008
Desarrollador 5 Estrellas
Recientemente he obtenido la 5ª Estrella del curso online de capacitación para tecnologías relacionadas con .NET. Actualmente trabajo con ese Framework, de ahí que decidiera enrolarme principalmente por ampliar conocimientos y obtener material actualizado. Mis impresiones al respecto:
- Lo mejor de todo que es gratuito.
- Es una buena oportunidad de iniciarse en .NET si aún no lo conoces y/o te pica la curiosidad.
- Buen material aunque no me agrada que la parte final sean vídeos y más vídeos. Además, la calidad del sonido es mediocre.
- Conoces tecnologías que aún no trabajando con ellas a diario, te pueden servir para proyectos futuros (p.e. Workflows).
- No es complicado aprobar exámenes, aunque alguno es algo "puñetero".
- Con tanta estrella al final eres capitán general, como poco ;-)
En breve abordaré el Desarrollador Gold y posteriormente, si todo va bien, el Platinum. Aquí como el Lute, camina o revienta...
- Lo mejor de todo que es gratuito.
- Es una buena oportunidad de iniciarse en .NET si aún no lo conoces y/o te pica la curiosidad.
- Buen material aunque no me agrada que la parte final sean vídeos y más vídeos. Además, la calidad del sonido es mediocre.
- Conoces tecnologías que aún no trabajando con ellas a diario, te pueden servir para proyectos futuros (p.e. Workflows).
- No es complicado aprobar exámenes, aunque alguno es algo "puñetero".
- Con tanta estrella al final eres capitán general, como poco ;-)
En breve abordaré el Desarrollador Gold y posteriormente, si todo va bien, el Platinum. Aquí como el Lute, camina o revienta...
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.
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.
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 TimerWebDock.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 IAnimatableWebDock.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.
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:
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:
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.
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í.
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.
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.
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.
Suscribirse a:
Entradas (Atom)
