Clonando Metal Slug en un Atari STE

Foro dedicado a la programación en todo tipo de sistemas clásicos.
masteries
Spectrum 48K Plus
Spectrum 48K Plus
Mensajes: 32
Registrado: 03 Oct 2017, 14:17
Sistema Favorito: Atari ST
primer_sistema: Spectrum +2
consola_favorita: Nintendo SNES
Primera consola: Nintendo NES/Clónica
Gracias dadas: 2 veces
Gracias recibidas: 18 veces

Clonando Metal Slug en un Atari STE

Mensajepor masteries » 12 Oct 2020, 21:20

Saludos compañer@s,

Es este foro creo que aún no había dado indicios de lo que me traigo entre manos,
programando en C y algo de ensamblador para Atari STE

Como librerías utiliza las Atari Game Tools, en contacto directo con su creador, e incluso aportando cambios y adaptaciones a las mismas.
Para el audio, se utiliza sólamente el audio digital disponible en los modelos STE. Para reproducir más de un sonido a la vez, se emplea un mezclador de audio de 4 voces que he escrito en ensamblador yo mismo... y su tela me costó manejarme con el ensamblador del 68k y no colgar la máquina cada dos por tres... :D

Para el vídeo, y de forma que se puedan apreciar más de 16 colores; se emplea una técnica para engañar al ojo humano; hay dos paletas de color alternando, una distinta para cada fotograma; corriendo a 50 cuadros esto produce un efecto de mayor colorido. Lo normal es que se alcancen entre 50 y 100 colores. Por supuesto, las dos paletas no son arbitrarias, son el producto de un algoritmo que tarda lo suyo en encontrar las paletas y recolorear los gráficos de la forma adecuada.

También todo el dibujado en pantalla es a través del blitter, y el formato de los gráficos es especial; no hace uso de operaciones bit-blit, ni máscaras. Orientado a maximizar el rendimiento.

El juego corre a 50 cuadros por segundo (en un STE normal a 8 MHz y con 4 MB de RAM); con alguna caída esporádica a 40 y muchos. Se ha implementado una técnica de frame-slipping, para repetir el cuadro anterior, si no hubo tiempo de completar el actual, para evitar que la tasa se caiga a la mitad en caso de sobrecarga, como sucede en la mayoría de sistemas retro, incluyendo recreativas.


Un vídeo en el que se incluyen todas las novedades en funcionamiento;

-El frame slipping para evitar que la sobrecargas lleven la tasa de fotogramas a la mitad.

-El nuevo driver del blitter, que optimiza aún más el rendimiento del mismo.

-Y el coloreado dualfield con dos técnicas a la vez; bicolor (se crean dos entramados en cada fotograma para mezclar dos colores) y el tricolor (en un fotograma un color se obtiene por entramado, y en el siguiente se mezcla con un único color). Como curiosidad el tetracolor no funciona, el ojo humano no mezcla esos colores, lo detecta como dos mezclas bicolores a la vez y no queda bien.
El tricolor ha permitido salvaguardar los fondos originales y extender las posibilidades también a difuminados de color, cosa que antes no se podía hacer; no queda majestuoso, pero si muy aceptable.

-En el mezclador de audio he acabado utilizando 3 canales en lugar de 4, porque rara vez estoy utilizando el canal 3; y con la CPU ahorrada puedes pintar otro sprite de 32x32

-El rendimiento está en torno a 18 - 22 sprites de 32x32 a 50 cuadros por segundo. Si los sprites son más sencillos (tienen menos huecos vacíos) o son más pequeños, pues entonces la regla de 3 funciona y puedes pintar más sprites en el mismo tiempo. Si fuesen todos sprites cuadrados, sin huecos interiores, fácilmente superarías los 30 sprites del citado tamaño.


Y ahora el vídeo, a disfrutarlo:

https://youtu.be/FMrdjrrtxWo

Avatar de Usuario
Namek
Atari 1040 STf
Atari 1040 STf
Mensajes: 871
Registrado: 11 Jul 2011, 13:13
Gracias dadas: 21 veces
Gracias recibidas: 51 veces

Re: Clonando Metal Slug en un Atari STE

Mensajepor Namek » 12 Oct 2020, 23:51

Pinta estupendo a ver si hay suerte y hacen un vídeo funcionando en un STE real... :roll:

masteries
Spectrum 48K Plus
Spectrum 48K Plus
Mensajes: 32
Registrado: 03 Oct 2017, 14:17
Sistema Favorito: Atari ST
primer_sistema: Spectrum +2
consola_favorita: Nintendo SNES
Primera consola: Nintendo NES/Clónica
Gracias dadas: 2 veces
Gracias recibidas: 18 veces

Re: Clonando Metal Slug en un Atari STE

Mensajepor masteries » 17 Oct 2020, 21:23

El mismo vídeo de antes, pero...

ejecutado en un Atari STE real con TV de tubo (viejuno), con lector de tarjetas SD conectado al puerto de joystick extendido:


Vídeo sin ninguna edición, en modo RAW xD La cámara no logra sincronizar bien del todo;
pero ahí está, porque hay quien dudaba de que fuera un STE real a sólo 8 MHz

https://youtu.be/hgW6Fc5Jli0

Avatar de Usuario
jltursan
Amiga 2500
Amiga 2500
Mensajes: 4062
Registrado: 13 Oct 2006, 19:45
Sistema Favorito: MSX
primer_sistema: Dragon
Ubicación: Serracines, Madrid, España
Gracias dadas: 62 veces
Gracias recibidas: 136 veces
Contactar:

Re: Clonando Metal Slug en un Atari STE

Mensajepor jltursan » 18 Oct 2020, 12:51

Desde luego el rendimiento es impresionante =D>

Y yo me pregunto...dado que el objetivo es un STE y que eso incluye el MegaSTE que puede correr a 16Mhz, ¿habría algún beneficio de ejecutarse al doble de velocidad o está todo demasiado ligado al blitter y no habría diferencia?

masteries
Spectrum 48K Plus
Spectrum 48K Plus
Mensajes: 32
Registrado: 03 Oct 2017, 14:17
Sistema Favorito: Atari ST
primer_sistema: Spectrum +2
consola_favorita: Nintendo SNES
Primera consola: Nintendo NES/Clónica
Gracias dadas: 2 veces
Gracias recibidas: 18 veces

Re: Clonando Metal Slug en un Atari STE

Mensajepor masteries » 19 Oct 2020, 16:52

jltursan escribió:Desde luego el rendimiento es impresionante =D>

Y yo me pregunto...dado que el objetivo es un STE y que eso incluye el MegaSTE que puede correr a 16Mhz, ¿habría algún beneficio de ejecutarse al doble de velocidad o está todo demasiado ligado al blitter y no habría diferencia?


Sí que la habría, de hecho es la CPU a 8 MHz el factor limitante. Cierto que cuando el blitter está moviendo datos, la CPU queda inhabilitada (cambia a modo maestro del Bus); pero el blitter funciona recibiendo órdenes de la CPU, y cuanto menos tiempo tardes en darle esas órdenes, más tiempo tiene el blitter para pintar.

Ese es el principal motivo de que los gráficos en el formato .emx ocupen tanto, minimizan la carga de CPU, para dárselo todo lo más masticado posible al blitter, para ahorrarle tener que hacer incluso operaciones de máscara, que aquí no las hay.

Pensad también, que el mezclador de audio a 3 voces y 12,5 KHz, está consumiendo unas 14 líneas horizontales de un total de 288. Con un 68k a 16 MHz con caché, el mezclador lo mismo se te queda en 6 - 7 líneas. Habría que saber también si la RAM va más deprisa en el megaSTE. El blitter tiene su tope, pero con una CPU a 8 MHz no puedes llegar hasta ahí; así que en el megaSTE podrías dibujar un 30% o 40 % más de sprites fácilmente.

El objetivo es el STE a secas, y mantenerse alrededor de los 50 fps; también por eso no habrá HUD; en todo caso la información necesaria se mostrará cuando lances una granada (un pequeño dibujo con el número de granadas que te quedan, y al poco desaparece), las vidas que te quedan cuando te maten... porque dibujar un HUD de forma constante, te estaría quitando sprites necesarios para mover una bestialidad como esta.

Avatar de Usuario
explorer
MSX Turbo R
MSX Turbo R
Mensajes: 319
Registrado: 11 May 2014, 17:10
Sistema Favorito: Atari ST
primer_sistema: Atari 800XL/600XL
consola_favorita: Atari 2600
Primera consola: Atari 2600
Ubicación: Valladolid, España
Gracias recibidas: 76 veces
Contactar:

Re: Clonando Metal Slug en un Atari STE

Mensajepor explorer » 20 Oct 2020, 01:40

masteries escribió:
jltursan escribió:Desde luego el rendimiento es impresionante =D>

Y yo me pregunto...dado que el objetivo es un STE y que eso incluye el MegaSTE que puede correr a 16Mhz, ¿habría algún beneficio de ejecutarse al doble de velocidad o está todo demasiado ligado al blitter y no habría diferencia?


Sí que la habría, de hecho es la CPU a 8 MHz el factor limitante. Cierto que cuando el blitter está moviendo datos, la CPU queda inhabilitada (cambia a modo maestro del Bus); pero el blitter funciona recibiendo órdenes de la CPU, y cuanto menos tiempo tardes en darle esas órdenes, más tiempo tiene el blitter para pintar.

El Blitter tiene otro modo de funcionamiento, que permite compartir el bus con la CPU. De esa manera, el Blitter mueve una serie de bytes por el bus, le cede a la CPU un tiempo para que acceda y ejecute unas cuantas instrucciones, y luego se lo vuelve a apropiar para la siguiente serie de bytes.

Bit 6 - Blit-Mode Register
Decides wether to copy in BLIT Mode (0) or in
HOG Mode (1). In Blit Mode (also known as cooperative),
CPU and Blitter get 64 clockcycles in turns, in Hog
Mode, the Blitter reserves and hogs the bus for as long
as the copy takes, CPU and DMA get no Bus access.


? Is there a way to make the Blitter faster in Blit-mode ?
! Yes, there is. Atari used this to speed up the Blitter in GEM
without risking to use Hog-mode:
Check the Busy-Bit. The CPU cannot access the bus and therefore
not the Busy-Bit if the Blitter is "active". If the CPU can finally
check the Busy-Bit the Blitter has "paused" and will wait for 64
clockcycles. Now if the Busy-Bit is 0, the Blitter is done and
you can leave. If not, set it to "1" manually and do a NOP.
Writing the Busy-Register will relaunch the Blitter immediatelly,
but the Blitter needs a few clockcycles to reserve the bus
(around 7), so the NOP is carried out in any case.
This gives about 90% the speed of the HOG-mode without losing
the option to execute interrupts after the next 64 clockcycles.
Here's an extract from the ST Profibook:
Loop: bset.b #7,$FFFF8A3B ;test and set Busy-Bit
nop ;do a NOP in any case
bne.s Loop ;if Busy-Bit was "1", go to Loop


http://alive.atari.org/alive6/ste3.php

Avatar de Usuario
jltursan
Amiga 2500
Amiga 2500
Mensajes: 4062
Registrado: 13 Oct 2006, 19:45
Sistema Favorito: MSX
primer_sistema: Dragon
Ubicación: Serracines, Madrid, España
Gracias dadas: 62 veces
Gracias recibidas: 136 veces
Contactar:

Re: Clonando Metal Slug en un Atari STE

Mensajepor jltursan » 20 Oct 2020, 17:30

Pero entiendo que lo que masteries busca es el 100% de la velocidad del Blitter y en el modo cooperativo se pierde un 10%. Otra cosa sería que fuese imprescindible hacer algo con la CPU en ese tiempo y entonces no quedaría otro remedio que darle una ventana a la CPU a costa de velocidad.
Todo es cuestión de ver si se gana algo al 90% de Blitter y la CPU adelantando cosas ese 10% (si algo se puede adelantar) o si al final es tontería y compensa más con el Blitter al 100% y hacer a continuación lo que se tenga que hacer a continuación.

masteries
Spectrum 48K Plus
Spectrum 48K Plus
Mensajes: 32
Registrado: 03 Oct 2017, 14:17
Sistema Favorito: Atari ST
primer_sistema: Spectrum +2
consola_favorita: Nintendo SNES
Primera consola: Nintendo NES/Clónica
Gracias dadas: 2 veces
Gracias recibidas: 18 veces

Re: Clonando Metal Slug en un Atari STE

Mensajepor masteries » 20 Oct 2020, 18:18

jltursan escribió:Pero entiendo que lo que masteries busca es el 100% de la velocidad del Blitter y en el modo cooperativo se pierde un 10%. Otra cosa sería que fuese imprescindible hacer algo con la CPU en ese tiempo y entonces no quedaría otro remedio que darle una ventana a la CPU a costa de velocidad.
Todo es cuestión de ver si se gana algo al 90% de Blitter y la CPU adelantando cosas ese 10% (si algo se puede adelantar) o si al final es tontería y compensa más con el Blitter al 100% y hacer a continuación lo que se tenga que hacer a continuación.


Lo que sé, tras probar el modo compartido; pues se configura con un "define", es que rinde bastante menos.

Por lo que se aprecia: como casi todo es dibujar, mejor dejarle tiempo al que dibuja;
que con una CPU más rápida ganas tiempo, claro; y ese tiempo lo podría usar quien dibuja, para dibujar más :D

Avatar de Usuario
explorer
MSX Turbo R
MSX Turbo R
Mensajes: 319
Registrado: 11 May 2014, 17:10
Sistema Favorito: Atari ST
primer_sistema: Atari 800XL/600XL
consola_favorita: Atari 2600
Primera consola: Atari 2600
Ubicación: Valladolid, España
Gracias recibidas: 76 veces
Contactar:

Re: Clonando Metal Slug en un Atari STE

Mensajepor explorer » 20 Oct 2020, 23:57

Efectivamente: si hemos hecho todos los cálculos de pintado, y podemos agrupar todos los 'bliteos' en una parte del proceso, pues le damos al Blitter todo el bus y que tire millas.

El modo compartido está, sobre todo, para cuando sospechamos que pueden ocurrir interrupciones mientras se hacen las operaciones gráficas (la interrupción vertical, el fin de reproducción del búfer de sonido DMA, etc.). Para este caso sirve el bucle propuesto (un simple 'nop'). Es decir, el bucle reactiva el 'bliteo' inmediatamente, salvo que haya ocurrido una interrupción, que será atendida (en bloques de 64 ciclos compartidos con el Blitter, claro). Si no hay interrupciones, el 'bliteo' llega al 90 % de la velocidad de lo que sería en modo exclusivo.

Para otros casos... en la documentación se hablaba del GEM, para evitar ver "congelamientos" en la pantalla. ¿Para qué serviría en un juego aparte de las interrupciones? Pues eso es lo que se puede estudiar. Por ejemplo, podemos dedicar la CPU para calcular el siguiente 'bliteo'.

Avatar de Usuario
jltursan
Amiga 2500
Amiga 2500
Mensajes: 4062
Registrado: 13 Oct 2006, 19:45
Sistema Favorito: MSX
primer_sistema: Dragon
Ubicación: Serracines, Madrid, España
Gracias dadas: 62 veces
Gracias recibidas: 136 veces
Contactar:

Re: Clonando Metal Slug en un Atari STE

Mensajepor jltursan » 21 Oct 2020, 18:21

...O si fuese posible, acceder simultáneamente con la CPU a RAM de video para continuar trabajando con ella en paralelo con el Blitter. Como ya digo, suponiendo que eso se pueda y que no se "pisen" trabajos mutuamente.
Es comparar peras con manzanas; pero eso es algo factible en maquinas como los MSX2, cuyo "blitter" funciona de forma paralela e indepentemente a la CPU y lo que haga esta.


Volver a “Programación”

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 4 invitados