|
oaby
|
 |
« : 13 de Febrero de 2007, 10:17:26 pm » |
|
Hola, necesito dibujar un mapa en pantalla, yo sé que BASIC incluia en la intruccion DRAW un "lenguaje" para definir la ruta que se quería dibujar. ¿hay algo similar en asm? ¿o se define de otra forma? ¿sería más eficiente definir el mapa en un fichero independiente, con alguna compresion (tipo RLE), y luego cargarlo? Aün peinso en el Z80 como si fuera para un PC, y no tengo el chip de "no hay recursos, copón!" metido en la cabeza  |
|
|
|
|
En línea
|
|
|
|
|
jltursan
|
|
« Respuesta #1 : 13 de Febrero de 2007, 11:15:25 pm » |
|
Pues depende de lo que entiendas por "mapa", ¿de que se trata exactamente?. Me explico, si lo que quieres es: 1) Presentar un auténtico mapa, como quien muestra el mapa de un tesoro en una isla  Si el gráfico es complicado y tiene mucho detalle; pues como dices, igual te conviene almacenarlo como mapa de bits y comprimido (un mapa de bits completo en MSX1/SC2 ocupa 12Kb, 6Kb para las formas y 6Kb para el color). Si has leido ya información acerca del VDP habrás visto que realmente los gráficos no son "bitmapped" al estilo clásico (cada grupo de bits determina el color de un pixel); si no más bien "bitplanned" con las formas y los colores en dos planos distintos superpuestos. 2) Dado un mapa de pantallas, quieres presentar una de las pantallas. En este caso no podrás almacenar las pantallas completas ni aun comprimiéndolas, tendrás que utilizar una técnica de "tile mapping", también utilizada en PC  , y volcar la pantalla componiendo el mosaico de "tiles" en pantalla. Supongo que se tratará del primer caso. Tú ten presente que la mayor parte de las técnicas usadas en PC pueden ser usadas en el MSX, ten en cuenta que no es lo mismo almacenar un gráfico con 16 colores y restricciones que otro de 16 millones de colores. En MSX tienes menos recursos; pero también necesidades mucho menores. De todas formas si quieres ahorrar a tope, intenta aplicar la fórmula de los "tiles" a todo. Si el mapa tiene zonas que son iguales, igual es más práctico trozearlo procurando que aparezcan trozos iguales y usar esos trozos para componerlo con el menor gasto posible. Respecto a la compresión más efectiva disponible sobre MSX, posiblemente sea el "bitbuster" que usa un algoritmo de compresión LZ. La descompresión no permite su uso en tiempo real; pero merece la pena vistos los resultados. |
|
|
|
|
En línea
|
Doom dee doom dee doom
|
|
|
|
oaby
|
|
« Respuesta #2 : 13 de Febrero de 2007, 11:40:24 pm » |
|
Efectivamente, se trata del primer caso... pero tampoco descarto el segundo del todo... Verás, me planteaba cómo sería un llevar a cabo un mapa tipo "Defenders of the Crown", en principio es un gráfico sencillo pero creo que consume bastante. Usar mapas tileables tampoco lo descarto del todo, bastaría ver hasta qué calidad de mpa quiero obtener... Mmm, creo que será mejor usar un gráfico comprimido. Veré las dos formas, a ver qué me resulta más eficiente
|
|
|
|
|
En línea
|
|
|
|
|
pitpan
|
|
« Respuesta #3 : 14 de Febrero de 2007, 01:06:51 am » |
|
Pues si lo que pretendes es usar un pantallazo completo (imagen de 256x192), lo más cómo es usar PCX2MSX, que es una utilidad un poco desastre pero para estas cosas funciona bien. Así tendrás dos ficheros de 6 KB, uno para patrones y otro para colores. A continuación puedes optar por: (a) Incluirlo a saco: ya sabes, se te van 12 KB de un plumazo. (b) Usar compresión básica: RLE, por ejemplo, con RLEpack. Adecuado para imágenes bastante planas. (c) Usar compresión tipo Huffman: BitBuster. Bájate el asMSX y échale un vistazo a los ejemplos incluidos, porque utilizan la opción (b) bastante a menudo. La última versión del asMSX está disponible en http://www.robsy.net/asmsx012f1.zip |
|
|
|
|
En línea
|
|
|
|
|
Jon_Cortazar
|
|
« Respuesta #4 : 14 de Febrero de 2007, 09:56:01 am » |
|
Si a dibujar un mapa con DRAW te refieres a hacer un trazo con el borde exterior de un mapa, pues esto realmente no existe (de forma directa) en ensamblador (lo mismo para dibujar pixels, lineas, circulos, etc...). Efectivamente puedes: 1. volcar la imagen a VRAM a saco (12KB baby!. Lo único es que, depende de la complejidad de la imagen, si comprimes los datos puedes reducir bastante esa cantidad). Esta opción es la más basta de todas y la que se usa cuando sobra sitio por todos los lados. Es la opción más rápida y la que lleva menos curro. 2. si tan solo es un trazo (relleno o vacío, me da igual) y un par de elementos dentro del mapa, incluso una tipografía para marcar los nombres de las zonas, sin duda la mejor opción es definir las tiles necesarias, y una vez definidas, colocarlas debidamente en la tabla de nombres. Para ambas cosas necesitas saber que direcciones de VRAM atacar para volcar colores, gráficos y mapa de nombres... si quieres echar una mirada a cómo funciona SCREEN 2, cómo colocar un dibujo (en este caso un logotipo), paso a paso, echa un vistazo por favor a este thread, que tal vez te resulte interesante. |
|
|
|
|
En línea
|
Jon Cortázar Abraido (aka El Viejo Archivero) RELEVO Videogames [Dioniso: La cafeína está haciendo su trabajo; yo espero hacer el mío.] [pitpan: Me sigue pareciendo más productivo jugar al SNAIL MAZE que seguir esta discusión.] |
|
|
|
burguera
Visitante
|
|
« Respuesta #5 : 14 de Febrero de 2007, 10:12:01 am » |
|
Unas pequeños comentarios: "bitbuster" que usa un algoritmo de compresión LZ. La descompresión no permite su uso en tiempo real; Depende de como de rápido se necesite la descompresión. En pruebas que he hecho, he llegado a descomprimir 4KB cuando el jugador pasa de una pantalla a la siguiente sin que apenas se note (para mi que menos de un segundo). Cuando digo 4KB me refiero a que los datos sin comprimir ocupan 4KB, claro. (Los datos eran de un PT3, música, con lo que no necesitaba pasarlos a VRAM después). Para mi que bitbuster puede ser usado durante el juego en la mayoría de casos sin que se note. Eso, claro, usando el descompresor "original" que necesita descomprimir en RAM. La versión que pasa a VRAM usando un solo byte de RAM tarda más, aunque no la he probado. si quieres echar una mirada a cómo funciona SCREEN 2, cómo colocar un dibujo (en este caso un logotipo), paso a paso, echa un vistazo por favor a este thread, que tal vez te resulte interesante. Wink Pues no conocía yo este hilo. Que cosas teneis en el foro  |
|
|
|
|
En línea
|
|
|
|
|
Jon_Cortazar
|
|
« Respuesta #6 : 14 de Febrero de 2007, 10:17:22 am » |
|
Depende de como de rápido se necesite la descompresión. En pruebas que he hecho, he llegado a descomprimir 4KB cuando el jugador pasa de una pantalla a la siguiente sin que apenas se note (para mi que menos de un segundo). Cuando digo 4KB me refiero a que los datos sin comprimir ocupan 4KB, claro. (Los datos eran de un PT3, música, con lo que no necesitaba pasarlos a VRAM después). Para mi que bitbuster puede ser usado durante el juego en la mayoría de casos sin que se note.
Yo creo que a lo que se refiere Jl es a descomprimir cada frame alguna cosa (vease gráficos, por ejemplo). Eso no podría hacerse sin perder mogollón de tiempo de cpu en el mero hecho de descomprimir, es decir, por ejmplo: en cada frame en que cambie el gráfico del personaje, descomprimir los gfx de sus sprites en tiempo real... ahora bien, para lo que tu comentas, como por ejemplo, poner en RAM una pantalla nueva a la que el personaje acaba de acceder en un juego pantalla a pantalla, o cargar una música nueva, o cargar un nuevo set de patrones porque vamos a cambiar de escentario, etc... no importa perder unos cuantos frames por el camino. |
|
|
|
|
En línea
|
Jon Cortázar Abraido (aka El Viejo Archivero) RELEVO Videogames [Dioniso: La cafeína está haciendo su trabajo; yo espero hacer el mío.] [pitpan: Me sigue pareciendo más productivo jugar al SNAIL MAZE que seguir esta discusión.] |
|
|
|
nerlaska
|
|
« Respuesta #7 : 14 de Febrero de 2007, 10:23:32 am » |
|
Por si vale como información.
En MonsterHunter cada vez que cambias de pantalla .. se descomprime: música, mapa, tiles y sprites.
Con BitBuster.
Si veís el juego, podéis echar un ojo al tiempo que puede suponer todo esto. Según en que casos esto puede ser muy lento y en otros pues no suponer nada en absoluto.
|
|
|
|
|
En línea
|
|
|
|
|
burguera
Visitante
|
|
« Respuesta #8 : 14 de Febrero de 2007, 10:27:36 am » |
|
Yo creo que a lo que se refiere Jl es a descomprimir cada frame alguna cosa (vease gráficos, por ejemplo). Eso no podría hacerse sin perder mogollón de tiempo de cpu en el mero hecho de descomprimir, es decir, por ejmplo: en cada frame en que cambie el gráfico del personaje, descomprimir los gfx de sus sprites en tiempo real... Ah, vale Yo es que ya doy por supuesto que esas cosas no hay que hacerlas en MSX. |
|
|
|
|
En línea
|
|
|
|
|
Jon_Cortazar
|
|
« Respuesta #9 : 14 de Febrero de 2007, 10:36:28 am » |
|
Malaika, por ejemplo, cada vez que empieza una pantalla, descomprime todos los gráficos, la música y el mapeado . En mi caso se notaba un pelín, pero para estas situaciones el tipico mensaje de entradilla de pantalla del tipo "STAGE 1-1" y demás suele ser muy útil para camuflar estos momentos muertos |
|
|
|
|
En línea
|
Jon Cortázar Abraido (aka El Viejo Archivero) RELEVO Videogames [Dioniso: La cafeína está haciendo su trabajo; yo espero hacer el mío.] [pitpan: Me sigue pareciendo más productivo jugar al SNAIL MAZE que seguir esta discusión.] |
|
|
|
jltursan
|
|
« Respuesta #10 : 14 de Febrero de 2007, 10:47:48 am » |
|
De lo cual se deduce que hacer un juego es como hacer un cocido, si se te va la mano con la sal, tendrás que tirar de patatas . Muchas veces las deficiencias por culpa de la falta de velocidad o escasez de memoria se pueden camuflar como dice Jon a base de truquillos que siempre suelen estar basados en distraer la atención del jugador (alguien se acuerda/conoce la pantalla de "loading" que tenía la NeoGeoCD 1x). Si tienes en mente un juego de estrategia tipo "Defender of the Crown" (¡Bien!) no creo que tengas demasiados problemas con la lentitud de la descompresión, que igual como dicen tampoco es tan lenta |
|
|
|
|
En línea
|
Doom dee doom dee doom
|
|
|
|
Jon_Cortazar
|
|
« Respuesta #11 : 14 de Febrero de 2007, 10:56:21 am » |
|
alguien se acuerda/conoce la pantalla de "loading" que tenía la NeoGeoCD 1x
El mono malabarista? |
|
|
|
|
En línea
|
Jon Cortázar Abraido (aka El Viejo Archivero) RELEVO Videogames [Dioniso: La cafeína está haciendo su trabajo; yo espero hacer el mío.] [pitpan: Me sigue pareciendo más productivo jugar al SNAIL MAZE que seguir esta discusión.] |
|
|
|
burguera
Visitante
|
|
« Respuesta #12 : 14 de Febrero de 2007, 10:56:44 am » |
|
Muchas veces las deficiencias por culpa de la falta de velocidad o escasez de memoria se pueden camuflar como dice Jon a base de truquillos que siempre suelen estar basados en distraer la atención del jugador Pues sí que tienes razón. Ahora me doy cuenta que no he usado este "truquillo" en ciertos puntos de mi juego. Bueno, no he visto el Loading del NeoGeoCD, pero sí recuerdo los "Loading" durante el juego del Castlevania: Symphony of the Night. |
|
|
|
|
En línea
|
|
|
|
|
oaby
|
|
« Respuesta #13 : 14 de Febrero de 2007, 11:37:40 am » |
|
Robsy>> tus ejemplos en ASmsx me estan siendo muy educativos. Muchas gracias, estoy avanzando mucho con ellos! Viejo archivero>>mi intención es poner un mapa muy poco complejo, pero con lo verde que estoy no le digo que no a ningún thread, gracias! JLTursan>> Me encantan esos juegos de estrategia, he visto en MSX un par de mano de Koei, pero no me acaban de molar del todo (y no porque estén en japonés  ) No sé, me ha parecido una buena forma de aprender y al mismo tiempo motivarme a hacer algo en MSX Others>>Gracias!
|
|
|
|
|
En línea
|
|
|
|
|
oaby
|
|
« Respuesta #14 : 14 de Febrero de 2007, 11:44:28 am » |
|
Donde encuentro el PCX2MSXi? He estado buscando en la peich de maese Robsy, pero no lo encuentro  |
|
|
|
|
En línea
|
|
|
|
|
