ADMINBLOG PROYECTOSDESCARGASNORMASACERCA DE
Blog de Miguel Herrero
Entro al trapo: Java vs Mono

Este ‘debate’ no se refiere tanto a los lenguajes (que son distintos, pero igualmente válidos) como a sus respectivos frameworks y máquinas virtuales. Yo sigo los blogs tanto del desarrollador de Irrlicht como el de Ogre. Y curiosamente, sus filosofías en dichas librerías también se extienden a sus gustos personales.

A Niko, al igual que con Irrlicht, le gusta programar en C++ a bajo nivel. No en vano, prefiero recomendar Irrlicht como librería para aprender, porque es como una capa por encima de las APIs gráficas, y le falta mucha funcionalidad. Pero es muy sencillita y abstrae lo suficiente sin marear, ideal para aprender.

En el polo opuesto, Steve prefiere abstracciones que permitan resolver problemas de forma general que, aunque suelan enmascarar lo que hay por debajo, lo ponen realmente fácil para añadir nueva funcionalidad. Por ello, opino que Ogre es la mejor opción para crear un juego sin aprender ni torta de gráficos. Sin embargo, hay que acostumbrarse al motor, lo que lleva un tiempo.

Recientemente han publicado varios posts en los que ambos autores hablan de Java o C#. A fin de cuentas, son lenguajes muy diferentes: Java es más sencillo (a pesar de los Generics y demás azucar sintáctico) y C# tiene más acceso a bajo nivel y control del compilador (por ejemplo, con sentencias de pre-compilador).

Yo estoy desarrollando mi PFC en Java. No engaño a nadie: si tuviera que elegir, saldría ganando Java porque es mi opinión al fin y al cabo. Pero dependiendo de la situación me decantaría por uno o por otro.

Java me parece más portable ahora mismo. Mono está en desarrollo, y no es algo “oficial” por mucho que Microsoft lo “apoye” a través de Novell. A Microsoft le interesa que Mono ayude a lavar su imagen. Ahora bien, centrándonos en el desarrollo de juegos ¿es posible usar Mono?. Tanto Java como Mono van a ser más lentos que C++ si TODO está programado en ellos.

Pero en la mayoría de los casos, lo que se hace es utilizar wrappers que llaman a código C++. En mi caso, apenas utilizo librerías de Java más allá de las colecciones (tablas has, listas y demás) y algo la parte de carga de imágenes para no depender de librerías externas a la hora de cargar texturas.

Por eso no es necesario que Mono haga todo lo que hace la máquina virtual de Microsoft. Solo es necesario librerías básicas y poder usar esos wrappers. En mi caso, también siento cierto apego por Java como lenguaje en sí, y por los entornos de desarrollo. Mono no tiene un Visual Studio para plataformas no-Windows. Sin embargo, tanto Netbeans como Eclipse son unos estupendos IDEs multiplataforma.

Respecto a Java, me gusta lo sencillo que es. Para mí, los generics han limpiado un poco el código y no han ‘pervertido’ el lenguaje (al menos, no tanto como Ortín suele decir). Cuando empecé a portar ciertas partes del SDE a Java, había momentos en los que costaba leer el código. Nada grave pero, por ejemplo, a veces tenía que buscar si un objeto.Param = 1 era un acceso a un parámetro ‘a pelo’ o usaba propiedades, que no es más que una forma de enmascarar los clásicos get y set de Java.

Ahora parece que a Miguel de Icaza le está yendo bien con Mono como plataforma de script para juegos. Y está claro que es una opción perfectamente válida. Yo no pido que se descarte a Mono de la ecuación, sino que se tenga en cuenta a Java que, muchas veces se le supone hasta menos eficiente que Python, por alguna razón. Quizás los applets le hayan dado esa fama a Java, pero en mi opinión, muchos de esos comentarios son “por seguir la corriente”. Es un cliché como puede ser meterse con Microsoft.

Y una vez más, termino una comparativa sin un claro ganador. He usado ambos lenguajes y ambos son muy cómodos. Sin embargo, prefiero inclinarme a pensar que la burbuja de Java todavía no ha estallado. Un lugar para cada cosa, y cada cosa en su lugar.

 
Cuando el río suena

Hace cosa de un mes, la grabadora de mi portátil (que es mi ordenador principal, para el que no lo sepa) dejó de leer PRINCOs en blanco, no los detectaba, así que no podía grabar en ellos. En el ordenador de mi padre funcionaban perfectamente. Sin embargo sí podía leerlos si ya estaban grabados.

Empecé a usar Verbatim, y aguanté un tiempo, pero cada vez grababa más despacio, y los últimos DVDs que grabé, se tostaban a 2x más o menos. Hasta que ayer intenté grabar uno (porque no ando muy sobrado de espacio ahora mismo) y nada más empezar dio un error de escritura. Saqué el DVD y metí otro, y ya no lo reconocía.

Siguiendo el consejo de Knudow, probé a meter algunos DVDs ya grabados a ver si los leía, y ha habido suerte, aunque recuerdo que algunos de los que tenía en casa con juegos no me los pillaba. La cosa es que no grabo muchos discos, y menos últimamente, que apenas hay juegos que me vayan bien.

Y el portátil no me ha dado problemas de momento, desde que me cascó el disco duro (según el servicio técnico, una “tirada defectuosa”). Ahora mismo, solo veo dos opciones: comprar una grabadora externa, o comprar un disco duro externo.

La respuesta sería sencilla si el DVD no leyese, pero como lo hace, para un apaño sirve. Se supone que un compañero mío compró una grabadora por unos 40€ en MediaMarkt o similares. Sin embargo, un disco duro decente cuesta como mínimo 80€ (de 160Gb). Teniendo en cuenta que lo usaría para almacenar a saco, y no para llevarlo por ahí, por 10€ más, tengo uno un pelín más grande de 500Gb.

Aquí es donde me entran las dudas: la grabadora externa es lo más barato, y todo seguiría como hasta ahora más o menos. El disco duro es más caro, y tampoco sé si debería meter TODO en un disco duro. Al fin y al cabo, cuando casca un DVD, solo se fastidia uno y no la tarrina de 25. Y aquí estamos hablando de que casquen 5 tarrinas de 25. Y ¿quién sabe cuanto durará un disco duro? yo sigo usando CDs de cuando empecé la carrera, e incluso antes.

Por otro lado, solo de pensar en 500Gb empiezo a salivar como el perro de Paulov. Aunque quizás sea mear un poco fuera del tiesto y con la grabadora sea más que suficiente. ¿Alguien puede darme algún consejo? o, siendo un poco más puñetero ¿qué haríais vosotros?

 
Fuentes de textura

Ayer me propuse renderizar las fuentes de textura que generaba con mi generador. Pero, por desgracia, me topé con un error muy feo en el parser de xml que me tuvo toda la tarde. Cada vez que parcheaba un lado, aparecía otro error en otra parte. Estuve un buen rato así, hasta que me dí cuenta que un fontanero en el titanic tenía más posibilidades.

Acabé reescribiendo el parser (que me llevó menos tiempo que el que pasé depurando, todo sea dicho) y por fin pude cargar los ficheros de descripción de las fuentes. Sin embargo, ya era demasiado tarde como para seguir programando (y hoy tenía clase por la mañana) pero, al menos, conseguí ver algo por pantalla, aunque fuera un amasijo de polígonos.

Hoy por la tarde, mientras esperaba a que un compañero saliera de prácticas, eché una hora a depurar un poco el estropicio. Índices mal calculados, errores en los bucles for y demás. Incluso aprendí que las fuentes tienen dos alturas: la altura del caracter en sí, y la altura hasta la linea base (esa línea imaginaria que mantiene todas las letras a la misma altura y que yo tan alegremente me suelo pasar por el forro). Hasta que por fin me topé con esto:

¡Por fín! Y además de alegrarme por dibujar la fuente en sí, fue mi primer acercamiento a cómo modificar la geometría de un VBO, cosa que necesitaré para hacer sprites animados y partículas. Ahora debería mejorar la gestión de objetos en la escena, pues ni siquiera los ordeno por transparencia todavía. Pero al menos es otro pasito más hacia adelante.

Con el tiempo, me gustaría añadir bastante funcionalidad a este texto (de momento, solo se puede alinear). Sería interesante poder justificar el texto, y hacer que sea fácil el típico efecto de aparición del texto letra a letra, usado hasta la saciedad en muchos juegos. En fin, queda mucho por delante, pero poco a poco los resultados son cada vez más visibles.

 
Flexo

Pues hala, tras tirarme todo el día de ayer buscando un nombre que no estuviera cogido (literalmente, TODO el día) al final me lié la manta a la cabeza y cogí Flexo. Es sonoro, suena igual de bien en inglés que en español y además muestra que soy un fan de Futurama.

Me registré en Google Code, que no está mal, aunque es más sencillo que SourceForge, pero puede que sea mejor así. Tiene un Wiki al que ya le he añadido un par de páginas y he incluido algunas capturas de pantalla, aunque no muestran ni la mitad de lo que hay hecho (pero claro, lo no-visual no sale en las fotos). Y luego el típico tracker de errores, que ya he empezado a usar.

También he subido el código al SVN que te dan ellos, y así guardo una copia de seguridad y al que quiera probar la versión “en desarrollo” pues ahí la tiene. De hecho, si os bajáis la carpeta ‘dist’ y hacéis doble clic en flexo.jar, podréis ejecutar los ejemplos (solo en Windows, para Linux ya postearé las instrucciones en el Wiki más adelante). Nada espectacular de momento, me temo.

Lo más nuevo y que no he posteado todavía aquí es un generador de fuentes de textura. Sé que hay muchos por ahí, pero me hacía ilusión hacer el mío propio y así despejaba un poco de programar el motor en sí. Lo he terminado en cosa de un día, así que ha sido tarea sencilla. Lo malo es que, de momento, no tengo manera de utilizarlo en el motor, así que esa será mi próxima tarea.

Pues eso, que ya podéis entrar a la web, en flexo.googlecode.com.

 
Refactorizando

Llevo un par de días programando el PFC. La cosa avanza lenta ahora mismo porque ando en un punto peliagudo. No es que se trate de programación complicada o que haya un fallo que no consigo encontrar. El principal problema es que noto que el diseño se me escapa de las manos, y en estos momentos prefiero ir despacito y pensar las cosas un poco.

Por un lado, me gusta tener todo ordenadito con sus gets y sets, pero cuando hay tantos sitios en los que los necesito, me da algo de pereza hacerlos. Además, en muchos casos, son internos, para otras partes de la librería. El problema es que necesito acceder desde muchos sitios a determinados recursos.

Esto me suele pasar con clases ‘contenedor’ como ArrayList o HashMap. La primera vez, simplemente las declaré en una clase que pudiera ser accedida por las demás y lo dejé con el modificador ‘package’ (es decir, sin poner nada) para poder acceder desde el resto de clases del paquete. Sin embargo esto es algo chapucero y es una situación que empieza a repetirse en otros lugares.

Esto no es algo especialmente importante, pero tengo que corregirlo ahora o nunca. También se dan otras situaciones curiosas. Como el hecho de que en Java no hay destructores como tal. Hasta ahora, me las he apañado incluyendo métodos remove en las clases necesarias. Sin embargo ¿cómo hacer saber al usuario QUÉ clases son las que tiene que liberar?. Haciendo algo de memoria, yo diría que todas las clases que el usuario ‘pide’ al motor, necesitan destrucción aunque no estoy seguro.

También estoy empezando a meter mano a una de las peculiaridades de mi motor: que todos los módulos comparten un árbol de escena común. Esto es algo experimental, así que no se qué tal resultará, y no es algo que haya visto en otros motores y pueda tener de referencia.

Y por último, y no menos importante, sigo dándole vueltas al tema del nombre. Nombrar un proyecto es algo muy complicado, porque es una primera impresión. Y hay que intentar que la gente lo recuerde, por lo que no puede ser muy rebuscado, pero tampoco demasiado común. También me gustaría intentar que sonara igual en inglés y español.

De momento se me han ocurrido

JAGE (Just another game engine)
Kuma Game Engine
Oporto Game Engine

Oporto también me suena bien. No es que tenga ningún significado en concreto, pero tiene buen sonido y creo que es fácil de recordar. Arg, qué difícil es ponerle nombre a una cosa de estas. Si fuera un perro, le cascas Tobi o Rufo y ya está.