domingo, 1 de enero de 2017

Super PepeToni -making off- 3 Sprites

Programar para la GameBoy tiene sus pros y sus contras.

Como pros hay que destacar que al contar con tan poca resolución de pantalla (160x140 píxieles) y tener un tamaño de sprites tan pequeño (8x8 o 8x16 píxeles) es viable encargarse de la parte de programación y gráficos a la vez, sin que esto segundo suponga una carga excesiva de trabajo. Vamos que con relativamente poco tiempo se pueden dibujar algunas cosas chulis.

Como contras está todo lo demás.

Pero en esta entrada no voy a hablar sobre las grandes carencias de este hardware sino sobre los sprites, o mas concretamente, las limitaciones y particularidades que atañen a estos.

Pero primero de todo ¿Que es un sprite? O mas bien ¿Que diferencia existe entre una imagen "normal" o un sprite?

Una imagen normal no es mas que un vector (Estructura de datos ordenada e indexada) que contiene tanto los metadatos de la imagen (Tamaño, peso, colores y etc) así como la información relativa a cada uno de sus píxeles. De esta manera, cuando mas gran grande es una imagen mas grande será este vector. Esta estructura se puede contemplar con facilidad en el formato de imagen bitmap . 



Cuando se usan imágenes/bitmaps, cada "entidad" corresponde a una 
imagen o parte de ella.  
Fijaos que cada frame ocupa el tamaño que necesita libremente.
Esto es lo que se usa actualmente en la programación moderna. 




En cambio un sprite es una estructura de datos que apunta a una imagen con una serie de "condiciones". Por ejemplo, debe de estar compuesta por un numero de píxeles definido, o solamente puede incluir una cantidad de colores determinada. 
Todas estas reglas se establecen porque, a diferencia de un bitmap, hay una parte del hardware denominada memoria de vídeo que se dedica exclusivamente a procesar estos sprites, liberando al procesador principal de esta ardua tarea. 

Un sprite ocupa lo mismo que cualquier otro sprite porque sólo es información de coordenadas en la pantalla mas un dato que indica a que imagen referencia. Esta imagen que es la que tiene que cumplir con esa serie de "requisitos" y se le denomina tile.

Representación de la memoria de vídeo de la GameBoy corriendo Super PepeToni. 
Fijaros que, a diferencia de la imagen anterior, todas las celdas miden exactamente lo mismo. 
Para formar un sprite grande, se deben ir seleccionando aquellas imágenes/tiles que corresponden.



La conclusión es que una imagen de tipo bitmap es mas detallada que un sprite porque existe "libertad" a la hora de construirla, pero también es mas lenta de procesar.

GameBoy usa sprites y por lo tanto hay una parte de su "circuiteria" que está dedicada al procesamiento de estos. Como el uso de sprites va fuertemente ligado a los videojuegos,  antiguamente, los sprites eran algo casi exclusivo de las consolas y es por esto que una GameBoy, con un un procesador algo inferior al del ZX Spectrum, por ejemplo, lograba juegos con personajes mas rápidos. El truco estaba en el uso de los sprites.


Limitaciones.

La principal limitación de la GameBoy para usar sprites es que sólo puede usar un máximo de 40. Aunque 40 sprites parezca un número mas o menos alto, en realidad no lo es. Como he explicado antes, un tile de la GameBoy puede medir 8x8 o 8x16 píxeles, y este es un tamaño muy pequeño.

El resultado final de toda esta fiesta es que para hacer un personaje de un tamaño considerable se necesitan usar varios sprites. En el caso de Super PepeToni son 10. Vamos, que el solito ya consume 10 de los 40 disponibles. O expresado de otro modo: El personaje principal, sin ser exageradamente grande, se come el 25% del total de los sprites...





Al añadir los enemigos he llegado al tope de los sprites que puedo usar: El personaje principal  mas tres enemigos distintos (He tenido que elegirlos muy bien) Si que es cierto que en realidad se puede representar como el personaje principal mas 6 enemigos, ya que por cada enemigo "guardo" un sprite extra para poder pintarlo 2 veces simultaneas. Osea puedo mostrar los 3 enemigos por 2 veces cada uno de ellos. Y todo eso a la vez. guau.

Guardaré un minuto de silencio por todas aquellas eminencias que, por
motivos técnicos, han quedado fuera :(


En realidad, se pueden crear mas tipos de enemigos "reciclando" sprites que para ser usados en varios personajes. Es decir, puedo reservar un grupo sprites para pintar enemigos del tipo 1 y tipo 2, siempre y cuando no los pinte a la vez.

Esto ultimo ya entra dentro de las clásicas triquiñuelas que se usaban para exprimir el hardaware al máximo, una tarea que resulta ardua pero que ofrece una compensación muy gratificante.

Y bueno, de momento eso es todo por hoy. Nos vemos en la siguiente entrada.


miércoles, 21 de diciembre de 2016

Super PepeToni -making off- 2 ¡Combate!

Tras optimizar todo lo que he podido me alegra anunciar que ya he implementado los enemigos, tanto su diseño como su comportamiento.

He de reconocer que hasta ahora nunca había dibujado nada en rollo pixel art, (Además que hacía años que no dibujaba) y en este proyecto, menos la música, me encargo de realizar todo desde cero.
No va quedando mal pero tengo muchas ganas de verlo corriendo en mi Game Boy ladrillo genuina made in Japan del '90.

Y bueno esto es lo que hay...


martes, 13 de diciembre de 2016

Super PepeToni -making off- 1

En esta serie de entradas narraré aquellos aspectos mas interesantes bajo, mi punto de vista, de los retos técnicos que me supone desarrollar un juego completo para GameBoy

Intentaré apartarme de los tecnicismos de programación y usar un lenguaje mas sencillo para que todo el mundo, incluso la vecina de los rulos o mi bisabuela, me pudieran entender.

Y para comprender mi punto de vista es necesario explicar, a groso modo, parte de mi trayectoria como programador.

Yo me inicie como desarrollador de software con el lenguaje de programación Java. Acumulo algo mas de cinco años de experiencia con esta tecnología y actualmente sigo usándola de manera profesional. Con todo esto, puedo considerar que mi nivel de conocimientos en JAVA es relativamente alto. Toma ya.

A lo largo de mi recorrido académico y profesional he aprendido y trabajado con otros lenguajes de programación entre los que destaco C#, Javascript, SQL y C.

Hasta ahora he desarrollado proyectos para muchas plataformas, tanto móviles como de escritorio, y también WEB. Windows, Android, HTML5,  Blackberry y ñañaña...pero es en Android donde he pasado la mayor parte del tiempo trabajando y explotando este entorno. Para Android he desarrollado juegos y apps tanto de forma nativa como también usando frameworks del tipo Unity3D.  He de reconocerlo, Android me gusta, me resulta cómodo, ya le vi potencial hace 5 años y opino que su futuro sigue siendo igual de brillante.



 Este es uno de los proyectos que desarrollé completamente en Android nativo. 100% canvas "a pelo"



Hasta ahora, la tecnología mas limitada en la que había trabajado era la extinta JavaME; ¿Os acordáis de cuando los "teléfonos" no se denominaban "smarphones" sino sencillamente "móviles"? Si, aquellos "rechonchetes" Nokias, Motorolas y Alcateles que tenían unas extrañas protuberancias llamadas "botones". Pues en mi anterior empleo de programador pasé unos tres años desarrollando juegos para estos dispositivos.


¿Te gusta instanciar objetos a loco, perro? Pues este estilizado diablo te va a patear el culo.




Aunque si que había considerables limitaciones técnicas (Había un Nokia que te imponía un tamaño máximo del juego de 128KB, por ejemplo) su mayor inconveniente venia dada por la desfragmentación innerente, esto es, que un mismo juego tenia que ser compatible con unas cincuenta familias de móviles distintos, con una implementación de JAVA que variaba (Cada uno era de un padre y una madre) que por el hardaware subyacente, que también, si, pero sobre todo por la desfragmentación.

Pero GameBoy es otro mundo. Es mas, es otra Galaxia.


Aunque lo publicitaran como un artilugio super-mega-futurista, ya en su día, la Gameboy contaba con una CPU "capada" para ahorrar en batería (Y en costes de producción)



Cuando programas para GameBoy, a diferencia de la concepción actual, no puedes "hacer" lo que te de la gana. Pensad que GameBoy ya era una máquina limitada en 1990. Cualquier pequeño detalle que en una plataforma actual es sencillo de realizar, en GameBoy puede resultar toda una odisea y cada una de las tomas de decisiones que afectan al diseño del juego viene condiciona, siempre, por la imposición del hardaware.

Si pensabais que la limitación de 128KB de aquel Nokia era dura...el reto ahora está en no exceder de los 32KB. En ese espacio tiene que entrar todo; la lógica del juego, los gráficos y el sonido.

Es todo un reto para mi porque vengo de la programación de alto nivel. La programación de alto nivel no significa que uno es un ninja programando, significa que puedes codificar y diseñar un proyecto sin necesitar conocer la arquitectura interna de la máquina. En GameBoy esto es impensable, no vale que el código sea bonito, exportable o modular, no, eso no, ha de ser rápido y ocupar poco espacio.

y para finalizar esta primera entrada que he alargado mas de los deseado, cito una pequeña lista de limitaciones e imposiciones con las que voy a lidiar:


  • Tamaño máximo del juego de 32KB.
  • Sprites de 8x8 píxeles.
  • 40 Sprites como máximo para todo el juego. Pensad que Super PepeToni se compone 2x8 sprites, es decir, el sólo ya se "chupa" 16 de los 40 disponibles.
  • Increíble paleta para los gráficos de hasta...4 tonos de gris.
  • Imposibilidad usar variables con precisión de coma flotante (Esta limitación ya la sufrí en la época de JavaME)
  • Aunque se puede, las operaciones aritméticas de multiplicación y división son efectuadas por software, lo que significa que son muy lentas. Así que a desplazar bits toca (De nuevo).
  • Todas la memoria reservada para las variables del juego deben de caber en el espacio de memoria de la frame de cada método. Punteros si, claro, pero alojarlos en el heap como que no (Ya explicaré este punto con mas detalle)
  • Toda la lógica del juego debe de resolverse antes de que empiece el barrido vertical de la pantalla que accede a la memoria de vídeo para pintar los sprites. Si se lee de la memoria de vídeo mientras esto ocurre se producen efectos raros. Esto significa que el código debe de ser lo suficiente rápido para que no le coja el "toro del dibujado".



Esta sería la solución fácil para los débiles de espíritu y también para aquellos que no perderán las horas de sueño que voy a perder yo \o/



Y eso es todo de momento. Volveré con nuevas aventuras.

Saludos.




domingo, 11 de diciembre de 2016

Super Pepe Toni. La historía del héroe mas grande

Cuando el planeta caminaba hacía la perdición a causa de multitud de malvados, maquiavelos en la sombra, y nada ni nadie parecía tener la receta para remediarlo, la ayuda llegó, una vez mas, del espacio exterior en forma de ser omnipoderoso; Super Pepe Toni es un increíble personaje de origen extraterrestre con una fuerza insuperable, una destreza sin paragón y una voluntad noble, cuando se lo propone.

Su único problema es que es tan holgazán que se traga el diario de Ana Rosa en Antena 3 con tal de no levantarse del sofá a cambiar de canal porque hace cuatro meses que el mando de la televisión se quedó sin pilas.

Por otro lado, El Xali, alocado villano que quiere convertir el mundo en un lugar caótico donde reine la locura, ha logrado hipnotizar a los personajes mas peligrosos e influyentes del mundo para que acaben con Super Pepe Toni, el único capaz de detener sus perturbados planes. Estos son Coco, el mas influyente escritor de todos los tiempos, Xoco, un monstruo con una descomunal fuerza, Babit un robot indestructible y Burufulot, un furioso cretino con un peligroso lobo.

Super Pepe Toni no tendrá mas remedio que levantarse del sofá, apagar la tele con el botón, e ir en busca de cada uno de estos individuos para detenerlos. Y ya de paso, para cuando regrese, pasara por la tienda del barrio a comprar pilas de oferta para el mando de la televisión.








Próximo destino: Game Boy

Uf que abandonado está esto. Da igual. Tras muchos meses liado en otros menesteres que mas o menos tienen que ver con los videojuegos, pero siempre con la programación, he decido que mi siguiente proyecto será algo que realmente me apetezca dejando a un lado su viabilidad comercial.

Dos párrafos de rollazo personal y luego voy al lío.

Cuando era pequeño, de todas las consolas y ordenadores que llegaron a casa: un ZX Spectrum, un clon del Atary 2600, una NES, una MegaDrive, una Game Gear y una Game Boy, le guardo un especial cariño a esta última.
Bien cierto es que todas me proporcionaron incontables horas de diversión y me robaron otras tantas de sueño (y también de estudio) pero es la Game Boy aquella que, por todo lo la hace tal y como es, la que elegí como mi mas fiel compañera de diversión, allá donde fuese.

Desde hace algunos años alguien distribuyó por Internet la documentación técnica oficial de Nintendo de GameBoy y es este hecho lo que probablemente haya dado pie a que exista una excelente librería para programar en lenguaje C o e ensamblador que alguien se ha tomado la molestia de escribir de forma totalmente desinteresada.
En concreto me refiero a GBDK, el cual brinda la oportunidad de codificar en C pero que, no obstante, hace llamadas directamente a rutinas nativas del Z80 de la GameBoy.

C es un lenguaje perfecto para desarrollar para esta arquitectura porque que me permite pensar a mas alto nivel mientras me facilita la posibilidad de optimizar a bajo nivel, algo que para la limitada GameBoy es prácticamente imprescindible.

Así que, tras documentarme un poco de aquí y de allá e inspirado por un ex-compañero de trabajo que ya ha hecho su primer pinito con esta librería, he decidido arremangare y desarrollar mi propio juego para aquella máquina que tantas horas de felicitad me brindo y a la cual considero como una influencia para mi que ha determinado el rumbo de mi vida.

Querida Game Boy, este es mi homenaje para ti. Durante las próximas semanas iré reportando mi avance de lo que se convertirá en un juego completo para la Game Boy.

Por cierto, me confirma Francisco Hoyos  que se va a encargar del apartado sonoro, así aunque el juego sea feo y esté mal hecho, al menos sonará bien.

Saludos.





martes, 13 de mayo de 2014

Warrior's Quest en pantalla grande.

Cuando uno se acomoda en el sofá, delante de una buena tele y con un pad en las manos, es cuando realmente se siente que está jugando a un videojuego DE VERDAD.

Gracias a la conectividad de muchos dispositivos multimedia esto es posible en Android y...así se ve Warrior's Quest en una tele de 32 pulgadas.

sábado, 26 de abril de 2014

BLOCKS! Publicado en GooglePlay y Balckberry World


Y tras unos dos meses de trabajar los fines de semana de forma dura, llega BLOCKS!, considerado como un proyecto de "factura rápida" (Que no por ello peor) y que ve la luz en dos de las tiendas mas importantes de la telefonía móvil: GooglePlay y BlackBerry World

Si algo destacaría de BLOCKS! es lo bien que considero que está cerrado y terminado a nivel técnico, los conocimientos que me ha aportado su desarrollo de algunas clases de bajo nivel del framework de Android y que es compatible con todas las versiones de Android que existen.

Además, pese a que es en HD, sólo ocupa 1.7 Megas de memoria.

A nivel jugable considero que es un juego muy adictivo por su sencillez, concepto y solvencia.
Los gráficos y el diseño, también ideados y producidos por un servidor (¡Ufff!), creo que son acertados y ayudan a transmitir ese toque de sencillez que envuelve toda la atmósfera de BLOCKS!.

De nuevo felicitar al compositor Francisco Hoyos por la BSO y los efectos de sonido, que si bien en mi opinión su punto fuerte son las composiciones de temas épicos y fantásticos, creo que se ha adaptado mas que bien a este proyecto y lo ha resuelto con elegancia.

Bueno, paro ya de promocionar juegos que lo mio es hacerlos. Ahora a retomar la versión FULL de Warrior's Quest, pues los demonios del inframundo empiezan a acumularse al otro lado de la puerta y no dejan de llamar insistentemente con el objetivo de que les deje ver la luz que hay final de la mazmorra.

Hasta otra :)