De Cuaterniones y Cuaterniones Duales

music: MOONSPELL -"The Butterfly FX"-

Aquí podemos ver las bondades de Cuaterniones y Cuaterniones Duales en técnicas avanzadas como Skinning.

Hasta otra. :P

Punto y aparte

music: COPTIC RAIN playing "Painted Bird [DB Mix]"-

No, no ha abandonado aún este mundo, ni me habían secuestrado. Desde mediados de enero he entrado a formar parte del Grupo de Programación Kinesis, y me he centrado de lleno en el proyecto que se está llevando a cabo, Quimera Engine.

Con lo cual Super Pong ha quedado parado de nuevo. Insisto en que no es un punto y final, sino un punto y aparte. Al estar inmiscuído en Quimera estoy necesariamente dándome de bruces con conceptos que había tratado de abordar en el pasado, sin demasiado éxito alno tener una motivación que superar. Por ejemplo, Cuaterniones y su utilización como un método alternativo a matrices y para efectuar rotaciones en 3D. Cosas que ahora comienzo, al fin, a comprender. Eso sí, los Cuaterniones han traído consigo a los Cuaterniones Duales y ha sido como "¡Venga, va...!". XD

Aunque no haga mucho ruido... por aquí sigo.

Hasta otra. :P

Un poco de todo

music: THE GONE JACKALS -"Legacy"- / -"Trapped"-

Sin novedad en el frente, o mejor... con multitud de pequeñas novedades. Tras el prototipo de dos pantallas he hecho un poco de aquí y otro de allá, centrándome en aumentar el rendimiento general del juego. Al fin puede decirse que funciona a un rendimiento aceptable tanto en Modo Ventana como en Fullscreen.

Por cierto, Las opciones de Menú ya pueden ser seleccionadas, por cierto, a través del ratón. En un futuro incorporaré la posibilidad de manejar el juego a través de un pad (como se indica en el Documento de Especificación de Requisitos). ; )

A la "espera" de estudiar más la sintáctica de UML y ver alguna herramienta de modelado como Rational Rose o eDraw UML Diagram he decidido aparcar por un tiempo el tema de Patrones de Diseño, algo con lo que me interesa mucho ponerme, y centrarme en algo que también es crucial: la incorporación al engine de un Grafo de Escena.

También he estado estudiando algunos capítulos del libro Video Game Optimization pero aún es pronto para hacer una valoración. He varios libros que me llaman la atención pero, por el momento, vamos a aguantar la tentación...

Hasta otra. :P

Con dos... monitores. :P

music: FIVE HORSE JOHNSON -"Ten Cent Dynamite"-

Es la 01:00 a.m. y en este momento la inspiración para escribir se ha ido ya a la cama, cosa que debería hacer yo también. He logrado terminar el prototipo en el que estaba trabajando en estos días para probar el funcionamiento del juego con dos monitores.

Básicamente lo he realizado así:

• Se crean dos ventanas que se mostrarán En Modo Ventana (no fullscreen como hasta ahora) y MAXIMIZADAS, consiguiendo así que los elementos 2D queden automáticamente escalados al tamaño adecuado y posicionados en el lugar correcto.
  

• Se captura la resolución del Escritorio (del primer monitor) y, dado que al final se especifica a las ventanas que se maximicen, se logra así tener una resolución independiente en cada monitor.
  

• Sólo se crea un único Render Device (no hay replicación de vertex buffers ni doble carga de recursos).
  

• Existirán dos Swap Chains. La primera es creada automáticamente al crear el Render Device, y la segunda se crea mediante el método GetAdditionalSwapChain del Render Device. A cada una de ellas se le especificará un Render Target distinto.

• Se ha creado una cámara adicional que sigue a la raqueta controlada por el ordenador, y cuya escena es mandada a pintar a la segunda Swap Chain.
  

• Hay dos pasadas de Render, una para cada Adaptador.

Como prototipo que es no he prestado mucha atención a la calidad de la implementación y ciertos detalles son realmente mejorables. En especial me preocupa el hecho de abandonar el modo fullscreen y el hecho de llamar a los métodos BeginScene / EndScene dos veces, pues es un hecho que va bastante lento. Si a alguien se le ocurre o sabe una forma mejor de hacerlo que lo comente por aquí, soy todo ojos. ; )

Hasta otra. :P

GAMEFEST 2010

music: COMBICHRIST mixing -"100%"-

El Documento de Especificación de Requisitos del Pong "sigue su cauce normal", así que cambio un rato de tema: hablemos de Gamefest 2010.

La verdad es que ha sido todo un éxito en lo que a asistencia de público se refiere y, al contrario que el supuestamente fallido S2e de 2003, este seguro que repite el año que viene.

Se respiraba en el ambiente un aire de profesionalidad, y mucho jolgorio; principalmente, yo me encontré a caballo entre el stand que Gamelab había instalado, asistiendo a las ponencias, y el montado por RetroMadrid. Por cierto... ¡al fin le eché mano a la recreativa Space Invaders de la gente de AUMAP!.

Y por el camino: volver a encontrarme con gente del sector del videojuego, y conocer alguna que otra persona nueva.

También pude ver (aunque no probar) la versión de Sniper Elite que han hecho para Wii, rifle de francotirador incluído.

Preguntas y respuestas rápidas:

¿Espectacularidad?. A raudales.

¿Novedades?. Aunque escuché algunos comentarios referentes a la escasez de novedades en el evento, no me pareció así; incluso ví cosas que no me esperaba ver, como la segunda parte de The Conduit y Dead Space.

¿Escena clásica?. Me equivocaba de todas, todas, creyendo que poco debía faltar ya por ver, y la exposición del stand de RetroMadrid me mostró de bruces dicha realidad.

Asimismo, espero que puedan verse el año que viene, en el stand de RetroWorks, los remakes de La Abadía del Crimen y Livingstone Supongo.

¿Kinect/Move?. Anécdotas curiosas, pero no sé si tendrán cabida en la clase de videojuegos que me interesan; supongo que tendré que echarle más imaginación al asunto...

¿S. Balmer?. No lo ví, no procede. :P

¿El Gamelab stand?. Bien, aunque sería deseable que en la siguiente edición de Gamefest pudiera situarse en un lugar más alejado, o poner mamparas aislantes de ruido, o algo por el estilo... pues el barullo del resto del evento dificultaba mucho la actividad del stand; aparte de la dificultad para seguir con atención las ponencias los micros se acoplaban mucho. Mención especial a la ponencia de motores gráficos del domingo, pero aquellos que teníamos interés en ella... ¡¡¡queríamos MÁÁÁÁÁÁÁÁÁÁS!!!.

¿Castlevania: Lords of Shadow?. Bien, muy chulo; si no le ponen una protección más estúpida de lo normal cuando salga en PC (como sucedió, por ejemplo, con la versión PC de Assasin's Creed II) seguro que me lo compro.

¿Freaks disfrazados?. Los justos y necesarios para darle la vida y el color necesarios que un evento así necesita, sin que se vuelva una parodia carnavalesca.

Y como colofón final, tras una divertida historia... ¡¡¡Runaway en pantalla grande!!!.

Hasta otra. :P

Análisis y Diseño Orientado a Objetos con Aplicaciones

music: NINA HAGEN -"New York, New York"- / -"Wir Leben Immer... Noch"-

Otra de las cosas que he estado haciendo en estas últimas semanas ha sido repasar la teoría relacionada con el Modelo de Objetos, Análisis y Diseño Orientado a Objetos (desde ahora, AOO y DOO) y, en general, con Ingeniería del Software. Para ello me ha venido muy bien uno de los pesos pesados de dicha materia: el libro "Análisis y Diseño Orientado a Objetos con Aplicaciones", de G.Booch (ficha en Wikipedia); libro que he devorado con avidez e intensidad durante este tiempo.

Está dividido en tres partes:

• Una primera, que describe las características inherentes del Modelo de Objetos (Clases, Objetos, características -Abstracción, Encapsulamiento, Modularidad, Herencia....-, tipos de relaciones entre clases /colaboraciones entre objetos, Parametrización de clases, Polimorfismo, etc.)

• Una segunda parte en la que se explica una metodología de desarrollo Orientada a Objetos (desde ahora, OO) y la notación correspondiente para aplicarla. Destacar, en cualquier caso, la insistencia que se hace durante todo el libro de no ser el desarrollo de sistemas complejos algo que se pueda realizar mediante una perfecta guía o fórmula de recetario.
  

• Una última parte en la que se estudian ejemplos de varios tipos de Sistemas OO, de diversos tipos, empleando la metodología adaptada para cada ejemplo. En esta parte ha resultado muy útil la creación de un pequeño guión /resumen para cada sistema, en el que se vayan enumerando en el orden en que aparecen cosas como tipos de diagramas que se emplean (según la fase de desarrollo), nuevas clases que van surgiendo, y nuevos métodos que se añaden a las clases.
  

Respecto a la implementación de dichos sistemas el lenguaje empleado es C++, pero no se olvida de otros lenguajes Basados en Objetos y OO como Smalltalk, Ada y CLOS, que son citados a menudo y se comparan sus características. De hecho, en el Apéndice se puede ver un resumen con una fichas de las características principales de los lenguajes citados y de alguno más.

Sin embargo, he encontrado en este libro un punto bastante negativo: la expresión, el lenguaje empleado al escribirlo. Demasiado rimbombante, demasiado sonoro. Como queriendo tapar algún tipo de hueco o carencia, o pretendiendo hacer más "grande" algo que es en realidad mucho más pequeño y sencillo. En mi caso, la alarma ha sonado varias veces cuando, tras haber visto un par de veces un determinado concepto X (me ha sucedido con varios) y quedarte literalmente igual, se llega a un tercer punto del libro en el que el autor comenta algo del tipo "...X, cuya explicación ya la habíamos realizado en el capítulo tal...". Ahí te paras y dices: "¡Eh, para el carro!. ¡¿Que dices que esto ya lo has explicado, en este otro capítulo?!. Pues yo me quedé igual...". He sentido en esos casos que no se empleara un lenguaje más llano, más directo, para expresar ciertas cosas.

Es en momentos como ese cuando he echado mano de "Software Engineering for Game Developers", de J. P. Flynt, un libro que sí emplea un lenguaje así, para comprender qué había querido decir Booch entre tanta frase etérea y floritura narrativa.

En resumen: un libro que, aunque engorroso de manejar en ciertos momentos, contiene una descripción muy completa sobre el Modelo OO, alguna que otra explicación muy interesante acerca del funcionamiento interno de C++, y varios ejemplos de los que se pueden sacar ideas y/o aplicar diseños adaptados a nuestras necesidades. Si además tienes a mano un libro de ayuda del que puedas tirar cuando notes que "suena la alarma"... recomendado. : )

Hasta otra. :P

Objetos Producer-per-Platform

music: THE PRETTY RECKLESS -"Make Me Wanna Die"-

Durante todo este tiempo que he estado sin actualizar he estado realizando unos cambios a nivel de estructura interna del engine e incoporádole algunas cosillas. Una de ellas es la inclusión de una nueva clase de la que heredarán sucesivas clases hijas con las que se crearán un nuevo tipo de objetos: los Producer-per-Platform.

Un Producer-per-Platform es un objeto servidor, encargado de crear y entregar al objeto cliente objetos dependientes de plataforma. Entiéndase por plataforma una parte del sistema o el engine, normalmente situada en lo que llamaríamos "bajo nivel", que puede variar según nuestras preferencias o disponibilidad (S.O., Bibliotecas de creación de ventanas, de audio, gráficas, etc.). Según la clase a la que pertenezca el objeto Producer-per-Platform, éste creará unos u otros objetos "Product" (ventanas, render devices, audio devices, etc.). Y la clase concreta del Product que creará se decidirá, por directivas de preprocesador, en tiempo de compilación.

Debe aclararse, por tanto, que los objetos Producer-per-Platform (desde ahora, Producer) no son los dependientes de plataforma, sino los objetos product que crearán (desde ahora, Product).

La relación entre el Producer y el objeto cliente (desde ahora, Cliente) será de USO, y normalmente adoptará la siguiente forma:

0) El Cliente poseerá, como atributo privado, un puntero polimórfico de la clase de Product que el Producer debe crear.

1) La generación del Product se producirá dentro de un método del Cliente; en la implementación de dicho método el cliente poseerá, como objeto estático local, el Producer necesario.

2) El producer creará el product dependiendo de la directiva de precompilador actualmente establecida para ese Product (estará establecida en la propia implementación del Producer) y entregará el Product en el puntero polimórfico del cliente como valor de retorno.

3) La implementación del método finalizará, y el Producer quedará destruído. El Cliente tiene comunicación directa con el Product a través del interfaz de éste último.

4) La responsabilidad de ordenar la inicialización del estado del Product recae en el Cliente; éste será quien llamará al método Init del Product.

5) Asimismo, la responsabilidad de finalizar la vida del Product recae también en el cliente; éste será el encargado de destruir el Product, liberando la memoria que ocupaba.

Como puede intuirse un Producer NO ES UN MANAGER; es un concepto mucho más sencillo que el de un objeto Manager que carga recursos en memoria, lleva la cuenta de la cantidad de instancias (referencias) de recurso que hay empleadas en el sistema y, cuando el número de referencias de un determinado recurso llega a 0, elimina realmente dicho recurso de la memoria.

a) El Producer surge de la necesidad de crear objetos (Product) dependientes de plataforma. SOLAMENTE en este contexto tiene sentido el Producer. De saber a ciencia cierta que va a emplearse únicamente una plataforma el Cliente generaría el Product de forma directa, sin Producer.

b) Gracias a los Producer tendremos un mayor control sobre el engine sabiendo dónde hay establecidas directivas de preprocesador que determinan compilación para una u otra plataforma: en los módulos del los Producer.

He creado ya un Producer de ventanas que devuelve al Cliente (que en este caso es el Objeto Aplicación) una ventana creada mediante la biblioteca Win32. Ahora podría crearse una clase ventana creada mediante, por ejemplo, la biblioteca GLUT y el mismo Producer de ventanas creará y devolverá a la Aplicación una ventana creada mediante GLUT con sólo cambiar la directiva de precompilación en el Producer de ventanas (de crear ventanas Win32 a crear ventanas GLUT).

El siguiente paso en el que emplear esta técnica es en el render device. A ello voy.

Hasta otra. :P