--------=======Formato de almacenamiento de sprites del SNES y el GB, ver 0.0=======-------- Por FDwR on 1998-05-28 Para cualquiera que quiera divertirse editando las imágenes en sus juegos, exportar sus personajes favoritos a imágenes separadas, o simplemente aprender sobre los gráficos de Nintendo, este documento le explicará cómo es que están almacenados. Se espera que al menos se entienda qué son bits, bytes y píxeles. 1. Introducción a los Tiles 2. Bitplanes (*planos de bits*) 3. Lista de todos los formatos conocidos 4. Los programas que permiten visualizarlos 5. Problemas al encontrar sprites 6. Agradecimientos, créditos y fuentes 1. -- Introducción a los Tiles -------- Si usted ya leyó otros documentos sobre cómo los gráficos son almacenados en la consola, entonces estará bastante familiarizado con esto; sin embargo, este documento explica cómo son almacenados en el cartucho ROM, no en el Video RAM (*VRAM*) de la consola cuando se está jugando. La mayoría de las veces, los sprites son almacenados en el ROM de la misma forma en que quedarían en el VRAM para simplificar las cosas. En algunas ocasiones, para ahorrar espacio, pueden ser ordenados de manera muy diferente en varios formatos comprimidos. Teóricamente, se podrían almacenar de cualquier forma siempre y cuando sean eventualmente convertidas a los tiles estándar de 1, 2 ó 4 bits que los dos PPU's (Picture Proccesing Units) entienden. No obstante, para ver o editar esas imágenes en el ROM, necesitamos saber también cómo están ordenadas en sus formatos de compresión. Para los que aun no han leído los documentos de Yoshi o de Dax sobre los formatos de los sprites, aquí tienen una pequeña intro. A diferencia de las imágenes de los juegos de computadora, los cuales están compuestos por cientos de píxeles individuales, cada uno dibujado por el software mismo, los sistemas de consola (incluyendo el NES, Sega, GameBoy y el SNES) construyen todas sus escenas con bloques más grandes llamados "tiles", los cuales son automáticamente manipulados por chips de gráficos dedicados. En el caso de las consolas de Nintendo, cada tile es siempre de 8x8 píxeles. Aunque el número de colores puede ser variable, las dimensiones son siempre las mismas. Bloques más grandes cómo de 16x16 están compuestos en realidad de tiles más pequeños de 8x8, cuatro para ser exactos. Sprites de 32x32 estarían hechos de dieciséis tiles. ¿Por qué el SNES dibuja todo con esos bloques armados en vez de utilizar pequeños píxeles? Primero, porque es más simple; segundo porque ahorra mucho espacio. En lugar de tener dos copias de los 256 píxeles por 16x16 bloques en pantalla, sólo necesitas una copia del tile y luego dos números de tile para especificar cuáles usar. Por supuesto también hay algunas desventajas, como no poder dibujar píxeles individuales con tanta facilidad, pero aparentemente los beneficios superan a las desventajas. En vez de almacenar la totalidad de los valores de color de los píxeles, sólo se almacenan los pocos colores utilizados en el sprite. La rutina de compresión de color reduce los requerimientos de tamaño a la mitad para la mayoría de los sprites y permite fáciles efectos de rotación de paleta. El 'color' de cada píxel es en realidad un índice a esa paleta de sprites y colores usados, el cual se traduce después a un valor RGB real. Un personaje promedio ni siquiera usa más de 10 colores así que, ¿para qué almacenar un valor de color completo de 8 o 256 bits? Para almacenar los 16 colores normales que podría utilizar un sprite, se necesitan 4 bits por píxel. Para 8 colores, sólo 3 bits por píxel; y para imágenes monocromáticas (dos colores), sólo se requiere de un bit para representar un píxel. Si alguna vez ha notado los mismos enemigos, pero con diferente color, o que en muchos juegos brilla un flash cuando se ataca a un enemigo, pues eso se logra de manera muy simple cambiando las paletas para esos sprites. Otra ventaja de la compresión de color es que el juego no necesita cambiar el valor de cada color en el tile, sólo los valores RGB asociados a esos índices de color. Por cierto, como corrección, los valores de color son realmente almacenados en la paleta como un BGR con el rojo como los cinco bits de más abajo en lugar del azul (los diseñadores Japoneses decidieron revertir el orden estándar por alguna razón). Sin embargo, eso no cambia nada. 2. -- Bitplanes (planos de bits) ---------- A excepción del modo 7 (que es diferente a todo lo demás), cada tile está ordenado de derecha a izquierda (reverse order *orden invertido*), de arriba a abajo. Cada byte representa una fila de bits de ocho píxeles (*eight pixel bits*) (no píxeles completos). El número de bytes necesario para una fila completa depende de la profundidad de colores, o más bien del número de bits necesario para representar esa cantidad de colores. Tiles de 1 bit necesitarían 1 byte (8bits) para una sólo fila monocromática; tiles de 4 bits necesitarían 4 bytes (32 bits). A diferencia de la mayoría de los formatos gráficos de PC, en vez de estar almacenados todos los bits de cada píxel uno junto al otro en el mismo byte, son almacenados con bits paralelos de otros píxeles en la misma fila. Los primeros bits de una fila completa de ocho píxeles son almacenados en el primer byte; todos los ocho de los segundos bits son almacenados en el segundo byte, los terceros bits en el tercer byte, y así con todos los bits que sean necesarios para expresar los que colores requeridos por ese tile (desde 2 hasta 256). A todos los bits paralelos de un tile se les llama bitplane (bpl). Nótese que screen planes (planos de pantalla) y bit planes (planos de bit) son cosas completamente diferentes. Para hacer un píxel completo, todos los bits divididos de un píxel se procesan por OR hasta lograr la profundidad de bit deseada. 3 3 3 3 3 3 3 3 ------- bitplane 3 3 2 2 2 2 2 2 2 2 ----- bitplane 2 3 2 1 1 1 1 1 1 1 1 --- bitplane 1 3 2 1 0 0 0 0 0 0 0 0 - bitplane 0 3 2 1 0 0 0 0 0 0 0 0 3 2 1 0 0 0 0 0 0 0 0 Nótese como los bitplanes 3 2 1 0 0 0 0 0 0 0 0 siempre tienen base cero. 3 2 1 0 0 0 0 0 0 0 0 2 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Por ejemplo, si en una fila completa, píxeles de 4 bits (16 colores) tuvieran una secuencia de 4,0,2,7,6,10,15,0 serían almacenados así: Como píxeles: Luego reordenados como bitplanes: 0123 01234567 ????????¦ ?????????¦ 0 ?? 4 0100 0 ?? 00000110 byte 0 1 ?? 0 0000 1 ?? 10011010 byte 1 2 ?? 2 0010 2 ?? 00111110 byte 2 3 ?? 7 0111 3 ?? 00010010 byte 3 4 ?? 6 0110 5 ?? 10 1010 6 ?? 15 1111 7 ?? 0 0000 Nótese cómo la columna vertical (bits paralelos) se convierte en la fila horizontal de cada bitplane, y cómo agregar otro byte a los bitplanes esencialmente añadiría un bit extra a cada uno de los ocho píxeles (para hacer 32 colores). Si el tile arriba fuera parte de un fondo que necesita ser usado primero para tiles de 8 bpl, sólo se añadirían cuatro bytes extra a los primeros cuatro para hacer 8. ¿Ve lo fácil que es para los juegos convertir de un modo de bits a otro si no necesita hacer montones de cambios de bits sino sólo centrarse en bytes completos? Muchas veces, los sprites del SNES sólo necesitarán 8 colores y serán almacenados con 3 bits, pero como el PPU sólo maneja en forma nativa sprites de 4 bits, necesitan que se les añada un bitplane extra vacío. Simplemente añadir un byte extra por cada tres ahorra el fastidio de tener que hacer rotaciones y operaciones OR. Por cierto, ya que los sprites del SNES (objetos que se mueven independientemente) sólo pueden tener 16 colores, los restantes tiles de tamaño de bit (*bitsize tiles*) son enviados directamente a VRAM como imágenes estáticas. Recuerde que para cualquier sprite, el valor de cada píxel es un índice a su página de paleta de 16 colores. El 6 significa imprimir el valor absoluto del color del índice 6 en la paleta de la página actual - ese valor RGB podría ser en realidad cualquier cosa. Escuché que hay 16 paletas de 16 colores cada una en la paleta principal de 256 colores, pero sólo 8 de esas puede ser usada por sprites (???)... Parece una severa limitación, pero de alguna forma los expertos en paletas le sacan el máximo provecho y logran hacer que los juegos parezcan tener más colores de los que realmente tienen. Desgraciadamente, el ejemplo que puse arriba es en realidad más perfecto de como son los tiles en la realidad. Los bitplanes no son todos limpios y claros, viniendo uno directamente después del anterior. Algunos son independientes, mientras que otros están entrelazados entre sí. Este revoltijo extra realmente no nos ayuda a encontrar gráficos, pero es fácil de compensar. 3. -- Lista de todos los formatos conocidos -- Hay seis modos comunes usados por los juegos de SNES para almacenar gráficos. Cuatro son modos con compresión de color que usan de 1 a 4 bits para expresar un único valor de píxel. Los otros dos son ambos modos de 8 bits que usan todos los 256 colores (o sea, no se necesitan páginas de paletas). Uno de ellos es el famoso modo 7 con el que fuimos todos impresionados en 1991 (y sigue siendo sorprendente). El GameBoy usa exactamente los mismos formatos de 1 y 2 bits que el SNES, excepto que en vez de que los píxeles se traduzcan a colores, sólo se traducen a sombras de gris. También hay dos formatos (1bit,2bit) usados por unos pocos juegos que tienen tiles de 8x12. Tres de los formatos familiares (1,2,4) los aprendí de varios documentos. Los otros tres (3,7,8) los descubrí yo mismo con un poco de prueba y error. Nadie sabía de los modos 3 y 7 y no existía documentación previa sobre ellos - esa es parte de la razón por la que estoy escribiendo esto. El único documento sobre 8 bpl ni siquiera era correcto. Cada modo tiene unas cuantas posiciones en juegos en los que usted puede encontrar una imagen en ese modo. Son todos juegos bastante comunes, con las posiciones dadas como usted las encontraría en SMC's (*ROM's de SNES*) con encabezado de 512 bytes (para un ROM puro sin encabezado, reste esos primeros 512 bytes). Y que el primer byte es siempre uno cuando se trabaja con registros (*records*) en Qbasic, todas las posiciones tienen base uno (en lugar de base cero). Junto con la información de formato, hay también una pequeña letra 'A' como ejemplo para cada modo. (*todos los modos en este documento dibujan una letra 'A'*) Por cierto, usted puede descubrir fácilmente el tamaño de un tile con la fórmula (alto x ancho) * bits \ 8. En el caso de tiles de tamaño normal, los ochos se cancelan y usted sólo necesita usar 8 * bits. -- 1bit bitplane 8x8 -- 2 colores, 8 bytes: Usados más comúnmente para fuentes monocromáticas Por supuesto este es el más simple, con sólo 1 bitplane, cada fila viniendo justo después de la anterior. Fue aprendida del documento de Yoshi. Sin ejemplos (no puedo recordad ninguno en este momento) Byte 0| Fila 0| Bpl 0| 00011000 0 /-- <====Bitplane 0 1| 1| 0| 00111100 1 |-- 2| 2| 0| 01100110 2 |-- 3| 3| 0| 11000011 3 |-- 4| 4| 0| 11111111 4 |-- 5| 5| 0| 11000011 5 |-- 6| 6| 0| 11000011 6 |-- 7| 7| 0| 11000011 7 \-- -- 2bit bitplane 8x8 -- 4 colores, 16 bytes: Usado en muchos lugares en SNES y GB Zelda: 459265-FuenteFamiliar ZeldaGB: 196609-InicioDeGráficos,252929-MásCosas Metroid 3: 865283-PedazosDeMapas El GameBoy usa este modo para sus sprites, con 6 sombras de gris. El SNES usualmente no lo usa para sprites, sino más comúnmente para texto y cosas que necesitan sólo dos colores. Es similar a 1 bpl en que las filas aparecen secuencialmente, excepto que está hecho por dos bitplanes de 1 bpl entrelazados. Este fue explicado en el documento de Pan, y en el código fuente de VileWrath. Byte 0| Fila 0| Bpl 0| 00011000 0 /-- <=====Bitplane 0 1| 0| Bpl 1| 00000000 | --\ 0 <=Bitplane 1 2| 1| 0| 00111100 1 |-- | 3| 1| 1| 00000000 | --| 1 4| 2| 0| 01100110 2 |-- | 5| 2| 1| 00000000 | --| 2 6| 3| 0| 11000011 3 |-- | 7| 3| 1| 00000000 | --| 3 8| 4| 0| 11111111 4 |-- | 9| 4| 1| 00000000 | --| 4 10| 5| 0| 11000011 5 |-- | 11| 5| 1| 00000000 | --| 5 12| 6| 0| 11000011 6 |-- | 13| 6| 1| 00000000 | --| 6 14| 7| 0| 11000011 7 \-- | 15| 7| 1| 00000000 --/ 7 -- 3bit bitplane, 8x8 -- 8 colores, 24 bytes: Usado mucho en juegos RPG para ahorrar espacio Zelda: 553473-Armas FF2: 295425-Enemigos,374041-Personajes,407745-MásPersonajes Cuando los sprites necesitan 4 colores, pero no necesariamente 16, este es el formato que usualmente se usa. No es un formato nativo del SNES, así que los juegos deben primero traducirlos a sprites de 4 bits. El GameBoy no maneja este modo ya que su PPU sólo muestra 4 sombras de gris. Los primeros 2 bitplanes (0,1) están entrelazados como 2 bpl y el tercero (2) es un único 1 bpl que viene al final de ellos. ¿Cómo es que nadie descubrió esto antes que yo, si es usado en tantos juegos? Bueno, técnicamente, los programadores de SNES lo 'descubrieron' mucho antes de que yo conociera de emulación (simplemente fue 'redescubierto' :-). Hasta ahora, sólo le había dicho a una persona sobre este precioso modo y sólo su visualizador lo maneja (Magnus Runesson's SMC-Ripper). Eso puede que cambie pronto en cuanto en cuanto todos lo prueben y este documento sea publicado. Byte 0| Fila 0| Bpl 0| 00011000 0 /-- <=====Bitplane 0 1| 0| Bpl 1| 00000000 | --\ 0 <=Bitplane 1 2| 1| 0| 00111100 1 |-- | 3| 1| 1| 00000000 | --| 1 4| 2| 0| 01100110 2 |-- | 5| 2| 1| 00000000 | --| 2 6| 3| 0| 11000011 3 |-- | 7| 3| 1| 00000000 | --| 3 8| 4| 0| 11111111 4 |-- | 9| 4| 1| 00000000 | --| 4 10| 5| 0| 11000011 5 |-- | 11| 5| 1| 00000000 | --| 5 12| 6| 0| 11000011 6 |-- | 13| 6| 1| 00000000 | --| 6 14| 7| 0| 11000011 7 \-- | 15| 7| 1| 00000000 --/ 7 16| 0| Bpl 2| 11100111 0 /-- <=====Bitplane 2 17| 1| 2| 11000011 1 |-- 18| 2| 2| 10011001 2 |-- 19| 3| 2| 00111100 3 |-- 20| 4| 2| 00000000 4 |-- 21| 5| 2| 00111100 5 |-- 22| 6| 2| 00111100 6 |-- 23| 7| 2| 00111100 7 \-- -- 4bit bitplane 8x8 -- 16 colores, 32 bytes: El formato nativo de los sprites del SNES Zelda: 524801-Link Mario AllStars: 1820687-Mario3, Casi en todo lado FF2: 852481-Personajes Metroid 3: 467969-Zebes,885249-Samus Este es el verdadero formato nativo usado por el SNES para los sprites. Algunas veces los juegos los almacenan en este formato porque los sprites requieren de casi todos los 16 colores, porque es más fácil, o porque no les preocupa el espacio de almacenamiento y no quieren molestarse con la conversión. Por ejemplo, mientras que la mayoría de las imágenes en Zelda están comprimidas (fastidiosamente) debido al pequeño tamaño del ROM, las de Super Metroid se dan el lujo de estar expandidas. Ese juego tiene tanto espacio (3MB), que se puede dar el lujo de desperdiciar un poco. 4 bpl es como dos 2bpl juntos, con los primeros 2 bitplanes (0,1) en el primer tile 2bpl y los últimos 2 bitplanes (3,4) en el segundo tile 2bpl. El documento Corsair es el único acertado que he visto sobre este modo tan común. Byte 0| Fila 0| Bpl 0| 00011000 0 /-- <=====Bitplane 0 1| 0| Bpl 1| 00000000 | --\ 0 <=Bitplane 1 2| 1| 0| 00111100 1 |-- | 3| 1| 1| 00000000 | --| 1 4| 2| 0| 01100110 2 |-- | 5| 2| 1| 00000000 | --| 2 6| 3| 0| 11000011 3 |-- | 7| 3| 1| 00000000 | --| 3 8| 4| 0| 11111111 4 |-- | 9| 4| 1| 00000000 | --| 4 10| 5| 0| 11000011 5 |-- | 11| 5| 1| 00000000 | --| 5 12| 6| 0| 11000011 6 |-- | 13| 6| 1| 00000000 | --| 6 14| 7| 0| 11000011 7 \-- | 15| 7| 1| 00000000 --/ 7 Principio del segundo tile 2bpl 16| 0| 2| 00000000 0 /-- <=====Bitplane 2 17| 0| 3| 00000000 | --\ 0 <=Bitplane 3 18| 1| 2| 00000000 1 |-- | ... ... 29| 6| 3| 00000000 | --| 6 30| 7| 2| 00000000 7 \-- | 31| 7| 3| 00000000 --/ 7 -- 8bit bitplane 8x8 -- 256 colores, 64 bytes: Usados por pantallas de título e imágenes detalladas Mario AllStars: 33280-Título,1409551-PantallaDeSelección Official SNES Test ROM: 164353-MarioVolando Cuando se necesita de una imagen colorida como en una pantalla de presentación o parte de una historia, éste es el que se usa ya que hace uso de todos los 256 colores. No puede ser usado por sprites, así que cualquier parte de la imagen que necesita moverse o ser animada (aunque usualmente no se mueven) debe ser cambiada manualmente por el código del juego. Son sólo cuatro tiles de 2 bpl, uno después del otro (o puede imaginarlos como dos tiles de 4 bpl). Los primeros dos bitplanes (0,1) son seguidos por los otros dos (2,3), luego el quinto y sexto (4,5) y, por último, por el sétimo y octavo (6,7). Sólo dos visualizadores lo manejan. A pesar del hecho de que ningún documento explicaba estos modos, fue bastante fácil de descubrir. Byte 0| Fila 0| Bpl 0| 0 /-- <=====Bitplane 0 1| 0| Bpl 1| | --\ 0 <=Bitplane 1 2| 1| 2| 1 |-- | ... ... 13| 6| 3| | --| 6 14| 7| 2| 7 \-- | 15| 7| 3| --/ 7 Principio del segundo tile de 2 bpl 16| 0| 2| 0 /-- <=====Bitplane 2 17| 0| 3| | --\ 0 <=Bitplane 3 18| 1| 2| 1 |-- | ... ... 29| 6| 3| | --| 6 30| 7| 2| 7 \-- | 31| 7| 3| --/ 7 Principio del tercer tile de 2 bpl 32| 0| 2| 0 /-- <=====Bitplane 4 33| 0| 3| | --\ 0 <=Bitplane 5 34| 1| 2| 1 |-- | ... ... 45| 6| 3| | --| 6 46| 7| 2| 7 \-- | 47| 7| 3| --/ 7 Principio del segundo tile de 2 bpl 48| 0| 2| 0 /-- <=====Bitplane 6 49| 0| 3| | --\ 0 <=Bitplane 7 50| 1| 2| 1 |-- | ... ... 61| 6| 3| | --| 6 62| 7| 2| 7 \-- | 63| 7| 3| --/ 7 -- 1bit bitplane 8x12 -- 2 colores, 12 bytes: Usado sólo en algunos juegos para ahorrar un poco de espacio. Sin ejemplos (no he encontrado ninguno todavía) Este modo es muy raro, pero ya que este documento pretende abarcar todos los formatos, está aquí con todos los demás. Es usado cada vez que los tiles deben ser más altos de 8 píxeles pero menores a 16. En el ROM, ahorra como 25% más espacio que si se hiciera de otra forma. Por supuesto, una altura de 12 no es nativamente manejada, así que antes de usarlos en VRAM, el juego debe convertirlos en dos tiles de 8x8 - con las ocho primeras filas en el tile de 8x8, las últimas cuatro filas en el segundo tile, y cuatro filas vacías para completarlo. El formato es exactamente el mismo que 8x8 de 1 bpl excepto que con 12 filas. Todavía no he visto títulos con este modo, pero son explicados en el documento de David Timko. Hasta ahora, ninguno de los visualizadores importantes lo manejan específicamente, aunque es posible editar esos tiles usando el más común modo 1 bpl. Byte 0| Fila 0| Bpl 0| 00011000 0 /-- <=====Bitplane 0 1| 1| 0| 00011000 1 |-- 2| 2| 0| 00111100 2 |-- 3| 3| 0| 01100110 3 |-- 4| 4| 0| 01100110 4 |-- 5| 5| 0| 11000011 5 |-- 6| 6| 0| 11000011 6 |-- 7| 7| 0| 11111111 7 |-- 8| 8| 0| 11111111 8 |-- 9| 9| 0| 11000011 9 |-- 10| 10| 0| 11000011 10 |-- 11| 11| 0| 11000011 11 \-- -- 2bit bitplane 8x12 -- 4 colores, 24 bytes: Usado sólo en algunos juegos para ahorrar un poco de espacio. FF3: Aunque sólo en parte ChronoTrigger: Al puro final Una variación del modo anterior que sólo usa 8x12 de 1 bit para hacer un único tile de 2 bits. Este modo es también usado donde los tiles necesitan ser más altos que 8, pero menos de 16 píxeles, y ahorra como 25% más de espacio que dos tiles de 8x8. Esto no lo he verificado personalmente todavía, así que el formato escrito abajo puede que sea incorrecto. Otra vez, lo conseguí del informativo documento de David Timko. Byte 0| Fila 0| Bpl 0| 00011000 0 /-- <=====Bitplane 0 1| 1| 0| 00011000 1 |-- 2| 2| 0| 00111100 2 |-- 3| 3| 0| 01100110 3 |-- 4| 4| 0| 01100110 4 |-- 5| 5| 0| 11000011 5 |-- 6| 6| 0| 11000011 6 |-- 7| 7| 0| 11111111 7 |-- 8| 8| 0| 11111111 8 |-- 9| 9| 0| 11000011 9 |-- 10| 10| 0| 11000011 10 |-- 11| 11| 0| 11000011 11 \-- Principio del segundo tile 8x12 de 1 bit 12| 0| 1| 00000000 0 /-- <=====Bitplane 1 13| 1| 1| 00000000 1 |-- 14| 2| 1| 00000000 2 |-- 15| 3| 1| 00000000 3 |-- 16| 4| 1| 00000000 4 |-- 17| 5| 1| 00000000 5 |-- 18| 6| 1| 00000000 6 |-- 19| 7| 1| 00000000 7 |-- 20| 8| 1| 00000000 8 |-- 21| 9| 1| 00000000 9 |-- 22| 10| 1| 00000000 10 |-- 23| 11| 1| 00000000 11 \-- -- 8bit mode7 8x8 -- 256 colores, 64 bytes: Usado cuando se necesitan buenos efectos Zelda: 803329-PiezasDelMapaEscalable Hasta ahora Zelda es el único juego en el que he buscado gráficos de Modo 7. Un juego como ActRaiser probablemente tenga muchas piezas de mapa. Mario Kart podría ser una buena fuente. Este modo es muy diferente a todos los demás. En vez de trabajar con bitplanes y paletas, todos los bytes representan un sólo píxel que corresponde a un color en la paleta principal. La diferencia entre este formato y el 8 bpl es que este modo puede ser usado (con la ayuda de un buen hardware) para excepcionales efectos de escalación (*scaling*), paralax (*parallaxing*) y rotación. Los datos de la imagen son almacenados casi de la misma forma que en el VRAM, excepto que en VRAM cada píxel está entrelazado por byte (*byte interleaved*) con otros datos. En el ROM, los bytes van contiguos. Me siento tonto por no haberlo descubierto por tanto tiempo, ya que es tan simple. Hasta ahora, al momento en que se escribió este documento, ninguno de los visualizadores importantes lo manejan. ¡Ya que no utiliza bitplanes, es mucho más simple de ver, editar y explicar! Bytes 0-7 | Fila 0| ---HI--- Bytes 8-15 | Fila 1| --MYNA-- Bytes 16-23| Fila 2| -ME--IS- Bytes 24-31| Fila 3| DW----AY Bytes 32-39| Fila 4| NEANDILO Bytes 40-47| Fila 5| VE----TH Bytes 48-55| Fila 6| ES----NE Bytes 56-63| Fila 7| S!----:) -- Los modos desconocidos -- ? colores, ? bytes Sailor Moon: 137139 Metroid 3: 829985,1868289 (este punto me molesta) Este espacio es para los futuros modos que no han sido descubiertos todavía, muchos de ellos en los ROM's japoneses. ¿Cómo sé que todavía hay otros modos sin descubrir? Al mirar ciertos juegos, todos los gráficos simplemente no aparecen. Deben estar por ahí, almacenados de alguna forma. Luego están esas áreas que deben ser gráficos, pero están ligeramente revueltos de alguna forma (como solía estar el 3 bpl). De acuerdo a Pan, puede haber otro formato para almacenar tiles de 2 bits compuestas de dos tiles de 1 bpl, pero eso no ha sido verificado en ningún lugar. Aunque estos son todos los modos comunes, siempre estoy atento a nuevos modos mientras examino ROM's. Si usted tiene alguno que no aparece aquí, cuéntelo por favor. Esta lista no estará completa todos hasta tener los formatos usados por cada juego. 4. -- Los visualizadores que los manejan -- Los modos más comunes (1,2,4) son manejados por cualquier editor respetable. Los otros tres (3,7,8) aparentemente nunca han sido descubiertos o algo, porque en los últimos seis años que esa información sobre el SNES ha estado en la red, los editores sólo han tenido esos tres modos (excepto por X-char que tenía 8 bit :-). El Modo 7 todavía no es manejado por ningún visualizador (excepto en un pequeño programa en BASIC que escribí con el único propósito de descubrir esos modos). Los últimos dos modos 8x12 son irregulares, pero podrían ser fácilmente manejados por los visualizadores si alguien tan sólo lo hiciera. Visualizador: Autor: Modos: Nagav L. Bontes 1 2 4 El más rápido X-char Planet X 1 2 4 8 Confuso Visor Lord Esnes 1 2 4 Lento SMC-Ripper Magnus Runesson 1 2 3 4 8 Excelente GUI y fácil para editar SpriteView FDwR 1 2 3 4 7 8 Buenas características para encontrar tiles Todos esos visualizadores están disponibles en la red. Puede que haya otros con los que simplemente no me he topado. No hay opciones de edición en SpriteView, sólo visualización, ya que su propósito es descubrir nuevos modos gráficos. Si quiere editar tiles, pruebe alguno de los otros visualizadores. 5. -- Problemas al encontrar sprites -- Los programadores usan una variedad de técnicas para ahorrar espacio (sólo tienen un máximo de cuatro megabytes para meter sus intros) y ya que los gráficos usualmente usan la mayoría del espacio, sacarán toda clase de astutas formas de hacer que 'mucho quepa en poco'; la mayoría son cosas que nunca se me había ocurrido. Tristemente, esas 'maravillosas' técnicas de compresión hacen difícil para nosotros encontrar/editar las imágenes, así que algunas de ellas se explican abajo. -- Reducción Simétrica -- Cualquier objeto simétrico es igual tanto en un lado como en el otro, así que ¿por qué no almacenar solamente el lado izquierdo (o el derecho) y luego voltear una copia de éste para hacer su otra parte? Esto también trabaja con objetos simétricos verticalmente. Algunos objetos pueden incluso ser simétricos por su radio y necesitar ser virados en cuatro direcciones para completar una pieza. Así que no se moleste en buscar dónde está el otro lado cuando un objeto parece estar cortado por la mitad, o sólo un cuarto. Cuando usted edita un lado, también afecta el otro (o los otros). Pruebe con Mario Allstars en 1696783 con un ancho (*with a wrap width*) de 1 para que vea un ejemplo de medios tiles. -- Llenamiento de tiles (*Tile crowding*) -- Esta técnica hace uso del espacio vacío, tiles duplicados, o tiles de un único color sólido almacenando otros tiles ahí. Eso significa que usted puede encontrar piezas de un sprite dentro de otro. No hay nada que usted pueda hacer al respecto, sólo recuerde que esa es la razón de que los tiles se vean tan enredados. Usted puede ver un poco de esto en AllStars en 1663503. -- Eliminación de filas (*Row stripping*) -- Similar al agrupamiento de tiles, en vez de almacenar una imagen rectangular completa de una imagen de forma irregular, sólo las secciones significativas son almacenadas. La mayoría de las veces, las imágenes son mantenidas como un todo en su marco rectangular por simplicidad, pero cuando se vuelven demasiado grandes, el espacio en blanco a los lados del objeto empieza a ser considerable, así que simplemente no se almacena. Si un objeto es ancho en la parte de arriba, se almacenan tiras lo bastante largas para almacenar toda esa fila de tiles. Luego, conforme el objeto se vuelve más delgado hacia su base, la longitud de las tiras se vuelve más corta y cercana entre ellas. Usted puede ver mucho de esto en DKC (revise 289483), y es bastante fastidioso. Para ver las imágenes como se supone que deben verse, simplemente necesita cambiar el ancho de la envoltura hasta que las tiras se queden alineadas (extrañamente, ninguno de los visualizadores existentes manejaban esto). -- Compresión de Color -- La compresión de color ya fue explicada más arriba, pero simplemente quería mencionar que, debido a que lo que está almacenado (excepto en modos de 8 bits) son en realidad índices de color en vez de valores RGB, los colores se verán todos mal al visualizar imágenes. Realmente ayuda cargar la paleta correcta y verlos en sus verdaderos colores. La mayoría de las veces, hace más fácil el encontrar imágenes. Usted puede obtener la paleta de colores de cualquier imagen en el ROM simplemente jugando el juego y exportando una captura de éste a un archivo PCX (GIF's no sirven porque cambian el orden de la paleta de colores). Los juegos cambian dinámicamente sus paletas conforme el jugador se mueve de la pantalla de tiles a la pantalla de mapa, del nivel acuático al nivel del desierto, así que asegúrese de hacer una captura de la escena a la cual pertenece la imagen deseada. Al momento en que se escribió este documento, ningún visualizador podía cargar paletas de capturas, ¡pero SMC-Ripper lo hará pronto! -- Bitplanes desfasados -- Esta no es una técnica de compresión, pero es comúnmente un problema. Cuando la posición del byte base no está alineada al primer bitplane de la fila 0, los bitplanes quedarán desfasados. Eso significa que el bitplane incorrecto estará al frente y, debido a que el tile inicia en un lugar incorrecto del patrón, todas las imágenes se verán medio raras - sprites con colores invertidos, parte de un sprite mezclado con el otro. Puede que logre ver la figura del objeto, pero habrá algo que no está bien. Para arreglarlo, simplemente ajuste la posición del byte base (*mueva el offset*) hasta que se vea bien (lo que significa que los bitplanes están en fase y que el patrón inicia en la fila correcta). Para la mayoría de los visualizadores, las teclas '+' y '-' son usadas con este propósito. Algunas veces encontrará datos que parecen gráficos, pero es en realidad otra cosa. Puede que lo esté viendo en el modo incorrecto, o que los bitplanes estén fuera de fase, pero también hay otras estructuras de datos repetitivas en los ROM's que podrían estar confundiéndolo. Las cosas más comunes que usted podría estar viendo son los esqueletos de los niveles. Aún así, quién sabe, tal vez usted está viendo un nuevo modo y simplemente no lo sabe. 6. -- Agradecimientos, créditos y fuentes -- Esto debió explicar suficiente sobre gráficos y formatos de tiles para satisfacer a los más curiosos de ustedes, e incluso dice suficiente como para hacer su propio visualizador si quiere. Si quiere escribir un visualizador y tiene cualquier pregunta, o tiene modos que no estaban aquí, por favor envíeme un correo. Por favor, envíe sus preguntas sobre cómo trabaja el SNES, cómo usar cualquiera de los editores de sprites listados arriba, o cualquier otra cosa a las personas correctas. :-) ¿Por qué rayos me senté y me puse a escribir este largo documento (*y yo a traducirlo*)? Porque me encanta el SNES y sus juegos, y quiero añadir mis personajes favoritos a mis propios juegos o divertirme modificándolos en su propio juego. Esto fue escrito para cualquiera que quiera hacer lo mismo. Esta versión servirá por un tiempo, pero tan pronto como sean descubiertos otros modos, me aseguraré de añadirlos a una futura versión. ;-) Estas son algunas personas que, sin saberlo, ayudaron a este documento: Yoshi por sus informativos documentos sobre todos sobre el SNES Dax por la útil, pero poco exacta, información sobre formatos de pantalla Corsair+Kari por el modo 4bpl del SNES Pan/Anthrox por la información del GameBoy VileWrath por escribir el sencillo código fuente de BASIC Realmente no entendía los bitplanes hasta entonces Savoury Snax por explicar cómo un modo de bits se convierte en otro David Timko por su documento sobre tiles 8x12 Magnus Runesson por hacer su SMC-Ripper A todos los que hicieron un visualizador de tiles y a los que escribieron un documento A todos ustedes que les interesó leer (y espero que aportar a) este documento Muchas buenas fuentes para encontrar más información o para conseguir utilidades: Emulation Programmer's Resource - documentos sobre varios sistemas http://classicgaming.com/epr/ SMC-ripper's official homepage - El mejor visualizador de tiles http://home.bip.net/magnusr/ EMU News Service - las últimas noticias sobre emulación http://members.aol.com/emunews/ SNEeSe HomePage - códigos bastante buenos para un emulador http://www.fortunecity.com/olympia/baberuth/24/index.html SNES Designers, developers corner - muchos documentos sobre el SNES http://emureview.ztnet.com/developerscorner/index.htm Node99 System Documents - documentos sobre varios sistemas http://mana.simplenet.com/node99/docs.html SNES Programming - documentos http://members.pgonline.com/~gau/snes.html Alamak! SNES Emulation! Generation EX - documentos http://www.alamak.com.sg/freehome/Singapore/SNES/ SNES File Library - utilidades http://ets.simplenet.com/snes/files.html Patent Pending: Utilities: Super Nintendo - utilidades http://netside.simplenet.com/pp/emulators/utilities/snes.html NES Emulator Documents - documentos sobre el NES http://ets.simplenet.com/snes/texts.html Anime SNES Roms - para esos raros ROM's Japoneses http://www.gate.net/~mamo/animesnes.htm Welcome To The Snes Emulation Centre - documentos http://freespace.virgin.net/cm.wright/ ftp://teeri.oulu.fi/pub/console/nintendo/ - mi primer sitio de documentos Zophar's Domain - documentos http://zophar.internexus.net/ Harry Mulder's Gameboy Development - documentos sobre el GB http://home.worldonline.nl/~hpmulder/gb/main.html Jeff Frohwein's GameBoy Technical Page - documentos sobre el GB http://fly.hiwaay.net/~jfrohwei/gameboy/home.html The Holy Sector of Nintendo Emulation http://www.alabanza.com/mercuryz/Nes.html The SNES HQ http://www.northcoast.com/~mbruce/ Algunos links pueden ser viejos - no los he revisado todos. Sólo revise todos los sitios, cada uno es bueno y tiene un poquito que otros puede que no tengan. Para comentarios, correcciones o aportes: FDwR@hotmail.Com (Frank Dwayne) *Traducido por Magimaster 2 (magimaster_2@yahoo.com)*