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

Probando nVidia PerfHUD

music: BLUE ÖYSTER CULT -"See You In Black"-

En estos días he estado probando nVidia PerfHUD (versión 6.62), un programa tipo profiler que puede ayudar a detectar cuellos de botella en el pipeline gráfico. Quiero ver si la caída en el framerate que comenté en la anterior entrada tuviera también algo que ver con un mal uso de Direct3D.

De momento no he tenido mucho éxito. Durante la instalación, se me indica que me van a ser actualizados los drivers de la tarjeta gráfica... el problema es que mi tarjeta está ahora mismo un poco anticuada y no pasa la prueba del logotipo de Windows con esos últimos drivers con lo que el asunto, como puede esperarse, no pinta muy bien. Y así ha sido: el programa se cuelga cada dos por tres, y el ordenador se ha quedado algo inestable hasta que le he vuelto a reinstalar los drivers anteriormente instalados.

Total, que voy a probar con una versión más antigua, a ver si así hay más suerte.

Hasta otra. :P

(** EDIT 31/05/2010 **) Ídem de ídem con la versión 5.2, y ya no se ven versiones más antiguas del entorno. Así que este asunto, al menos por el momento, así se va a quedar... :(

Super Pong y el Modo Debug

music: WENDY O'WILLIAMS singing -"It's My Life"- / KISS -"Rock and Roll Hell"-

De vuelta al trabajo. Ya estoy dándole duro otra vez al Super Pong; de ahora en adelante voy a intentar actualizar más a menudo, como muy tarde cada dos semanas; aunque será como todo, dependerá de los progresos y cómo me cunda el asunto. : )

Durante la semana anterior he estado arreglando algunas cosas y haciendo que la información de los AABBs quede guarde como un centro y unos "radios" o Halfwidths en X,Y y Z; de esta manera, se guarda la mitad de la longitud (y no la longitud entera) en X,Y y Z del AABB, lo que ahorra tener que dividir entre 2 (o multiplicar por 0.5) en un montón de sitios dentro del juego. : )

He estado marcando objetivos y, entre ellos, está el hecho de crear algún tipo de sombra o proyección de la pelota contra las paredes del recinto, para que el jugador pueda hacerse una mejor idea de lo cerca que está la pelota de la raqueta suya. También voy a meterle algo de musica, aunque aún no he logrado crear el efecto cross-fading que me había planteado.

Sin embargo, sigo arrastrando todavía un problema "curioso": la diferencia brutal de rendimiento entre crear un ejecutable en Release y ejecutarlo separadamente del entorno de programación en Modo Pantalla Completa... y ejecutar el juego en Debug, dentro del entorno de programación(sea en Pantalla Completa ó en modo Ventana). Sigue sucediendo lo mismo: en modo Debug el rendimiento SE VA A PIQUE. Tal es la caida que no se puede llevar una partida con normalidad, lo cual hace muy difícil la depuración del código.
No sería tan importante si, estando en Debug, mantuviera un rendimiento aceptable en Pantalla Completa pues el asunto se resolvería mediante dos monitores (como en el trabajo: uno para tener a la vista el código, otro para ver la ejecución del juego). Pero no, es algo que he estado probando este fin de semana y se ralentiza igual.

El cuello de botella parece producirse en los componentes IA_NPC y LogicaPelota, posiblemente por las llamadas al componente Colision3D; es por ello que deseo modificar el sistema de Collision Detection and Response y hacer algo que sea más eficiente (aparte: solucionar los eventuales problemas con el tunnelling).

En fín, iré compaginando esto con las otras cosas que quiero hacer y veamos en qué acaba el asunto en las próximas semanas. Esta imagen lleva congelada demasiado tiempo.

Hasta otra. :P

¿Seguridad en el cálculo ó Fallo en la programación?.

music: MOBY -"Natural Blues"-

Bueno, pues al fín terminé de vér cómo funciona el sistema de Collision Detection. Pero hay algo que no termino de enterarme, y no sé si lo están haciendo por seguridad ó es un bug de la demo. Anoto aquí la duda sobre el asunto, el cual explico resumidamente:

1-Por una parte tenemos 8 vértices, y tenemos que comprobar que alguno de ellos, está ó no dentro de un espacio cuadrado delimitado por cuatro vértices que están dentro de un plano. Para ello vamos a tener un bucle for que lo que va a ir haciendo es coger cada uno de dichos vértices (de entre los 8 a comprobar), hallar la proyección ortogonal de ellos sobre el plano, y comprobar si dicha proyección está ó no dentro del espacio cuadrado del plano. OK

2-En cuanto se demuestra que la proyección ortogonal sobre el plano de uno de estos 8 vértices está, además, dentro del espacio cuadrado, se procede a calcular la distancia existente entre el vértice y su proyección; si es aproximadamente 0, se considera que el vértice mismo está colisionando contra ese plano. Y además, se rompe el bucle for y no se siguen comprobando el resto de los vértices. También OK.

3-Hasta aquí, todo bien. El asunto es que al citado bucle for de los 8 vértices lo engloba un bucle infinito; si se cumple todo lo del paso 2, se incrementará un contador... ¡PERO PERMANECEREMOS DENTRO DEL BUCLE INFINITO!. En la siguiente iteración de dicho bucle infinito NO se pasa a evaluar otro grupo de 8 vértices, sino los mismos; no se cambia de plano (ni de su correspondiente espacio cuadrado, sigue siendo el mismo). Con lo cual volverá a evaluarse y volverá a salir, digo yo, EL MISMO VÉRTICE; se volverá a incrementar el contador, se rompe el bucle for de los 8 vértices, volvemos a entrar en el bucle infinito...

4-...y así, hasta que el valor almacenado contador sea mayor que 20, y ahora sí, salimos del bucle infinito. Momento en que, si bien los 8 vértices van a ser los mismos, se toma un nuevo plano (el cual tendrá su correspondiente espacio cuadrado definido por cuatro vértices que están dentro de él) y se pasa al punto 1.

OK, pero... ahí está la duda: hasta llegar al punto 4 ,hemos realizado el proceso explicado en el punto 3... ¡¡¡20 VECES!!!. Y lo que no llego a ver es si esto algo que se desea realizar de esa manera por alguna razón (quizás por seguridad, para evitar posibles errores de punto flotante, o lo que sea)... o es directamente un fallo en la programación.

Pero bueno, ahí se va a quedar la cosa; ya me enteraré otro año.

Hasta otra. :P

No eran proyecciones, sino ecuaciones de planos...

music: COPTIC RAIN -"Barefoot / Perfect Lie"-

Estos días los he pasado averiguando cómo funcionaba el sistema de C0llision Detection de la famosa demo de los Donuts, algo en lo que me había quedado encasquillado en otra ocasión... pero esta vez he tenido más éxito.

El problema radicaba, principalmente, en el enfoque. Mientras veía el funcionamiento del método encargado de realizar la Colission Detection estaba entendiéndolo como una serie de proyecciones de cada uno de los vértices del Bounding Box del primer objeto (aquel que realiza la Collision Detection con el resto de objetos) sobre las normales de las caras del Bounding Box del "segundo objeto (en cada caso, éste último será el objeto digno del análisis de Collision Detection por parte del primer objeto; cabe destacar que Objeto 1 siempre será distinto de Objeto 2).

Bajo esta perspectiva la explicación "casi funcionaba", pero me fallaba algo: no comprendía cómo con una simple resta del vértice actual del Objeto 1 sobre lo que yo consideraba "la proyección de él mismo" sobre la normal de la cara actual del Objeto 2 hallábamos ya la proyección de dicho vértice actual sobre la cara actual del Objeto 2.

La solución ha venido de la mano del libro "Real-Time Collision Detection", del cual ya puedo decir que ha merecido la pena el dinero invertido aunque sólo sea por esto (no obstante, espero tener más razones aún en el futuro). :P

Como preliminares:

1) Volví a repasar algo el tema de vectores, recordando un elemento clave: un vector representa una magnitud, dirección y sentido... pero NO posee dirección.

2) Volví a ver las ecuaciones del plano, y las propiedades asociadas a dichas ecuaciones.

A partir de aquí, lo ví claro: lo que verdaderamente se estaba haciendo NO era proyectar sobre las normales... sino hallar el punto más cercano de cada vértice del Bounding Box del Objeto 1 a cada una de las caras del Bounding Box del Objeto 2, tratando dichas caras como planos mediante la ecuación del plano:

n · X - d = 0, siendo:

--> · la operación Producto Escalar,
--> n, la normal de la cara actual del Objeto 2,
--> d = n · P, tal que P sea un punto perteneciente a la cara actual del Objeto 2.

Dicho punto más cercano, si prefiere verse así, puede verse directamente como la proyección del
vértice actual del Bounding Box del Objeto 1 sobre la cara actual del Bounding Box del Objeto 2.

Desde aquí:

-Si a dicho punto más cercano lo llamamos R y al vértice actual del Bounding Box del Objeto 1 lo llamamos Q,

-Y si tenemos en cuenta que las normales de los Boundings van a estar normalizadas...

... la cosa queda así: R = Q - [(n · Q) - d]n <-- Esta es la citada resta, ahora sí teniendo sentido, que comentaba más arriba; esto es lo que verdaderamente se hace en la demo.

Y ahora sí: una vez hallado ese punto más cercano a Q, R (o esa proyección de Q, R, si prefieres verlo así), se comprueba que se encuentra dentro de los límites de la cara actual del Bounding Box del Objeto 2; si lo está, se puede decir "con la boca pequeña" que ambos objetos están colisionando; si no, debe proseguirse con el análisis.

Pues ya quedan poquitas cosas de las que quería ver de esta demo. Tengo que ponerme a realizar un recuento de objetivos a realizar para Super Pong.

Por cierto, todo esto me ha dado una idea acerca de algo que tenía ganas de hacerle: poder proyectar puntos, líneas o algo así desde la posición de la pelota hacía las paredes del recinto para que el jugador pueda hacerse una mejor idea sobre la distancia a la que se encuentra la pelota de la raqueta, que dada la cámara a veces no sabes muy bién dónde está.

Hasta otra. :P

Edición Española de RUNAWAY: A Twist of Fate

music: JMM -"My Dear Tula"- / HIS HAIRCUT -"Cultural"-

El pasado 25 de marzo salío a la venta la Edición Española de Runaway: A Twist of Fate, ¡¡¡al fin!!!.

Espero que aquellos que lo jugueis os guste. Los que hemos participado en la creación de este juego hemos dado lo mejor de nosotros para que ello sea así. : )

Por mi parte ya he conseguido ambas ediciones -single y trilogía- y dejo por aquí algunas fotillos que les he hecho, junto con la camiseta de promoción, como hice con la versión alemana; la versión francesa es practicamente igual a la versión single española.

Me gustaría ver las Ediciones Checa y China; la primera, por si tiene un diseño de caja tan... digamos "espectacular"... como en las entregas anteriores de la saga. Y la China... porque tiene que ser el despiporre escuchar a los personajes en chino -no sé si mandarín ó cantonés-. Pero aún no sé nada de dichas versiones.

Y de la edición en habla inglesa... bueno, si nos fiamos de Gamespot parece ser que se pondrá a la venta en mayo. ¡En fín, a esperar un poquito más, jeje...!.

Hasta otra. :P

Se me enfrian los Donuts... :P

music: none

¡Bueno, al fin!. Ya he terminado de ver los artículos de física que estaba viendo. La verdad es que el esfuerzo ha merecido la pena pues gracias a ellos me he enterado de un montón de cosas pero para el lector no familiarizado con la física (o que ya no lo esté, como es mi caso) resultan bastante duros.

En cualquier caso, he repasado/entendido cosas como el Método de Euler, la fórmula de Rotación 3D de Ollinde Rodrigues, las Fuerzas y los Pares de Torsión ("Torques" en ingles), el Momento de Inercia, la descomposición de la velocidad que lleva un rigid body que se traslada y rota alrededor de su Centro de Masas por el Teorema de Chasles... un par de "misterios sin resolver":

-Similarity Transform: Un proceso que permite transformar la orientación de un body en coordenadas de mundo. Se transforman los vectores de la orientación mediante una matriz que es producto de tres matrices:
1)Matriz traspuesta de la "matriz de paso de coornadas locales a coordenadas de mundo" --> Al estar hablando de un sistema ortonormal, la matriz traspuesta será la inversa la matriz anteriormente mencionada, con lo que estamos hablando de la "matriz de paso de coordenadas de mundo a coordenadas locales".
2)Matriz de transformación --> Debido al paso 1) la orientación ya está en coordenadas locales; así que transformamos la orientación en coordenadas locales.
3)Matriz de paso de coordenadas locales a coordenadas de mundo --> la transformación vuelve a pasarse a coordenadas de mundo.

-Matriz Inertia Tensor; algo que ya había visto rondando por algunas demos , y que viene a ser la representación en 3D del Momento de Inercia en 2D.

En fin, digamos que en este momento me siento preparado para entender la parte de simulación física de la demo de los Donuts, y que al comienzo parecía una hardcorada total. Me pondré con el asunto en estos días, pero eso sí... voy a tener que recalentar un poco los Donuts. :P

Hasta otra. :P


P.D. Y mañana sale el Runaway a la venta...

The Black Art Of 3D Game Programming

music: FATBOY SLIM -"Right Here, Right Now"-

Albert Einstein: "No te metas en la cabeza aquello que puedas meterte en el bolsillo".
Anderson_JAG: "Sr. Einstein... ¡¡¡¿ha visto usted el tamaño de este libro?!!!". :P

Ya tocaba hablar de uno de mis libros favoritos, "The Black of 3D Game Programming" de A. LaMothe. Gracias a este libro, el cual llevo estudiando desde hace aproximadamente un año, he podido llegar a enterarme de un montón de cosas de las que, de otra forma, hubiera sido imposible haberme formado una idea acerca de cómo se producían, de su funcionamiento.

A nivel general, he de decir que cuando quiero estudiar o informarme sobre un tema relacionado con programación de videojuegos... donde me gusta mirar es en los libros. Sean mejores, sean peores... no importa. Siempre le daré, al menos, una oportunidad a un libro.

Así que, en estos años de andadura en el mundillo de la programación de videojuegos, me he encontrado principalmente con tres tipos de libros:

TIPO 1: Aquellos que te sueltan el rollo macabeo, te plantan los cuatro pseudocódigos generalistas y/o formulones, y... ¡ahí lo llevas, majo!.

TIPO 2: Ahora nos vamos al otro lado. Libros muy orientados a realizar algo muy concreto, empleando una tecnología muy concreta, pero que se quedan cortos no ya a la hora de profundizar en la materia, sino de explicar la materia misma. Qué se esta haciendo en esta o aquella parte del código, porqué llamar a estas fórmulas de Direct3D, OpenGL o lo que sea, y no a estas otras; porqué llamarlas en este orden. Porqué los parámetros empleados, y no otros. Etc.

TIPO 3: El tipo más minoritario. Hay una explicación más o menos extensa y difícil pero para nada farragosa o intragable; y si aún así, por mucho que te hayas esforzado, no te enteras de nada... no te preocupes: porque inmediatamente detrás va a venir siempre una pequeña demo, lista para ser compilada y ejecutada, con la que vas poder entender qué narices estaba diciendo el autor en este o en este otro lugar realizando un tracing de su funcionamiento.

Es fácil adivinar que enmarco a este libro dentro del Tipo 3. Cuando hablo de demos, no me refiero a una demo de final de capítulo... ¡sino a VARIAS demos dentro de un mismo capítulo!. Con lo cual puedes volver atrás en la teoría y decir: "¡Claro, ahora lo entiendo...!".

Y gracias a ello, he podido llegar a comprender (y más aún, VER) cosas como pintado de líneas, relleno de polígonos mediante scan conversion, shading Flat y Goraud, Z-Buffering y BSP partitioning. De acuerdo, existirán técnicas mejores que las explicadas en este libro para realizar las citadas tareas. De acuerdo, fastidia mucho que haya temas que LaMothe comenta explicitamente que no se van a tratar en el libro; de acuerdo, la demo final del tema de Voxel Graphics dista mucho de ser... como se dice ahora, "resultona". Pero no menos cierto es que si te encuentras atorado, si por alguna razón no logras comprender determinados aspectos relacionados con álgebra, con gráficos 3D, con estructuras de representación de un entorno 3D, o inlcuso con recursividad... te puede venir muy bien. De este libro se puede hablar muy bien ó muy mal. Depende del prisma. Pero dado que a mí me está sirviendo, aunque no sea de una forma directa... seré de los primeros.

CONCLUSIÓN:

Si no te apetece "perder el tiempo con algo viejo y obsoleto" porque estás buscando explicaciones sobre tecnología next-gen, o un manual para hacerte un engine que supere a Unreal Engine... tienes toda la razón, "no pierdas el tiempo".

Si consideras que los engines no son como las hortalizas (que las plantas, y crecen) sino que debe haber una base "soterrada" bajo capas y capas de tecnología de rimbombantes nombres y te apetece conocer un poco qué hay bajo todo ello y formarte una idea al respecto, aunque no pueda ser una idea exacta... este libro te puede interesar.

E insisto: si te encuentras atorado, si por alguna razón las transformaciones 3D, el pipeline gráfico, Direct3D u OpenGL "no te entran", si notas que te falta perspectiva de base... este libro te puede ayudar mucho si le derivas parte de tu tiempo; leete el Cap.1, de ahí salta al 10 y... ¡a trabajar!.

Hasta otra. :P


(** EDIT:  10/16/2013 **)

Thanks for signing me the book, Mr. LaMothe. : )

Retromadrid 2010

music: MOONCHILD -"A Friend / War"-

Pues eso... que el próximo 13 de marzo será la edición de Retromadrid para este año; estrenando, por cierto, nuevo sitio. Espero poder ver caras conocidas de la pasada edición (me sé yo de unos de las Islas que, como como crucen el charco y vengan, van a tener que traerse un buen surtido de caramelos porque servidor vendrá entrenado para el "Attack of the Mutant Fruits from Outerspace", ¡jejejeje...!). ; )

Hasta otra. :P

Physics, Collision Response and Runaway

music: AMERICAN DOG -"Dog Will Hunt"-

Veamos... estas últimas semanas han sido muy productivas a nivel de trabajo. He estado analizando el funcionamiento de la demo de los Domuts, especialmente el sistema de detección de colisiones, y la verdad es que me he enterado de bastantes cosas; pero tocar la parte relacionada con la física y el sistema de collision response aún me he parecido delicado con lo que, a riesgo de perderme sin entender ni papa, me he metido primeramente a ver unos artículos sobre Rigid Body Dynamics escritos por C. Hecker (link al website personal) que me están resultando muy, muy útiles y didácticos. Este señor ha logrado resumir en cuatro artículos... diría que entre 6 y 7 temas de física (Cinemática y Dinámica) de un libro de Bachillerato; y con la ayuda de las demos que acompaña, puedes ver perfectamente donde y cómo se emplea cada elemento, cada fórmula... en definitiva, cómo encaja todo. Hoy he terminado de ver los relacionados con 2D y he empezado a ver el de 3D (¡menos mal que avisa que la mayoría de fórmulas de cinemática ya vistas valen también para 3D, jejejeje...!). ¡¡¡RECOMENDADOS!!!.

Respecto de Runaway: A Twist of Fate... he estado bastante tiempo sin comentar nada porque, aparte de estar muy ocupado con estos y otros asuntos, era un tema que estaba copando toda la atención del blog, y tampoco quería eso. Me hice este blog basicamente como un "Dev Blog", para ir comentando mis progresos en programación, en mis proyectos personales, señalar artículos y cosas interesantes relacionadas con el mundo de la programación de videojuegos que fuera utilizando, recomendar libros del tema, etc. Por eso he dejado al Runaway más de lado, aunque han ido apareciendo noticias importantes sobre él (tan importantes como que será publicado en España el próximo 25 de marzo); podeis echar un vistazo a la página de Runaway: A Twist of Fate en español y también a la nueva página de Pendulo Studios, pero vamos, si habeis estado atentos seguro que todo esto ya lo habeis visto.

Hasta otra. :P

DONUTS IV: REVENGE OF THE SPACE TORUS

music: W.A.S.P. -"The Heretic (The Lost Child)"-

Durante estos días me he puesto a mirar una demo a la que llevaba tiempo queriendo echarle un ojo: "Donuts IV: Revenge of the Space Torus".

Se hallaba entre los samples de DirectX SDK Summer 2003 e, inexplicablemente, fue eliminada en versiones posteriores. Me estoy centrando, sobre todo,en determinar el funcionamiento del Sistema de Collision Detection and Response, el principal elemento de Super Pong que quiero modificar, y que se me atraganta desde hace muuuuucho tiempo. Las explicaciones que he encontrado en Metanet Software , en Gamasutra y en los libros "Real-Time Collision Detection" y "3D Math Primer for Graphics and Game Development" estan muy bien... pero sigo sin saber muy bien qué hacer con todo ello, sin ver cómo encaja todo ello... sin ver "the big picture", vamos.

También he estado entretenido "rescatando" la posibilidad de pintar, estando en Modo Debug, los Bounding Box de los enemigos y los donuts que lanzas como proyectil (digo rescatando porque pareciera que dicha opción hubiera quedado "enterrada" en el código, sin posibilidad de dar una orden de activación de dicha característica desde el exterior). Así que la he dejado que puedas activarla/desativarla pulsando una tecla estando en Modo Debug. Por aquí he dejado un par de capturillas.

Gracias a "The Black Art of 3D Game Programming" de A. LaMothe (un libro al que le debo mucho y del que ya hablaré en una entrada próxima) he podido enterarme sin mucha dificultad de cómo se están calculando las normales de las seis caras de los Bounding. Por otra parte, parece que los únicos vértices del bounding que emplea para comprobar son los ocho de las esquinas (en ese sentido probaré a añadirle los seis puntos céntricos de cada cara, para refinar las comprobaciones).

Lo dicho, espero poder enterarme de más cosas y poder algún día resolver el problema de las colisiones y el "tunnelling" de Super Pong (mención aparte, el framerate en el portátil se me va a pique). :P

Me marcho otro rato a la Biblioteca, que es temporada de estudiantes y también abre los domingos.

Hasta otra. :P

¿ PC --> iPhone --> Mac ?. ¿Es esta la jugada?.

music: MANO NEGRA -"Rock'N' Roll Band"-

Desde que me he enterado que Rage está siendo programado también para Mac llevo dándole vueltas a la cabeza a algo...

Me sorprendió muchísimo ver, en CDV 2009, cómo la gente se había tirado de cabeza al iPhone. Personalmente hay algo que no consigo ver ni a la de tres: decir "el iPhone por el iPhone". Así, porque sí, porque "aquí está el negocio y esto es la panacea con la que poder vivir"... y simplemente, no lo veo. Máxime con todos esos terminales dotados con Android revoloteando alrededor del cacharrito de Apple.Y tras haber visto el anuncio de Rage para Mac sólo se me ocurre una cosa para que esto cuadre...

Partiendo de la base de una hipotética sustitución del PC única y exclusivamente por otro ordenador (porque eso es lo único que sustituirá al PC; y lejos de querer avivar debates estériles, ninguna videoconsola podrá jamás erradicar "al ordenador" -actualmente: PC- como plataforma de videojuegos)...

...y partiendo del hecho indiscutible de los Mac como elelementos que ya han comenzado a salir del Olimpo de Apple para caminar entre nosotros, los pobres mortales......¿es que acaso veremos, dentro de unos cuantos años, el declive REAL del PC -el de verdad, no el falso que intentan colarnos con mayor o menor éxito- en favor de los Mac, el ordenador que quizás se consolide en el futuro y, sea, por lo tanto la "plataforma ordenador" para la que programar videojuegos?.

Y de ser así... ¿es esa la razón por la que tantos y tantos se han tirado "from lost to the river" al iPhone, como un buen paso previo para cuando el Mac se ponga ya por delante y la demanda de videojuegos para él crezca?.¿Acaso es esta la jugada?. Porque "el iPhone por el iPhone"... como diría alguien que conozco, que se llama Brian Basco: "No lo veo claro".

Hasta otra. :P