Impresión de sprites Knight Lore

[Gandulf]

Hola:

A partir del artículo de Íñigo Ayo con respecto a la forma en que están los gráficos de knightlore invertidos, la explicación es válida para la forma de usar la pila para acelerar la impresión de sprites, pero mirando el pantallazo que pone en el debugger, no se corresponde con lo que está haciendo. No he tenido tiempo a mirar toda la gestión de sprites, ni siquiera una parte, pero desde luego la rutina que se ve efectivamente forma parte de la impresión de sprites, lo he comprobado, e invierte tiempo (tanto en esas como en otras zonas cercanas de código) en invertir bytes sin sentido alguno.

Si alguien tiene tiempo que mire en la zona $D7AE y adyacentes (y no digamos la rutina previa). Parece como si las rutinas estuvieran invirtiendo bytes porque hayan sido almacenados de una forma especial. ¿Quizá algún sistema para evitar el ripeo de sprites o complicar la vida a los que quisieran tocar o cambiar cosas?

Me gustaría tener más tiempo ahora mismo para mirarlo a fondo y ver el sentido de esa negación de bytes, pero al menos en un par de días no puedo echarle otro vistazo.

¿Alguien lo ha mirado antes o ya sabe el motivo?

[Gandulf]

Tras echarle un ojo al documento de Ricard Galvany (pdf sobre su remake de knight lore) y a otros sitios, la explicación que se da es que a cada byte de la máscara se le hace un CPL, porque no se guarda invertida. A mi no me cuadra. ¿Qué sentido tiene almacenar la máscara de forma que tengas que invertirla en cada byte de impresión para poder usarla? Entiendo que puede ser por algún tipo de rutina o utilidad que se hicieron y que generara máscaras de forma automática (lo dudo), pero qué sentido tendría en todo caso, guardarlas luego de esa forma y sobre todo, no invertirlos ya en caso de no tomarse la molestia de hacerlo antes, una vez cargado el juego.

Es meter una carga absurda en la rutina de impresión.

Yo diría que tiene que haber otro motivo, sería ridículo hacerlo porque sí y más en una rutina tan costosa como la impresión con máscara de un sprite.

[climacus]

He estado echando un vistazo y la verdad es que las técnicas de programación (a priori) dejan un poco que desear.
Evidentemente estamos hablando de los pioneros en esta clase de juegos, por lo que no les quito méritos en absoluto.
Pero no tiene nada que ver con Head over Heels, por ejemplo.

Como dices, la rutina de sprites podía estar mucho más optimizada (a no ser de que se me escape algo).
La rutina del volcado del sprite a la pantalla real tampoco es muy allá.
Ese cúmulo de circunstancias hace que en determinadas pantallas el juego se ralentice mucho.
Y el tema de imprimirlo de abajo a arriba supongo que será heredado de otros juegos como el Sabre Wulf que lo hacían para burlar el parpadeo, porque no es necesario en absoluto.
Tampoco lo hacen usando la pila para dibujar en la pantalla, técnica que popularizó Joffa y que supuso otra revolución (desconozco si alguien lo hizo antes).

De todas formas, los juegos de Ultimate a los que he echado un vistazo me parecen bastante complicados de estudiar, comparados con otros de gran nivel como los de Joffa o Mike Lamb.

[Gandulf]

Ya te digo. El volcado del buffer a pantalla se podría optimizar muchísimo. Y por ejemplo, sí, vale, usa la pila para sacar datos y ahorrarse algún tiempo, pero luego lo despilfarra de manera absurda en otras partes de la rutina.

Lo de hacer un CPL en cada byte de los sprites es totalmente demencial. Vale que son 4 TS pero es que es ¡en cada byte de cada gráfico! X-)

Lo de imprimir de abajo arriba sin duda es eso, por hacerlo de la misma forma que antes, pero no tiene sentido cuando están usando un buffer intermedio. ¿Quizá en las primeras versiones iba directamente a pantalla?

El código está super-liado y enmarañado, como realizado a través de bastante tiempo, añadiendo cosas. Da la sensación de haber sido improvisado, sobre todo el tema de las máscaras, y una vez estuvo operativo, no se molestaron en re-escribirlo, y así quedó.

Yo tengo una teoría. Al principio no usaban máscaras, hacían el CPL sobre el byte del gráfico para hacer de máscara, me imagino que en las fases de prueba y desarrollo estaba así.

Me imagino que John Ritman y otros al ver el código se frotarían las manos, porque seguramente (como nos pasó a nosotros) esperaban ver un código super optimizado y difícil de mejorar en velocidad, pero la realidad es bastante diferente.

[susso]

Mmmmm.... ¿Pero como iban a hacer mascaras con CPL si hay sprites con ceros que también necesitan enmascararse?


Enviado con Tapatalk

[climacus]

Mmmmm.... ¿Pero como iban a hacer mascaras con CPL si hay sprites con ceros que también necesitan enmascararse?


Enviado con Tapatalk

Lo extraño es que metan las máscaras con ceros en las zonas transparentes, y cuando van a usarlas las hagan un CPL. Lo lógico es guardar las máscaras directamente con unos en las zonas transparentes y te ahorras los ciclos del CPL (que son muchos).

[susso]

Espera... ¿es posible que esos CPL están porque justo en ese momento que se captura la rutina es porque ciertos sprites están flasheando? Por ejemplo, en las opciones del menu principal, en la selección de control.


Enviado con Tapatalk

[susso]

Ahora.... A ver cómo narices invertimos todos esos Sprites porque el sevenUp no lo hace, mmmm habrá que hacer una rutina que los invierta.


Enviado con Tapatalk

[Kyp]

Es esta web tienes los sprites de varios juegos de Ultimate y otros: http://www.icemark.com/downloads/index.html
De ahí saque los gráficos para mi remake del Sabrewulf.

[susso]

No, si no quiero rippear graficos, sino sacar los datos invertidos a partir de los que haga yo. Porque el sevenUp no tiene esa opción de sacarlos por orden -Y y de chars de derecha a izquierda en X


Enviado con Tapatalk

[susso]

He hecho un pequeño programa con Python para invertir y probar este sistema de ultimate. Teneis que exportar los sprites hechos con SevenuP a BINARIO con las máscaras habilitadas y en "output options" poner el byte short Priority por este orden: mask, char line, Y char y frame number, marcar mask before graph. Marcar GFX solo. NO HABILITAR ATRIBUTOS O NO FUNCIONARA EL PROGRAMA.

Para convertir los gráficos a la forma inversa como las de ULTIMATE ejecutad la utilidad desde la línea de comandos así: MDI.exe archivoaconvertir archivoconvertido por ejemplo: MDI.exe sprite.bin invsprite.bin

El programa lo que hace es recibir el bin que esta configurado así:
Sprite.bin
Byte0mask,byte0sprite,byte1mask, byte1sprite.........

Y convertirlo en esto:
Invsprite.bin
.......................byte1mask,byte1sprite, byte0mask,byte0sprite.

Lo podéis descargar de aquí:
https://www.dropbox.com/s/edpc2xzftp7pn5n/MDI.rar?dl=0


Enviado con Tapatalk

[climacus]

Yo hice una prueba rápida con el Sprite del prota. Lo que pasa es que como la distribución del juego está denegada, no he seguido. Pero la optimizacion del juego en cuanto a velocidad no es muy complicada. Mirando por ahí, he visto que en Hydrofool pasa lo mismo. Meten las máscaras invertidas y hacen el CPL (?????). Lo que pasa es que el código está mucho más optimizado y el juego va muy fluido siempre.

[susso]

Me da la impresión que no se desarrollaba en la maquina original y por el cross compiling dejaba los CPL según la maquina versionada.
O le hacia el favor al grafista para no liarse con mascaras invertidas. Puede ser. Pero es de lo mas estupido, no se me ocurre otra. Para Amstrad seria inviable.


Enviado con Tapatalk

[Gandulf]

Que también ocurra lo mismo en el Hydrofool es raro X-), que digo raro, es demencial.

Uno de los primeros juegos en usar máscaras en spectrum creo que fue el Everyone's a Wally. A ver si le hecho un ojo para ver si trabaja de la misma forma. A veces la gente hace las cosas no por lógica sino porque se estaban haciendo así antes, pasa mucho (demasiado) en las empresas de software, y luego uno pregunta porqué se está haciendo así y nadie tiene una buena respuesta.

No creo que se trate de algún tipo de entorno de desarrollo multiplataforma. Los ports del juego eran para Z80, pero yo creo haber leído que los Stamper desarrollaban sobre spectrum, además era una época muy incipiente, yo creo que no se estilaba todavía este tipo de inventos.

Sea como fuere, lo que está claro es que están malgastando 4 ts en cada byte de sprite, no es que sea para rasgarse las vestiduras, pero al no haber una explicación lógica, tiene que haber algún tipo de explicación no lógica (manías del grafista o imposiciones del grafista, herramienta para generar máscaras, etc)

Además hay otras rutinas raras en este juego, no es lo que uno espera ver en un juego comercial, y desde luego no se ven estas ñapas en otros juegos de programadores destacados.

[susso]

También me parecen muy extraños los BC esos, no parecen usarse como contador, sino como punteros de memoria al no poder hacer PUSH por tener ocupada la pila. Mmmmm...


Enviado con Tapatalk