search

Samuel85 / Abbey

Modern implementation of the classic spanish game: "La abadía del crimen" or "The Abbey of Crime", for Linux, RG350, PS Vita, and Android.
20 stars 3 forks source link

xbr and hqx graphic filter #3

Open luzbel opened 3 years ago

luzbel commented 3 years ago

Take a loot at this branch with experimental features to improve graphics in newest displays https://github.com/luzbel/VigasocoSDL/tree/xbr

Samuel85 commented 3 years ago

Could you provide me a screenshoot of this effect?, sounds interesting.

luzbel commented 3 years ago

https://twitter.com/VigasocoSDL/status/1163459741793816576?s=20

Samuel85 commented 3 years ago

hola Luzbel, veo que también hablas español. Luce muy bien el juego con el filtro xbr + hqx, pero veo algunos errores gráficos en el contorno de los ladrillos. No he visto la implementación, pero esas imperfecciones me hacen pensar que el filtro es aplicado a la escena final, lo que no es muy ideal para consolas portátiles. Creo que lo ideal sería sacar las texturas fuera de la rom para poder mejorarlas con algún filtro como este y evitar post procesamiento.

luzbel commented 3 years ago

Efectivamente se trata de filtros típicamente usados en los emuladores tipo MAME. Si la portátil no tiene suficiente potencia y no quieres aplicar post-procesado, puedes modificar los tiles. El código original de Vigasoco interpretaba la información del volcado del disco original CPC (a todos los efectos, la ROM), pero en VigasocoSDL, al incorporar los gráficos mejorados del remake de Antonio Giner, las texturas están sacadas a los archivos GraficosVGA y GraficosCPC (se mantiene el formato usado en el remake de Antonio Giner). En realidad, más que texturas debemos hablar de tiles. En cualquier caso, aunque el formato de los archivos es binario, no hay mucha dificultad para editarlos con Gimp abriendolos como raw , pasando los offsets correspondientes y cargando a mano la paleta. Alguna vez he tocado, burdamente, algún gráfico para hacer la gracia https://twitter.com/UCZ443/status/454733399836479489?s=20

Otra opción es partir de los tiles en formato más modernos. Creo recordar que el visor Java de pantallas de Manuel Pazos usaba los tiles en formato PNG. En ese caso, tendrás que cambiar todas las rutinas de gráficos de Abbey para usar esos formatos. Simplificaría mucho el código heredado de Vigasoco , que es fiel al original y donde la rutina de generación de pantalla es compleja para que entrase todo "comprimido" en 64K

Ya me dices que camino quieres seguir y te explico como editar en Gimp los tiles o donde tocar para generar las pantallas de una forma más sencilla aunque ocupando más espacio en memoria en la definición de cada pantalla.

Samuel85 commented 3 years ago

Me llama mucho mas la atención la segunda opción. No soy muy partidario de seguir usando los recursos desde la ROM y me gustaría que en un futuro se pudieran sustituir los "tiles" por otros mas detallados. ¿Por dónde me recomendarías empezar?.

luzbel commented 3 years ago

Adjunto los gráficos originales usados por Antonio Giner en su remake PC.

En el juego hay diversos elementos gráficos que se tratan de forma distinta (tiles, sprites, marcador, ...)

Yo empezaría con los tiles de las pantallas y luego, si progresas, abordaría otros elementos e iría sustituyendo poco a poco la dependencia de elementos de la ROM y de los archivos GraficosVGA y GraficosCPC (con gráficos y paleta). Cuando elimines todo podrás modificar AbadiaDriver::createGameDataEntities y otros métodos relacionados para no tener que cargar esos 3 archivos.

Empezando por los tiles, convierte los PCX en Gimp o similar a un formato en el que te sientas cómodo y carga mosaico y noche al inicializar el juego en una estructura en la que te sientas cómodo. Cada tile tiene 8x16 pixeles y podrías tener un array con todos los tiles del juego.

Luego modifica GeneradorPantallas::dibujaTira para que en vez de apuntar a los datos de la variable roms , apunte a los datos de tus tiles.

Ya me dices si avanzas esa parte y vemos como cambiar sprites, paletas , marcador, etc. para terminar de eliminar dependencias del volcado del disco original.

Adjunto también los png de los tiles usados por el visor Java de Manuel Pazos. Hay que tener cuidado con el color elegido para la transparencia, que igual difiere entre el GraficosVGA , los PCX y los PNG.

Graficos vga.zip tiles_cpc tiles_msx tilesRemake

Samuel85 commented 3 years ago

Me encanta el diseño del pergamino en la versión de Antonio Giner. El año pasado le escribí para preguntarle por los efectos de luz que muestra en su página, pero supongo que no revisa mucho el correo de su página del remake. ¿Sabes algo al respecto de este efecto? http://www.abadiadelcrimen.com/images/crimen19.gif

luzbel commented 3 years ago

Pues como el mismo Antonio indicaba en su página: "Y esto último es un TRUCO: no quiero engañaros, en el juego todavía no he conseguido esta iluminación, pero son mis primeros experimentos con Photoshop para ver cómo quedarían ciertos efectos de iluminación, que a mi juicio ambientarían muy bien el juego."

Lo que sí llego a tener como código aunque no llegó a liberar una versión con esos cambios es a aplicar "normales por píxel, lo que permite desplazar la posición del sol a lo largo del día, de forma que los sombreados se iluminen de forma realista en cualquier superficie." Puedes ver el resultado en http://www.abadiadelcrimen.com/img7.html Sobre éste efecto me comentaba: "Si te fijas en el fuste de las columnas verás que según el ángulo de incidencia de la luz la sombra varía."

Creo que cuando todos empezamos a tocar la abadía , siempre tenemos muchas ideas para mejorar el motor :-) Pero , paso a paso, primero cambiar los tiles para no leerlos usando un puntero ;-)

Samuel85 commented 3 years ago

Hola Luzbel, he conseguido reemplazar GeneradorPantallas::dibujaTira. Hay un pequeño detalle, las imágenes de Antonio Giner son mas bien la matriz transpuesta de los sprites en la rom (yo tampoco entiendo el porque), aunque lo he solucionado por código sería mas conveniente reordenar los tiles en los tilemaps, para que en un futuro se puedan importar las pantallas y sprites a algún editor de tiles como Tiled Map Editor, esto para poder cambiar los tiles mas cómodamente o para reescribir las escenas a 16:9.

Ahora me gustaría reescribir la parte de los sprites y marcador. Las paletas a mi parecer no son necesarias porque hay 3 tilemaps diferentes que abarcan todas las posibles paletas (día, noche y lampara) y solo hay que cambiar una variable para elegir. ¿Por dónde me recomendarías empezar para cambiar los sprites?

luzbel commented 3 years ago

Los sprites tienen más complejidad. Los monjes comparte el cuerpo y solo cambia la cabeza, hay sprites para los personajes, para las puertas, tratamiento especial para las habitaciones sin iluminar y mostrar solo si llevas la lámpara, etc.

De primeras, cargaría los sprites de forma similar a como has hecho con los tiles para tenerlos en una estructura. Luego igual modificaría Sprite::dibujaVGA para que no se acceda a roms y se acceda a la nueva estructura. Tendrías que adaptar despSrc en función de como hayas montado la estructura con los sprites.

Pero es una mínima parte, hay mucho más donde habría que tocar.

Samuel85 commented 3 years ago

Sprite::dibujaVGA solo copia un fotograma de los sprites a un bufer. Ese bufer viene de otra clase que mezcla los tiles por profundidad con los sprites. He conseguido volcar a pantalla el sprite que va al bufer, pero al visualizarlos de forma continua no me aparecen algunos fotogramas intermedios.

¿Me podrías explicar como ver el contenido de la rom en GIMP?, para ver los sprites .

luzbel commented 3 years ago

Sprite::dibujaVGA solo copia un fotograma de los sprites a un bufer. Ese bufer viene de otra clase que mezcla los tiles por profundidad con los sprites. He conseguido volcar a pantalla el sprite que va al bufer, pero al visualizarlos de forma continua no me aparecen algunos fotogramas intermedios.

Si, como te comentaba, hay que tocar en muchos otros sitios.

¿Me podrías explicar como ver el contenido de la rom en GIMP?, para ver los sprites .

Al abrir con Gimp , en vez de que autoseleccione el tipo de archivo, seleccionas en "Select File Type" el tipo "Raw Image Data" y eliges el GraficosVGA (o GraficosCPC) Eso te abrirá una segunda ventana en la que:

(*) Personajes:

Por ejemplo, si miras en Guillermo.cpp tienes Personaje::DatosFotograma Guillermo::tablaAnimacion . Por ejemplo, usamos el offset 57240 , para el ancho multiplicamos por 4 el siguiente valor de la tabla y para el alto el último valor de la tabla Otra animación de Guillermo, por ejemplo, la de offset 54480 es de 20x34

Tienes tablaAnimacion también para Adso

Para los monjes hay que tener en cuenta que el sprite del cuerpo es común y solo le cambia la cabeza. A ver si saco luego un rato y te paso los datos.

Para puertas: Ancho y alto lo sacas de core/abadia/Juego.cpp cuando inicializa // sprite de las puertas for (int i = primerSpritePuertas; i < primerSpritePuertas + numPuertas; i++){ sprites[i] = new Sprite(); sprites[i]->ancho = sprites[i]->oldAncho = 0x06; sprites[i]->alto = sprites[i]->oldAlto = 0x28; } Recuerda multiplicar el ancho por 4, así que tienes que son 24x40 El offset lo puedes ver en Puerta::notificaVisibleEnPantalla sprite->despGfx = 69708 + 120305*despOrientacion[oriPuerta][7]; // VGA // 69708 es la posicion de la puerta dentro de GraficosVGA // 120305 es el desplazamiento entre el grafico de la puerta y su // grafico "flipeado"

Los objetos son de 16x12 y su desplazamiento lo tienes en la variable despObjetos en core/abadia/Juego.cpp Un poco más abajo en ese código puedes ver como inicializa su ancho y alto a 16x12 sprites[i]->ancho = sprites[i]->oldAncho = 0x04; sprites[i]->alto = sprites[i]->oldAlto = 0x0c;

MARCADOR

Dígitos (Ver Marcador::dibujaDigitoDia): Las letras en número romano del día son de 8x8 V offset 72108 I offset 72172 ( el 72108 más los 64 bytes de los 8x8 del número anterior) Hay también un juego de 8x8 de pixeles negros en el offset 72236 para cuando necesitas "borrar" un digito escrito antes

Marcador (Ver Marcador::dibujaMarcador) Offset 0xB200 (45568) y 256x32

luzbel commented 3 years ago

Algunos recortes de ejemplo

Puerta image

Guillermo image

Otra animación de Guillermo image

Adso image

Gafas image

Samuel85 commented 3 years ago

maravilloso!!! ahora por fin entiendo las animaciones. Gracias Luzbel, ya te contaré.

luzbel commented 3 years ago

CARAS monjes , creo que son todas de 20x10

Berengario , ver Berengario::fijaCapucha con capucha offset 69308 y 69508 sin capucha offset 68108 y 68308

El resto lo puedes ver en su .h correspondiente en el constructor. Por ejemplo, en Abad.h , los offset de datosCara son 67308 y 67508 En Jorge.h, 68908 y 69108

CUERPOS monjes

los offsets están en SpriteMonje::despAnimTraje , no recuerdo si el ancho y alto variaban ¿20x23?

FUENTES

En cuanto a las fuentes que se usan en el marcador para cuando hablan los monjes, creo que no las leo del GraficosVGA y GraficosCPC y lo saco directamente de la ROM. Pero no lo encontrarás directamente en abadia.dsk en los offsets marcados en Marcador::imprimirCaracter if (caracter != 0x20){ data = &roms[0xb400 + 8*(caracter - 0x2d)]; } ya que la estructura del volcado del disco no es lineal. Por eso en AbadiaDriver::filesLoaded hay llamadas a reOrderAndCopy. Así que tras filesLoaded, podrías volcar la "rom" a un fichero externo para sacar los elementos que te faltan y quieras modificar. (Por ejemplo, paleta, las fuentes, etc. ) . Los datos de los caracteres necesarios para las traducciones (letras con acentos, dieresis, etc. ) están metidas a fuego en Marcador::imprimirCaracter y tendrás que añadir esa información a mano. Aunque creo que querías usar una fuente TrueType para estas cosas.

Samuel85 commented 3 years ago

hola Luzbel, estoy muy cerca de reimplementar la parte de los sprites, pero tengo un problema. No se donde dibujarlos en pantall ya que están en un buffer y las funciones que hacen eso tienen parámetros que no son muy descriptivos y no entiendo que hacen. ¿Sabes algo al respecto?

luzbel commented 3 years ago

¿de qué funciones hablas en concreto? El motor es bastante complejo porque va intentando dibujar lo menos posible y tocar solo los pixeles que se han modificado . Es decir, primero se pinta la pantalla y conforme un Sprite se mueve, se redibuja el fondo por donde estaba para dejarlo igual que al principio y mezcla el fondo con la nueva posición del Sprite.

Pero si me pasas el nombre de alguna función concreta intento ayudarte.