ES KAsi UN blog

Blog de Unkasoft, donde hablamos de programación de juegos para móviles, advergaming, marketing móvil, la industria de los videojuegos, metodologías ágiles y todos aquellos temas que nos preocupan en nuestro día a día

25 octubre 2006

Estrujemos esos píxeles

En una empresa como la nuestra, cuyo problema al hacer videojuegos para la plataforma móvil siempre es la falta de capacidad para añadir todos los detalles divertidos que se nos ocurren, poder disponer del máximo nivel de compresión para nuestros gráficos es una gran ventaja. Eso nos permite disponer de recursos, no solo para poder añadir más gráficos, sino alternativamente, para añadir por ejemplo comportamientos a los personajes, o bien más niveles o niveles más grandes.
De ahí que le dediquemos atención a las herramientas de compresión que podemos localizar y que prometen un buen rendimiento. Hasta el momento habíamos conseguido una buena combinación de facilidad de trabajo, compatibilidad con nuestra herramienta de desarrollo, Unkasoft Platform, y bajo peso utilizando un procesado de tres aplicaciones.
El trabajo base lo realizamos con Photoshop, que nos proporciona buena capacidad de trabajo y velocidad con altos pesos, y en algunos casos nos crea archivos compatibles con Unkasoft Platform. Seguidamente y para asegurar la compatibilidad y eliminar datos innecesarios de los archivos los abrimos y exportamos desde la aplicación de código libre Gimp. El peso desciende, pero sigue siendo alto. Por último, hemos probado varias herramientas específicas de compresión de imágenes en formato .png, que es el que se usa en los soportes móviles, y hasta la fecha la que mejor compresión ofrecía era sin duda Pngout.
Durante un tiempo hemos usado la versión de esta aplicación que se lanza desde línea de comando, con la consiguiente perdida de tiempo, pero cuando vimos que estaba disponible la versión de windows, capaz de tratar paquetes de archivos, y además con una capacidad de compresión mejorada, no dudamos en adquirirla.

Recientemente hemos detectado algunas herramientas que, según los usuarios, mejoran las prestaciones de Pngout, concretamente se trata de Xat image optimizer (http://www.xat.com), pngquant (http://libpng.nigilist.ru/pub/png/apps/pngquant.html), y superpng (http://www.fnordware.com/superpng).

Respecto al primero, Xat se trata de una aplicación que en principio, resulta muy útil. Permite automatizar el proceso de reducción de la paleta de colores usando un algoritmo propio, que da bastante buen resultado. Sin embargo, en lo que a Unkasoft respecta, la elección de la paleta de colores se realiza en cada caso con mucho detenimiento, en ocasiones incluso seleccionando uno a uno los colores para optimizar el resultado. Por otra parte como herramienta de compresión es realmente aceptable, pero no supera en modo alguno los resultados de la versión sobre windows de pngout (algo más eficiente que la de línea de comando). De ahí que no nos resulte muy interesante.

Por otra parte, pngquant como compresor no logra superar los resultados de pngout, pero sin embargo tiene una habilidad que puede resultar extremadamente útil: Permite crear pngs cuya información de colores tenga solamente 8 bits (paleta de colores indexada) y al mismo tiempo incluir otros 8 bits de información conteniendo la transparencia del archivo (Permitiendo transparencias parciales).De las imágenes de la izquierda, la primera es una imágen de 32 bits de Photoshop, mientras que la derecha es una imágen de 16 bits obtenida con pngquant. Lamentablemente, para verlas correctamente es necesario un navegador que lea correctamente estos formatos, como mozilla.
Esto supone un gran ahorro de espacio en relación con la opción que nos ofrece Photoshop, que es crear un png de 8 bits por canal, es decir de 32 bits, frente a los 16 incluidos por pngquant. Según parece pngout permitirá también la creación de este tipo de archivos, pero por el momento y hasta donde sabemos no es así.

Por último superpng es un plugin para photoshop que permite ampliar las posibilidades de exportación y lectura de pngs, la cual sobre todo hasta la versión 7 es muy limitada en cuanto a las variantes admitidas. Al mismo tiempo optimiza el tamaño de salida de los pngs y ahí es donde nos resulta más útil, puesto que esta reducción no se solapa sino que se añade a la que ofrece pngout, reduciendo aún más el tamaño final del archivo.

En resumen, estas tres aplicaciones y especialmente pngquant y superpng son muy recomendables como complemento a la hora de optimizar nuestras posibilidades de trabajo sin perder en ningún caso calidad de imagen.

Etiquetas:


Comentarios:

Desde la ignorancia del funcionamiento de lo móviles: no se podría plantear la posibilidad de generar las texturas proceduralmente ? Para ciertas cosas no es viable, pero me imagino para para ciertos fondos, etc sí puede ser interesante.
 


No hay nada mejor que el PNGOUT. La última versión de hace un días incluso mejora la compresión (aunque muy poco).
Para optimizar no hay nada como el Photoshop y su "Guardar para Web" (completito, integrado, versátil...). Como último recurso siempre queda la optimización a mano.
 


Es una buena pregunta Javi; en principio parece prometedor usar fondos (por ejemplo) procedurales, pero falta plantearse la utilidad que van a tener; Será más interesante cuanto más grande sea el fondo, y siempre contando con que no haya que incorporarle elementos específicos (por ejemplo una puerta de salida a otro nivel). La verdad es que los escenarios de los juegos para móviles suelen ser de tamaño muy reducido, y en los casos en que no es así (por ejemplo en nuestro juego "El 4º sello") se trata de escenarios que deben poderse detallar a gusto del diseñador de los niveles (para esos casos usamos tiles, que repetidos nos dan mucha variedad a poco coste.
Sin embargo si es posible imaginarse un juego en que le sacaramos partido a una textura procedural de fondo (por ejemplo de plataformas), así que me voy a informar con nuestros chicos expertos en el rendimiento de los móviles y te mantendré al día.
 


Desde luego Daniel, el guardado para web de Photoshop es lo más cómodo y permite un control muy grande sobre el resultado, pero si andas corto de espacio te recomiendo que después de optimizar con Photoshop vuelvas a abrir tu png y lo exportes con Superpng. Verás algo de reducción que siempre es de agradecer.
 


Gracias por los datos de esas otras herramientas, las voy a probar.
Yo usé Pngout y ahora estoy usando PngGauntlet, que tiene un IDE muy cómodo y obtengo muy buenos resultados.
 


De nada, tomo nota del pngGauntlet, seguro que aún podemos estrujarles un poco más....
 


@jesus: no dejeis de comentar los avances que tengais en esa línea :)
 


Javi, me temo que con tu pregunta (que yo les he trasladado) hemos puesto en apuros a nuestros programadores :-). Seguro que en breve te podré comentar algo respecto de los mapas procedurales. Por lo pronto, la aplicación que nos recomendaba Sergio parece ser que usa como compresor al pngout, y por lo menos yo estoy contento con la comodidad y el funcionamiento en general de la versión de windows, así que por ahora me quedo con el pngoutWin.
 


El tema promete bastante, no sé qué capacidad tiene un móvil convencional para hacer ese tipo de cosas, pero hay cosas por ahí (*) que quital el hipo. El video que muestran parece que tiene aceleración por HW, pero de deja de quitar el hipo. Seguramente los dispositivos que soporten 3D tengan suficiente cantidad de memoria para almacenar cientos de texturas y recursos sin problemas, pero estoy seguro que el modelo de venta por descarga se alegraría muchísimo de ver como el peso de los juegos se reduce drásticamente. Me imagino bajarme un juego completo en 3D en unos pocos kb. Además, el negocio de los juegos 3D para móvil parece que arranca, solo hay que ver que gameloft ya empieza a meterse e intel, ati y nvidia tienen ya sus chipsets funcionando en dispositivos móviles.

Lógicamente para dispositivos más cortos de recursos no es lógico implementarse todo un sistema completo de generación procedural, pero con unas pocas líneas de código se generan texturas vistosas y útiles.



(*) http://www.theprodukkt.com/mobile
 


Yo (como Dani Blazquez) utilizo Photoshop con su opción "Guardar para web..." y luego el pngout (la version DOS, la de Win no la he probado). Adicionalmente la ventaja que me da este método es que Photoshop me deja guardar y aplicar una paleta de 256 colores a los gráficos, y el pngout tiene la opción de comprimir el gráfico dejando intacta la paleta (opción que no econtré cuando evalué xat y otros). En mi caso siempre uso una única paleta para todos los gráficos del juego (o del nivel si quiere diferentes gamas en distintas fases del juego), lo que un tercer paso que efectue en el proceso es "extirpar" la paleta de todos los pngs (lo que es un punto más para ahorrar espacio en todos los pngs) y luego compongo el png dinamicamente en la carga del juego.
Salu2
 


Javi, estoy en manos de los que saben más que yo de las capacidades de los teléfonos, pero desde luego yo le veo un mundo de posibilidades...
 


En efecto, Imagame, yo también uso Photoshop para especificar la paleta. Pero una vez tienes un archivo con la paleta exacata que quieres, si lo vulves a abrir y lo exportas con superpng desde Photoshopantesde pasar por pngout verás reducido el tamaño sin cambios en la paleta de colores (hasta donde he podido comprobar).
Y respecto al tercer paso del que hablas, ¿te importaría explicar más en detalle como "extirpas" la paleta de colores del png? Yo no suelo tener una sola paleta de colores para todo el juego, pero si tu sistema supone una ventaja importante estoy dispuesto a intentarlo!
 


Hola, la verdad es que el mayor problema para manejar texturas en el móvil son las limitaciones de potencia y memoria, me explico:
Tener una textura sacada de un archivo necesita de memoria para el BITMAP que representa dicha textura, es decir, que no tenemos en memria un PNG, sino un BITMAP y que al final ocupa mucho. Obtener la textura ya sea de un archivo desde un PNG (comprimido) o de forma procedural, no creo que cambie mucho el resultado. Por un lado la textura en PNG ocupa "poco" y el código para generar una textura en memoria también ocupa. Por otro lado, hacerlo de forma procedural limita las texturas que se pueden usar a los algoritmos básicos que funcionarían bien en un móvil. También tenemos una restricción de potencia y crear las texturas necesitará de bastante tiempo que tendremos que rellenar delante del usuario (barra de estado?).
Mi conclusión es que habría que hacer un ejemplo y ver las diferencias, auqnue mi experiencia me dice que con los teléfonos pequeños ambas cosas no se usarán por el momento.
Respecto a los juegos en 3D, por el momento hay pocos y pocos teléfonos que realmente den un buen resultado, creo que en un año o año y medio el tema mejorará bastante.
 


No había visto aún el video Javi, pero desde luego es impresionante 8 )
 


Por lo que se ve del vídeo, parece que funciona en teléfonos de gama muy alta y con código nativo. Es decir que de los juegos Java ni hablamos por el momento. Aparentemente están creando y usando las texturas en tiempo real (por lo que dicen de la memoria), impensable para el 90% de los modélos de teléfonos actuales, ni siquiera los Sony-Ericsson con procesadores duales. Tampoco veo claro que usando código nativo se pueda tener éxito en el mercado actualmente, con Java hay bastantes problemas de compatibilidad y es lo más extendido. Como demostración tecnológica sobre un Windows Mobile y desarrollado en .NET (C/C++) está muy bien y creo que podremos ver buenas cosas para salir al mercado a partir de finales del 2007.
 


No he programado nunca para móvil, sin embargo parece que java no ha funcionado ni funciona demasiado bien en lo que ha compatibilidad se refiere. Para windows CE si que he programado y no veo problema para poder usar C++(lenguaje al que cualquier programador de juegos está sobradamente acostumbrado), sin demasiados problemas de compatibilidad entre terminales.
Sabiendo que muchos de los móviles empiezan a llevar windows mobile y chipsets para aceleración 3D no creo que tardemos en ver cosas de ese tipo. jaja, incluso sin tener chipset que acelere se pueden hacer cosillas con el raster por SW de alguna implementación de OpenGLES (siempre que no uses texture mapping) :).

Incluso algunos programadores que conozco de xbox live están haciendo uso de texturas procedurales para evitar que el peso del juego sea grande (imprescindible en juegos para descargar), aunque luego en disco ocupen la tira.

En resumen, los teléfonos que ahora son de gama alta, serán gama media en poco tiempo :). Esperemos que unkasoft nos enseñe unos cuantos juegos en 3D :P.
 


Sobre el tema de la compatibilidad, dependemos de lo estricto que sea el estándar a la hora de aceptar una implementación de la máquina virtual. J2ME ha preferido expandirse muy rapidamente (cosa que ha conseguido) a costa de ser flexibles en las implementaciones (cada fabricante ha hecho lo que le ha dado la gana). Según dices, la gente de Microsoft ha preferido ser más estrictos a la hora de dar el visto bueno a la implementación de la VM de .NET (un sugus para ellos :)

Ale, a disfrutar del solito murciano (:
 


yo me uno a tu deseo, Javi, aún cuando me suponga ponerme a aprender a programar texturas procedurales
8 )
 


@jm: estoy "disfrutando" del calor murciano, aunque soy de Valladolid, de ahí mis problemas con el solito :).

@jesús: Yo no abro el photoshop para crear una textura, yo la programo :P. Al final se le coge el truquillo y salen cosas chulas. Si quieres probar una herramienta de generación procedural curiosa mira http://www.scene.org/file_dl.php?url=http://http.de.scene.org/pub/resources/demomaker/theprodukkt/pno0002_werkkzeug1_v1200.zip&id=242925
Hay un tutorial muy simple y bastante espectacular.
 


Hombre, muchas gracias por el vínculo, le echo un vistazo en cuanto pueda
;)
 


Publicar un comentario

Links to this post:

Crear un enlace



<< Home

This page is powered by Blogger. Isn't yours?