Ver la versión completa : Cuando un Atari STE se cree una NeoGeo
masteries
12/06/2020, 15:55
Lo que sucede cuando una máquina que sólo puede mostrar 16 colores en pantalla se viene arriba...
Quería dejarlo para más tarde, para cuando estuviera más completo,
Estuve modificando el algoritmo que genera las paletas de color y te hace el dithering de los gráficos para obtener mayor colorido.
Me he basado en darle más importancia a la distancia en luminosidad que a la distancia cromática; con la intención de poder obtener colores más vivos.
El resultado me ha sorprendido tanto, que adjunto la demo de aprendizaje en la que estoy trabajando (voy aprendiendo cómo usar la librería AGT, cómo funciona el tema de las colisiones, colocar sprites, manejar el scroll...).
Se maneja con las teclas A,D,W y N para disparar. Como emulador recomiendo el Steem Engine v3.2 (build 22 Oct 2004), utilizo TOS 1.06 Española.
Por cierto, no empeceis caminando hacia la izquierda que se va a la porra; es una demo muy temprana, pero había que compartirlo.
Para que se pueda "ver bien", hay que poner el emulador en pantalla completa y activar el sincronismo vertical a 60 Hz
Necesita un Atari STE con al menos 2 MB de RAM
Dad vuestra opinión sobre qué os parece la calidad gráfica, a ver si puedo subir un vídeo que le haga justicia,
Actualizado: He subido un vídeo que de verdad respeta el cómo se ve en el STE; la técnica también es apta para un ST; salvo que habría que desactivar el scroll hardware y el blitter. Pero se vería igual.
https://www.youtube.com/watch?v=stWZTlnMLUc
y segunda parte, ya con sonido:
https://www.youtube.com/watch?v=GhcNnmMOwD8
53709
Joer, si no me dices que son 16 colores no lo habría averiguado en mi vida. El efecto hace que parezcan muchos más.
Siento no poder apreciar en toda su magnitud el trabajazo que hay detrás, porque no conozco tan a fondo esas máquinas (y la compresión de vídeo de Youtube no ayuda :D), pero sí que se nota que hay muchísimo curro detrás.
No sé si darte la enhorabuena por lo conseguido, o ánimos para poder terminarlo :D
masteries
12/06/2020, 17:00
Siento no poder apreciar en toda su magnitud el trabajazo que hay detrás, porque no conozco tan a fondo esas máquinas (y la compresión de vídeo de Youtube no ayuda :D), pero sí que se nota que hay muchísimo curro detrás.
No sé si darte la enhorabuena por lo conseguido, o ánimos para poder terminarlo :D
Es sencillo, además de probarlo en emulador de la forma que indico, para que se pueda ver bien;
coge un pantallazo de un buen juego de NeoGeo y con un programa de dibujo pásalo a 16 colores, a ver si se sigue viendo así de bien.
De momento son ejercicios para aprender a usar las librerías, probar el mezclador de audio y esas cosas.
Por lo demás, bajo mi "sabio" consejo se están introduciendo cambios en las AGT para que la forma de programar con ellas sea lo más semejante a Fénix / Bennu posible. De hecho cada sprite es una función que funciona como un proceso, jaja
También para reproducir sonidos se hace igual, dado que escribí el mezclador de audio.
Las colisiones son más avanzadas que las de Bennu / Fénix; recientemente se añadió el pixel perfect, y una forma de colisiones rectangulares fácilmente personalizables por cada fotograma de cada sprite. Y la forma inicial que sólo toma en cuenta el marco que ocupa el sprite.
Y los mapeados, admite cargar ficheros de Mappy o Tiled, o directamente leer ficheros gráficos y extraer de ahí los tiles y la composición de los mismos.
Sí, el motor de scroll tileado fué de lo primero que se incorporó a estas herramientas.
Nos queda por ver cómo usar el doble scroll. Sí, el hardware de scroll del STE se diseño para partir la pantalla en dos partes, para hacer juegos de dos jugadores mostrando diferentes partes del escenario. Estamos investigando cómo usar esto para hacer scroll parallax.
fbustamante
12/06/2020, 18:51
Como dice Drumpi, yo tampoco tengo ni idea, pero por lo que explicas se me hace un tilín en la cabeza que no veas. :)
Enhorabuena y que continuéis. :brindis:
selecter25
12/06/2020, 19:24
Impresionante, menuda pasada de curro.
romeroca
12/06/2020, 19:29
Lo cual me lleva a la siguiente conclusión ... PODRÍAN HABER ADAPTADO METAL SLUG EN EL AMIGA !!!! Perdón por la troleada.
Gran trabajo Masteseries y ganazas de ver como avanzas con esto.
Lo cual me lleva a la siguiente conclusión ... PODRÍAN HABER ADAPTADO METAL SLUG EN EL AMIGA !!!! Perdón por la troleada.
Gran trabajo Masteseries y ganazas de ver como avanzas con esto.
El problema del Amiga es que si quieres usar el blitter o sprites por hardware los tienes que poner en la chip ram y esta esta limitada (IIRC) a 1MB aunque amplies el amiga a 14MB.
Los gráficos se ven muy bien, y en un monitor CRT se tiene que ver de lujo, lo malo es si tienes el Atari conectado a un TFT... puede que no se vean tan bien ahí.
Que chulada, me parece impresionante que solo sean 16 colores!
tienes algun screenshot limpio o algo para que podamos ver de mas cerca como ha hecho el dither?
Supongo que utilizará algun truco de entrelazado, un frame con unos colores, otro frame con otros y la mezcla de ambos frames hace que 16 colores parezcan muchos más.
JoJo_ReloadeD
13/06/2020, 10:16
currazo, ya contaras como sigue el proyecto :)
masteries
13/06/2020, 12:16
Supongo que utilizará algun truco de entrelazado, un frame con unos colores, otro frame con otros y la mezcla de ambos frames hace que 16 colores parezcan muchos más.
53711
De hecho ese es el concepto. Aún así, cada paleta de 16 colores generada es por sí sola muy buena.
Pero con la complejidad de que al crear las paletas y colorear los gráficos, se tiene en cuenta cómo percibe el ojo humano los colores; de forma que no notes las dos paletas ni los píxeles por separado y en cambio se produzca una fusión de los colores. La fusión se produce en tu ojo, no en el monitor, nuestro sistema óptico no es capaz de diferenciar las dos imágenes.
En mi versión del algoritmo he dado más importancia a la luminosidad que al color; de forma que puedo obtener colores más intensos; antes no era posible dibujar un "Metal Slug" que se pareciera a la versión original de NeoGeo. La versión original del algoritmo se centraba en la distancia cromática, pero no podía mostrar colores vistosos. La versión actual del algoritmo incluye las modificaciones que he realizado, porque da mejor resultado en términos generales. Se puede considerar una actualización del método.
Me gustó tanto el resultado que he querido compartir de forma temprana la demo de aprendizaje.
En Amiga sería posible, pero con 1 MB de Chip RAM te quedas tan justo... mejor 2 MB de Chip RAM, pero eso sólo está disponible para Amiga 500 Plus y Amiga 600.
Esto ya lo han señalado; la memoria fast puede ser más grande que la Chip, pero al no ser accesible por el adaptador de vídeo no te sirve esa memoria.
En el ST normal, el método funciona igual de bien, pero no dispones del blitter ni del scroll hardware; por supuesto en ST el scroll también es a nivel de píxel, pues hay trucos para ello.
Pero no podrás mostrar muchos sprites, ni reproducir sonido mediante el mezclador de audio digital.
En Amiga sería posible, pero con 1 MB de Chip RAM te quedas tan justo... mejor 2 MB de Chip RAM, pero eso sólo está disponible para Amiga 500 Plus y Amiga 600.
Esto ya lo han señalado; la memoria fast puede ser más grande que la Chip, pero al no ser accesible por el adaptador de vídeo no te sirve esa memoria.
fixed.
¿El algoritmo para convertir la imagines mirando la luminosidad lo tienes solo tu o esta subido a la ultima versión de las AGT?
masteries
13/06/2020, 16:57
fixed.
¿El algoritmo para convertir la imagines mirando la luminosidad lo tienes solo tu o esta subido a la ultima versión de las AGT?
Ya está integrado, el switch entre una y otra modalidad depende de lo que le pidas cuando solicites generar paletas y dithering.
53711
De hecho ese es el concepto. Aún así, cada paleta de 16 colores generada es por sí sola muy buena.
Pero con la complejidad de que al crear las paletas y colorear los gráficos, se tiene en cuenta cómo percibe el ojo humano los colores; de forma que no notes las dos paletas ni los píxeles por separado y en cambio se produzca una fusión de los colores. La fusión se produce en tu ojo, no en el monitor, nuestro sistema óptico no es capaz de diferenciar las dos imágenes.
En mi versión del algoritmo he dado más importancia a la luminosidad que al color; de forma que puedo obtener colores más intensos; antes no era posible dibujar un "Metal Slug" que se pareciera a la versión original de NeoGeo. La versión original del algoritmo se centraba en la distancia cromática, pero no podía mostrar colores vistosos. La versión actual del algoritmo incluye las modificaciones que he realizado, porque da mejor resultado en términos generales. Se puede considerar una actualización del método.
Me gustó tanto el resultado que he querido compartir de forma temprana la demo de aprendizaje.
En Amiga sería posible, pero con 1 MB de Chip RAM te quedas tan justo... mejor 2 MB de Chip RAM, pero eso sólo está disponible para Amiga 500 Plus y Amiga 600.
Esto ya lo han señalado; la memoria fast puede ser más grande que la Chip, pero al no ser accesible por el adaptador de vídeo no te sirve esa memoria.
En el ST normal, el método funciona igual de bien, pero no dispones del blitter ni del scroll hardware; por supuesto en ST el scroll también es a nivel de píxel, pues hay trucos para ello.
Pero no podrás mostrar muchos sprites, ni reproducir sonido mediante el mezclador de audio digital.
estas imagenes son de uno de los lados entrelazados? o con ambos a la vez? se ve de **** madre.
masteries
14/06/2020, 11:38
estas imagenes son de uno de los lados entrelazados? o con ambos a la vez? se ve de **** madre.
Esas imágenes utilizan sólo una de las dos paletas, no sabría decirte si la paleta 0 o la 1.
Las he obtenido poniendo el emulador en pausa, se queda el cuadro congelado y entonces puedes ver la imagen con su dithering y con sólo una paleta.
Son dos imágenes complementarias, al mostrar 50 Hz o 60 Hz, pero cambiando entre una y otra, se ve como en el vídeo del primer post.
El programa que te genera estos gráficos complementarios dice que se apreciarán 77 colores distintos en este caso.
Aún así, como habéis podido ver, cada paleta de 16 colores por separado y el dithering son muy buenos por sí solos.
Esas imágenes utilizan sólo una de las dos paletas, no sabría decirte si la paleta 0 o la 1.
Las he obtenido poniendo el emulador en pausa, se queda el cuadro congelado y entonces puedes ver la imagen con su dithering y con sólo una paleta.
Son dos imágenes complementarias, al mostrar 50 Hz o 60 Hz, pero cambiando entre una y otra, se ve como en el vídeo del primer post.
El programa que te genera estos gráficos complementarios dice que se apreciarán 77 colores distintos en este caso.
Aún así, como habéis podido ver, cada paleta de 16 colores por separado y el dithering son muy buenos por sí solos.
si si. Se ve brutal. Enhorabuena.
masteries
17/06/2020, 00:50
Actualización:
Después de días de arduo trabajo, hemos podido dar con un formato gráfico que ocupa poco espacio, y empalma por sí solo las líneas que componen los gráficos; respetando los límites impuestos por el hardware blitter.
Se maximiza el uso de los sprites, de hecho se puede alcanzar una tasa de 10,2 KB en gráficos de sprites por fotograma; lo que hacen 510 KB/s de un total de 512 KB/s que tiene el blitter. Ya si añades más sprites, empieza a bajar de 50 fotogramas. Y todo esto con el mezclador de audio a 5 voces a 12,5 KHz funcionando.
¿Qué se ha logrado con esto? Poder usar sprites gigantes como este, y que ocupen poca memoria, de hecho ese monstruo mecánico gigante ocupa sólo 7 KB de RAM:
53717
Bah, eso te lo hago yo con una Raspberry :lol:
En serio, es algo impresionante. Conociendo lo que sé de los ordenadores de la época, sprites de ese tamaño son bestiales. Si encima se mueve a 50fps... me quito el sombrero :)
O sea, que si admitimos 40FPS en esa máquina ¿puedes llegar a tener la mitad de los sprites del Metal Slug en sus momentos más intensos? ¿O ya con un mastodonte de media pantalla la cosa se resiente demasiado?
Sea como fuere, cualquier cosa mayor de 32x32 se consideraba grande, y eso es como 8 veces más. ¡UAU!
platipus
17/06/2020, 16:09
53719
Leguleyo
18/06/2020, 21:38
Que pasada!!! Buen trabajo...
masteries
23/06/2020, 19:56
más actualizaciones:
Primera, se ha duplicado el número de píxeles que puedes mostrar en pantalla, ahora ya está cercano al 50% de la pantalla, manteniendo los 50 fotogramas por segundo. Se está depurando mucho el dibujado de los sprites y el redibujado del fondo; para el redibujado del fondo, en lugar de redibujar tiles completos, se está redibujando de forma poligonal. Se ahorra trabajo del blitter, y aunque hay que calcular las áreas de los polígonos, acabas ahorrando incluso trabajo rutinario de la CPU que antes se usaba para dar órdenes al blitter.
Porque el STE tiene scroll hardware, pero esos fondos no se restauran solitos; en un Amiga tampoco.
En resumen, más sprites gigantes, o más sprites medianos, o muchos sprites pequeños.
53729
Segundo, he terminado de programar la posibilidad de reproducir músicas basadas en fragmentos de sonidos que se concatenan; estás músicas de sonido digital a 12,5KHz se mezclan con el resto de las voces digitales; consumienod una sola de las voces disponibles (a elegir entre 4 y 6) y todo fácil y para toda la familia. Se construyen con partituras como esta:
1A - 1B - 4C - 2D - 2E - 3F - 1D - 2C - F1
Que significa (de izquierda a derecha): reproducir 1 vez la muestra de sonido A, al terminar reproducir 1 vez la muestra B; 4 veces la muestra C; 2 veces la muestra D... al llegar a F1, la F indica volver a la posición 1; vuelve a 1B
romeroca
23/06/2020, 20:52
Muy interesante todo lo que comentas.
Interesante la forma de restaurar los sprites.
masteries
09/07/2020, 10:52
La diferencia entre un emulador y la máquina real:
Queda claro que los emuladores recrean la experiencia, pero no recrean el hardware a la perfección; habrá que hacer debug para saber dónde están fallando los timing, debido a las últimas actualizaciones del motor gráfico,
53762
Perdonad el reflejo del monitor; está funcionando en un STE real, con conversor RGB a VGA (necesito un cable nuevo porque vaya prototipo malo que me fabriqué).
A ver si lo arreglamos y grabo un vídeo decente ingame, con sonido (tremendo el sonido calcado a NeoGeo que está saliendo de esta máquina de 1989) funcionando en el STE real.
mills332
11/07/2020, 21:47
Muy chulo, aunque nunca tuve uno original y no lo llego a apreciar del todo :). Lo voy a probar en el core que hay en FPGA de la placa mister, a ver si hace lo mismo que en la maquina original (o eso afirman los creadores, segun parece tuvieron acceso a los esquemas originales de los circuitos).
EDITADO:
Pues no se veían los sprites, por lo que sea, aun es muy nuevo ese core/simulador como se quiera llamar, pero si que se nota el efecto para darle mas colores:
53765
Cuando no hace scroll, no se nota nada, se ven todos los colores :) (mucho mejor que en la foto). Pero cuando te mueves, si se nota un poco que esta alternando, y se ven los patrones de difuminado, porque es una pantalla moderna, en una de tubo no se vería eso. (Las scanlines las añade el escalado).
masteries
13/07/2020, 10:41
Muy chulo, aunque nunca tuve uno original y no lo llego a apreciar del todo :). Lo voy a probar en el core que hay en FPGA de la placa mister, a ver si hace lo mismo que en la maquina original (o eso afirman los creadores, segun parece tuvieron acceso a los esquemas originales de los circuitos).
EDITADO:
Pues no se veían los sprites, por lo que sea, aun es muy nuevo ese core/simulador como se quiera llamar, pero si que se nota el efecto para darle mas colores:
Cuando no hace scroll, no se nota nada, se ven todos los colores :) (mucho mejor que en la foto). Pero cuando te mueves, si se nota un poco que esta alternando, y se ven los patrones de difuminado, porque es una pantalla moderna, en una de tubo no se vería eso. (Las scanlines las añade el escalado).
Para que funcione bien tienes que tener ahí sintetizado un STE 100% fiel; el motor gráfico exprime y maneja el hardware de maneras para las que no se había pensado; por lo que si la máquina emulada o sintetizada, no es capaz de tener en cuenta el comportamiento exacto de toda la máquina; puedes encontrarte fallos como ese.
Atendiendo a que el fondo si está funcionando y los sprites no lo están haciendo; el fondo está siendo dibujado por el chip blitter; el scroll lo mueve el scroll hardware y se va actualizando (fuera del campo visible) por el blitter. Los sprites también están siendo dibujados por el blitter, pero no de la forma usual (como es el caso del fondo), sino de formas raras y especializadas que minimizan el trabajo del blitter (para que puedas dibujar más sprites a la vez), de hecho en el compilado del primer post se usan dos / tres formatos de sprites, EMS, SLAB y SLAB compuesto.
Estos formatos juegan con las interrupciones que gobiernan el blitter y el scroll, y contienen instrucciones específicas para cada frame del sprite a dibujar (en la jerga los llaman sprites compilados); se vé que esta forma de jugar con el hardware no está soportada por ese core, porque no recrea al 100% el comportamiento de la máquina. Deciros que los actuales emuladores para PC tienen problemas con el STE, no lo emulan al 100%
Por otra parte, no conviene conectar una máquina que da salida de 50 o 60 Hz a un monitor / TV plano que sea capaz de mostrar más de 60 Hz; aquí se pueden dar varios casos:
1 - Que el monitor / TV te diga que está mostrando 50 o 60 Hz, pero él sólo puede dibujar a 100, 144 Hz... lo que hace en este caso, es hacer que esos 50 Hz sean 100, o 144... repitiendo varias veces el mismo cuadro; con lo que ese mismo cuadro está durando demasiado en pantalla.
2 - Que el monitor / TV te diga que está dibujando a 50 Hz, 60 Hz, y en realidad se ha configurado a 50 - 60 Hz, pero no se sincroniza con la señal de entrada, sino que dibuja la señal con un retraso de 1 frame, y está dibujando la imagen muy rápido; por lo que ésta permanece demasiado tiempo en pantalla y se percibe el truco. Son monitores / TV que podrían dibujar más rápido, seguramente en algunas resoluciones alcanzan los 75 Hz (como truco para saberlo, a 800x600 se configuran a 75 Hz), y por tanto siempre dibujan igual de rápido que si estuvieran a 75 Hz
Siempre se puede notar un poco el efecto si desplazas la vista rápidamente del centro a la esquina "de dónde venga" el scroll, si te separas más de 1 metro de la pantalla (en el caso de pantalla de 24 pulgadas), se torna bastante difícil notar algo. Pero claro, hablo de las pantallas planas que tengo que sólo alcanzan 60 Hz y sincronizan la señal.
mills332
13/07/2020, 16:15
Se ve que es muy nuevo ese core, ademas tiene problemas con monitores planos (se apagan o la imagen se ve descentrada), lo ideal es usar un conector vga a un monitor antiguo, para hacer la salida de video igual que el original, pero necesita otra placa y no la tengo. Lo de los sprites compilados es lo que hice en el motor para vga, no sabia que estos atari funcionasen de forma parecida, pense que tenian sprites por hardware.
masteries
13/07/2020, 19:56
Se ve que es muy nuevo ese core, ademas tiene problemas con monitores planos (se apagan o la imagen se ve descentrada), lo ideal es usar un conector vga a un monitor antiguo, para hacer la salida de video igual que el original, pero necesita otra placa y no la tengo. Lo de los sprites compilados es lo que hice en el motor para vga, no sabia que estos atari funcionasen de forma parecida, pense que tenian sprites por hardware.
No tienen no, lo que tienen es un chip que pinta líneas de gráficos en lugar del procesador, el blitter, pero antes la CPU tiene que darle las órdenes.
Obviamente es una ayuda muy útil, porque pinta en pantalla bastante más rápido que la CPU. Pero el mecanismo sigue siendo parecido a hacerlo todo por software, tienes que redibujar el fondo cuando los sprites se mueven... ahora estamos metidos en la harina de redibujar sólo aquello que haga falta, y progresa bastante bien.
También se ha solucionado el problema de que el fondo iba mal en la máquina real.
Por otra parte, hay un experimento para manejar el doble scroll del STE; sí, tiene un hardware de scroll que permite partir la pantalla en 2 mitades independientes, y con un poco más de truco ya existe la posibilidad de hacer un poco de parallax, aunque el parallax no da para pantalla completa, sólo para una sección. Eso sí, es un parallax casi "CPU free".
mills332
14/07/2020, 11:10
Bueno mira así he empezado a trastear con otra maquina que no conocía, seguiré probando a ver como mejora.
¿Cual es la forma más fácil de cargar programas caseros en el atari st?. Yo encontré una imagen de disco duro y tuve que pasar archivos desde una carpeta compartida en windows a esa imagen, usando el emulador steeem pero es un poco tedioso. ¿No hay manera de generar discos o acceder directamente a la imagen vhd? (el core fpga no carga zips ni tiene carpetas compartidas, necesita imágenes de disco duro o de disquetes).
masteries
14/07/2020, 19:12
¿Cual es la forma más fácil de cargar programas caseros en el atari st?. Yo encontré una imagen de disco duro y tuve que pasar archivos desde una carpeta compartida en windows a esa imagen, usando el emulador steeem pero es un poco tedioso. ¿No hay manera de generar discos o acceder directamente a la imagen vhd? (el core fpga no carga zips ni tiene carpetas compartidas, necesita imágenes de disco duro o de disquetes).
Utilizo Steem, habiendo configurado una carpeta de tu PC como directorio del disco duro del ST / STE.
Te aparecerá en el escritorio del ST una nueva unidad, el disco C:, con los directorios y la "morralla" xD que hayas metido ahí dentro en tu PC.
En el STE real utilizo disquetes; otros desarrolladores tienen discos duros físicos conectados.
De imágenes de disco y cómo crearlas, de eso ya no controlo nada.
En el STE real utilizo disquetes; otros desarrolladores tienen discos duros físicos conectados.
Pillate un SatanDisk
http://joo.kie.sk/?page_id=55
masteries
15/07/2020, 21:52
¡Viniéndonos arriba un poco más!
Funcionando en la máquina real y viéndose en una TV / monitor plano de 60 Hz,
-Se ha añadido dos funciones a los sprites; pueden titilar al detectar una colisión, o pueden parpadear. El parpadeo me encanta para cuando has eliminado un enemigo, sensación 100% arcade.
-Se ha llevado el motor gráfico y el hardware al límite; se puede mostrar la máquina mastodóntica, un par de tanques, el jugador y algunos disparos / explosiones y se mantiene entre 49 y 50 cuadros por segundo. Os podemos decir que ya no da más de sí; pero con esa cantidad de píxeles para sprites te asemejas en potencia a una MegaDrive. Te quedas un poquito por debajo, pero no demasiado lejos. Y con sonido digital a 4 voces con muestreo de 12.5 KHz, parece que estás sentado frente a una NeoGeo.
Un Metal Slug es posible.
53770
53771
53772
53773
53774
53775
La foto para los escépticos, sí es un ST/E; este mismo scroll con la técnica multicolor también funciona en ST
53776
La Asociación en Defensa de los Atari STE (ADASTE) ha recibido una denuncia por abusos y maltrato de un Atari STE por parte de un miembro de este foro, y ya lo tienen en busca y captura.
:lol:
Impresionante trabajo. También podrías bajar a 40 fps y no creo que nadie se quejase, vamos, no creo que fuese el primer juego de los 80 que se ralentizase un poco (o un mucho :D).
Pero más que un Metal Slug, yo probaría con un juego de lucha 1vs1, eso se tiene que ver de lujo con sprites tan grandes, y sólo serían 2 más los VFX.
selecter25
16/07/2020, 13:33
Majia
¿Como se hace el parpadeo? Porque dibujar el gráfico con los planos en otro orden seria 100% free pero saldría con colores raros, ¿o sale bien porque la paleta esta ordenada por intensidad (o algo así) y estas dibujando la mascara en uno de los planos?
masteries
17/07/2020, 11:41
¿Como se hace el parpadeo? Porque dibujar el gráfico con los planos en otro orden seria 100% free pero saldría con colores raros, ¿o sale bien porque la paleta esta ordenada por intensidad (o algo así) y estas dibujando la mascara en uno de los planos?
¿Como se hace el parpadeo?
El blitter puede saturar a los extremos de la paleta, o saturar hacia el color que indiques. De forma que en el siguiente dibujado del sprite, el blitter no necesitará datos gráficos, tan sólo la posición desde donde empezar y la longitud en píxeles; es mucho más rápido al no tener que acceder a memoria para transferir los datos a la memoria de vídeo, dado que esta tarea se realiza directamente sobre la memoria de vídeo. Es el dibujado de primitivas mediante el blitter. Los colores intermedios, entre el gráfico y blanco (o color elegido), se hacen con la intervención del shifter, y de esto, ya me entero más bien poco; es algo sobre utlizar la información residual del shifter y mezclarlo con la nueva entrada al DAC de salida de vídeo.
dibujando la máscara en uno de los planos?
Los formatos optimizados de sprites no utilizan máscaras, eso sólo lo utiliza el formato de sprites compatible con el ST normal. El ST normal dibuja mediante Bit Blit, el STE mediante transferencias chunky** (se comporta y se utiliza como si no fuera planar*), no hay bit blit, sólo realiza una operación de copiado a memoria de vídeo, una sola vez. Es una operación raster, con textura, pero sin necesidad de sincronía con el retrazo vertical. En cada operación el blitter toma el control absoluto del bus del sistema, hasta que no termina su operación, no se puede hacer nada más. Todas las operaciones de dibujado se encolan, "deferred rendering", para que se ejecuten todas en una sola función, se pinta línea a línea para que se puedan atender las interrupciones al término de una línea. Hay otro modo de dibujado en desarrollo, pero es un experimento demasiado temprano.
**No es la forma en la se pensó utilizar el blitter, pero maximizas el ancho de banda del mismo, porque ya es un poco pobre como para pintar más de una vez o tener en cuenta más de un dato, a parte de los datos gráficos (la textura). Quizás esta manera de usar el hardware de vídeo no está soportada en los cores FPGA y por eso no se ven los gráficos en esos sistemas, como comentaba el compañero Mills332
*Aunque la distribución de los datos es planar y lo mínimo que puede escribirse son 16x1 píxeles, porque sólo se pueden escribir los datos en múltiplos de 16 bits, 1 bit por píxel x 16 píxeles x 4 planos = 64 bytes como cantidad menor que maneja el blitter en modo gráfico. En el modo de dibujado de primitivas, no necesita leer nada de la memoria del sistema, no hay transferencia DMA de la memoria del sistema a la memoria de vídeo, sólo indicarle cuántos píxeles quieres, o incluso que superficie rectangular quieres y de qué color de la paleta. Este modo de primitivas, debería probarlo para un juego de coches... jeje porque debería dibujar primitivas bastante rápido.
-----Actualizado-----
La Asociación en Defensa de los Atari STE (ADASTE) ha recibido una denuncia por abusos y maltrato de un Atari STE por parte de un miembro de este foro, y ya lo tienen en busca y captura.
:lol:
Impresionante trabajo. También podrías bajar a 40 fps y no creo que nadie se quejase, vamos, no creo que fuese el primer juego de los 80 que se ralentizase un poco (o un mucho :D).
Pero más que un Metal Slug, yo probaría con un juego de lucha 1vs1, eso se tiene que ver de lujo con sprites tan grandes, y sólo serían 2 más los VFX.
También podrías bajar a 40 fps
Hay que intentar no bajar mucho, porque entonces el efecto del coloreado con dos paletas empieza a cojear, y se nota un "flicker".
Estoy probando a introducir la posibilidad de hacer frame skip (saltarse el ejecutar una vez la función de rendering, pero no la de limpiado del fondo), nada exagerado, un frameskip de hasta 1 de cada 4 o 5 cuadros o así, para que proporcione el tiempo adicional que puede llegar a hacer falta en los momentos más abusivos. Las primeras pruebas parecen ir bien, alivias la necesidad de tiempo, y no aparece el "flickeo". Todavía falta hasta que considere que el frameskip es generalizable y estable.
Al parecer lo que hacen es que en algunas zonas del código o para algunos casos, no esperan a que el blitter este libre para enviarle los nuevos comandos, esto es porque saben que ya habrá terminado de hacer la operación, así poco a poco vas rascando ciclos, el problema es que si el emulador o la fpga no respeta los mismos tiempos al 100% fallara.
mills332
17/07/2020, 23:52
El metal slug de neo geo bajaba a muy pocos fps cuando había explosiones y cosas, yo creo que estaba ente 20 o 30 como máximo, no pasa nada si bajas poniendo sprites enormes.
Yo el problema que veo es la memoria, que te la puedes comer en nada, aunque puedes ir cargando el nivel a medida que avanzas como hacia el Ninja Warriors o el SWIV.
El metal slug de neo geo bajaba a muy pocos fps cuando había explosiones y cosas, yo creo que estaba ente 20 o 30 como máximo, no pasa nada si bajas poniendo sprites enormes.
neogeo no usaba ningun truco con el refresco de pantalla. Bueno, a veces si, los tipicos para simular transparencias, pero no basaba TODO el color del juego en eso.
Claro, cuando he dicho lo de bajar los FPS no había tenido en cuenta que se usan los 60fps para emular 30fps reales, pero con colores diferentes, y que se mezclen en la retina. A lo mejor a 40fps sí que se ve demasiado obvio el truco, pero si no fuera por eso, si se usasen las paletas "normales", el poder tener enemigos tan tochos funcionando a 30 fps, para esa máquina, por lo que tengo entendido, sería un logro impresionante.
masteries
22/07/2020, 12:02
Actualización con muchas de las mejoras a nivel del driver gráfico,
ahora sólo se redibujan los tiles del escenario que de verdad hacen falta; aquellos que están bajo los sprites, o que van a estar bajo los sprites no se redibujan. Se mantiene casi todo el tiempo a 50 fps, las ralentizaciones son muy puntuales. Más o menos salen en pantalla hasta la mitad de sprites que saca una NeoGeo (si consideramos el fondo como scroll, que en una NeoGeo no es así).
Por otra parte, dada la masiva cantidad (o tamaño) de los sprites, he prescindido del overscan; me gustaba mucho disponer de 240 líneas, pero el truco exige perder un tiempo de CPU totalmente necesario; me habré de conformar con 200 líneas; con una pantalla de 320x200
He podido capturar el audio, aunque he tenido que hacerlo por separado y luego juntarlos; el sonido que vais a escuchar está en 8 bits a 12.5 KHz (hasta 4 voces, aunque en esta demo apenas se usan 2 voces); y se escucha así de bien :)
https://www.youtube.com/watch?v=GhcNnmMOwD8
caman2002
22/07/2020, 12:50
Esté muy currado. Ya quisiera yo saber hacer eso
Seguramente lo que voy a decir no aplique a este tipo de scrolls con chorrocientos colores, tiles muy detallistas, y seguramente ya hayas pensado en ello, pero no está de más comentar la idea por si acaso:
¿Has tenido en cuenta, al pintar la nueva fila o columna en el buffer, si en dicha posición ya estaba pintado el mismo tile/imagen/maraña de puntos? Lo mismo te sirve para ahorrar algún ciclo de dibujado más, sobre todo si es un scroll tileado tipo SMBros.
Seguramente lo que voy a decir no aplique a este tipo de scrolls con chorrocientos colores, tiles muy detallistas, y seguramente ya hayas pensado en ello, pero no está de más comentar la idea por si acaso:
¿Has tenido en cuenta, al pintar la nueva fila o columna en el buffer, si en dicha posición ya estaba pintado el mismo tile/imagen/maraña de puntos? Lo mismo te sirve para ahorrar algún ciclo de dibujado más, sobre todo si es un scroll tileado tipo SMBros.
No es mala idea, me la apunto.
Por cierto ¿de que metal slug es ese tanque?, me parece un poco raro tiene como un cañón en la parte de las ruedas.
masteries
23/07/2020, 19:28
Por cierto ¿de que metal slug es ese tanque?, me parece un poco raro tiene como un cañón en la parte de las ruedas.
Es un tanque no utilizado de Metal Slug 1; ese cañon raro es un lanzallamas que cuenta con su propia animación para la llamarada, que tampoco fué utilizada.
Aún sin haber sido utilizado en el juego (ni en ningún otro metal slug), los datos de estos gráficos están presentes en la ROM de este primer juego de la serie.
Como update de hoy:
-Me he puesto a invetigar cómo tratar los "overrun", las situaciones en las que 1 fotograma tarda en dibujarse más tiempo del que se dispone para 1 fotograma, cuando tarde más de un retrazo vertical completo ( 1 VBL ).
-Hasta ahora se producía una caída inmediata a 25 fps, ralentizándose en exceso y perdiéndose el efecto del coloreado dualfield.
Solución:
-Sabiendo como funciona, a muy alto nivel, el engine; con este esquemita:
Editado: El esquema se ve como una m*****, ni con las etiquetas de code queda bien, pero se entiende. xD
Esto: |-----------------------------. Representa el tiempo que tarde 1 cuadro en actualizarse y dibujarse en el buffer que le corresponde.
(1st frame) (odd) (even) (odd)
VBL_IRQ VBL_IRQ VBL_IRQ VBL_IRQ
| (Frame time) | | |
|-----------------------. |-------------------------------------------. (Time Lost) |---------------------------.
-He podido recuperar el tiempo perdido, y poder utilizar el Time lost para empezar a dibujar el siguiente cuadro.
-Como mejoras, el juego ya no se ralentiza tanto, y se mantiene el efecto del dualfield.
->Problema, como el shifter está tomando un framebuffer donde aún no se ha terminado de dibujar todo, aparece un efecto en los sprites parecido al de la consola NES cuando pones más sprites de los que esta puede dibujar.
-Para ralentizaciones momentáneas, el truquito funciona bien, porque un pequeño parpadeo de algunas partes en algunos sprites, bueno es pasable.
Hay que estudiar el añadir un frameskip para estas situaciones.
-Falta por completar y añadir la detección de que un sprite no se está moviendo, para no tener que redibujarlo. Esto también ayudará en muchas situaciones.
Es un tanque no utilizado de Metal Slug 1; ese cañon raro es un lanzallamas que cuenta con su propia animación para la llamarada, que tampoco fué utilizada.
Aún sin haber sido utilizado en el juego (ni en ningún otro metal slug), los datos de estos gráficos están presentes en la ROM de este primer juego de la serie.
Hala!, a desperdiciar memoria XDXDXD
Para que no baje entre 50hz y 25hz una solución suele ser el triple buffer, pero en este caso por eso de usar dos pantallas para representar ¿necesitarías 6? eso seria una burrada.
Tal vez lo mejor sea que tengas dos zonas de código, uno que hace toda la IA, mover protagonista, etc, y la otra solo de dibujado. Cuando se termina un Frame deberías poder ejecutar la parte del calculo para el siguiente pero te tienes que esperar antes del código de dibujado si no se ha producido un vbl.
PD: lo malo es que la parte de la lógica ocupara muy poco (incluso en un juego real terminado) en comparación con la parte de dibujado.
masteries
10/08/2020, 21:01
Hala!, a desperdiciar memoria XDXDXD
Para que no baje entre 50hz y 25hz una solución suele ser el triple buffer, pero en este caso por eso de usar dos pantallas para representar ¿necesitarías 6? eso seria una burrada.
PD: lo malo es que la parte de la lógica ocupara muy poco (incluso en un juego real terminado) en comparación con la parte de dibujado.
Actualización:
La bajada de frames se ha solucionado utilizando los mismos dos búferes que ya estaban; si no llega a tiempo, se repite el útlimo cuadro y entonces muestra el cuadro a terminar cuando le toque mostrarse al siguiente. Se produce un frame slip; si te pasas mostrando gráficos se repite 1 cuadro cada tantos; dependiendo de lo excesiva que sea la sobrecarga. Pero vamos que ahora puedes mostrar muchísimos sprites, caer a 40 y pico cuadros y se sigue viendo bien el efecto del dualfield, y los sprites no parpadean ni nada de eso.
El esquema es así (las marcas verticales representa cuando se tendría que mostrar un nuevo cuadro, los números indican el cuadro que se está construyendo y el que se dibuja):
1............. 1............. 2............ 3.......... 4
|----------|----------|----------|--------|
1------------2---------3-----------4--------5
Con esta forma de operar, puedes ser incluso un poquito bestia con el tema gráfico, porque es cierto que vas perdiendo cuadros por el camino, porque a intervalos se van repitiendo, pero tienes que pedirle un 175% o un 200% de lo que puede dibujar en 1/50 para que de verdad el juego empiece a ir bastante mal.
Mucho mejor que antes, que se caía a 25 cuadros,
masteries
02/09/2020, 10:55
Se ha probado el resultado con un cable Atari STE a RGB Scart... en una TV led moderna...
La verdad, las TV de hoy traen SCART por herencia y cosas así... pero no se lo curran nada, no desentrelazan la imagen, ni hacen reescalado... sencillamente sólo dibujan 1 cuadro de los 2 que le llegan, y lo repiten durante 2 fotogramas. Por tanto, una imagen PAL a 50 Hz se convierte en una a 25 Hz; y una imagen NTSC a 60 Hz queda en 30.
Ha sido muy fácil detectarlo, además de porque el efecto de coloreado dualfield desaparece del todo; dado que sólo se muestra 1 de las paletas de 16 colores; también se me ocurrió colocar un sprite en una esquina, que cambia su imagen cada cuadro; este sprite muestra un número 1 y un 2; tan sólo el número 2 es visible en pantalla, el 1 no se ve nunca.
Así que ya sabéis, que a nadie más se le ocurra probar a través del SCART... por cierto ¿existe alguna TV moderna con un SCART en condiciones, que le puedas poner scanlines a través de un menú y cositas así? Y no haya que andar con los conversores a VGA, que si después el generador de scanlines... que si este u otro sistema te traen de cabeza con la señal de sincronismo... etc.
masteries
08/10/2020, 01:56
Os traigo una actualización:
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.
Olvidaba comentar, que el jugador, el soldado enemigo son sprites compuestos a mano; el torso por un lado y las piernas por otro. Se ahorra muchísima memoria, y se incrementa el trabajo...
Y ahora el vídeo, a disfrutarlo:
https://youtu.be/FMrdjrrtxWo
romeroca
10/10/2020, 09:53
Sorpendido me quedo con lo que estás haciendo. Enhorabuena.
masteries
17/10/2020, 20:58
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
selecter25
17/10/2020, 21:13
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
Lo difícil es creerlo aún viéndolo, es brutal.
romeroca
18/10/2020, 11:08
Es una pasada.
Desconocía totalmente las capacidades del STE. Gracias por tu trabajo.
Mola!!!
¿Donde te has pillado el lector de SD? Yo tengo un ST pero por si algún día amplio la familia...
¿Sabes que puedes abrir las carpetas y aplicaciones haciendo doble click XDXDXD?
Mola!!!
¿Donde te has pillado el lector de SD? Yo tengo un ST pero por si algún día amplio la familia...
¿Sabes que puedes abrir las carpetas y aplicaciones haciendo doble click XDXDXD?
Yo tengo la sospecha por lo mal que se movia el cursor y ademas se atrancaba que no estaba con un ratón real o que el que usaba estaba en las ultimas...
Yo tengo la sospecha por lo mal que se movia el cursor y ademas se atrancaba que no estaba con un ratón real o que el que usaba estaba en las ultimas...
Cierto, el raton se movía fatal, los de bola si no tienes una alfombrilla no suelen ir muy bien, ademas de que los tienes que limpiar cada poco tiempo.
masteries
18/10/2020, 20:12
Mola!!!
¿Donde te has pillado el lector de SD? Yo tengo un ST pero por si algún día amplio la familia...
¿Sabes que puedes abrir las carpetas y aplicaciones haciendo doble click XDXDXD?
El lector de SD es una maravilla... no es que la tasa de datos sea muy buena, pero 20 KB/s es sólo un poco más lento que la disquetera.
¡Pero resulta más cómodo disponer de un disco duro! :)
El ratón va bastante mal; el botón izquierdo tiende a quedarse enclavado, de ahí que no recurra a hacer doble click, y doy gracias que exista la opción de fichero->abrir
Creo que resultaba obvio el por qué alguien recurre a abrir y ejecutar de esta manera,
-----Actualizado-----
Cierto, el raton se movía fatal, los de bola si no tienes una alfombrilla no suelen ir muy bien, ademas de que los tienes que limpiar cada poco tiempo.
Cierto, hace tiempo que quiero darle un repaso general a ese ratón; o hacerme con un adaptador de ratón moderno a ratón Atari ST.
Otra cosa, el juego funciona mejor en la máquina real, que en emulador; en el emulador hay bajadas de cuadros donde en la máquina real no las hay... sospechamos que el emulador añade un ciclo de espera adicional tras cada orden dada al blitter y en cada una de sus transacciones.
Otra cosa, los binarios de esta demo estan adjuntos a este mensaje; ¡a probarlo!
Una cosa, cuando lo ejecuteis en el emulador Steem; tenéis que activar el Vsync (si usais Windows 7, tenéis que activar el Aero para que el Vsync funcione bien). Y no mováis la ventana del emulador, o paséis a pantalla completa con el juego corriendo; porque entonces la emulación se va a traste y se cuelga con tropecientas bombas, unas veces se pierde el sincronismo de la IRQ del mezclador de audio y otras es la manera de manejar el blitter la que hace que el emulador reviente si toqueteas las ventana sin pausar la emulación. El sonido PCM y el blitter no están 100% bien implementados en los emuladores.
53905
Que rabia no haber pillado un STE y un Amiga hace unos años cuando estaban tirados de precio.
masteries
19/10/2020, 10:48
Que rabia no haber pillado un STE y un Amiga hace unos años cuando estaban tirados de precio.
Cuando me hice con ellos; el STE y el Amiga 500 Plus; regalados no estaban, pero cierto que no se subieron a la parra como sucede hoy día; que por menos de 250€ o 300€ parece que no se ven.
La verdad se están columpiando mucho, demasiado especulador suelto.
Como recomendación, para poder hacerse con alguno de estos, y seguro lo sabes bien; hay que ir a los foros de "cacharreo"; los Atari STE y los Falcon anidan en Atari Forum, hay muchos que tienen más de una unidad funcionando, y pueden dejarte uno por un precio decente. Eso sí, el ordenador será la versión británica, porque allí se vendieron muy bien los STE; pero no es un problema grave que sea versión UK, sigue siendo PAL 50 Hz.
-----Actualizado-----
Mola!!!
¿Donde te has pillado el lector de SD?
El lector de SD es un desarrollo de Orion, durante el confinamiento duro.
Pese a que es sencillo de construir, puedes adquirir uno a buen precio al belga Olivier Gossuin:
https://www.gossuin.be/index.php/shop
Luego, hace falta un driver (son sólo 3 KB) que lo colocas en el directorio AUTO de un diskette.
Me sumo a los elogios, aunque todos se queden cortos :)
Se ve de miedo, por mucho escéptico que haya por ahí. Sigo sin conocer la máquina, pero viendo lo que he visto por la Retro Gamer, se nota que es un logro gordo.
blindrulo
21/10/2020, 13:49
Cierto, el raton se movía fatal, los de bola si no tienes una alfombrilla no suelen ir muy bien, ademas de que los tienes que limpiar cada poco tiempo.
Que yo sepa todo lo contrario. Yo uso en mi curro uno de bola desde hace 13 años y me funciona en todas las superficies sin problema, algo que o pueden decir mis compañeros con sus ratones ópticos, hay mesas donde no funcionan y necesitan ratón. xDD
Un saludo. :brindis:
Que yo sepa todo lo contrario. Yo uso en mi curro uno de bola desde hace 13 años y me funciona en todas las superficies sin problema, algo que o pueden decir mis compañeros con sus ratones ópticos, hay mesas donde no funcionan y necesitan ratón. xDD
Un saludo. :brindis:
Efectivamente que entretenimiento mejor se puede tener que quitarle la roña que se queda pegada a los rodillos de la bola y si tienes mascotas los pelufos que se cuelan cada mes, es utilidad y diversión en el mismo paquete :D, los de laser no funcionan en cristal pero como no soy spiderman y no me pego a las ventanas, solo uso mesas normales no me fallan :D.
Ahora sin coñas, llevo usando ratones opticos mucho tiempo y en el unico sitio que fallan es en las mesas con cristal o superpulidas, que son raras.
¿Soy el único que, por quitarle la roña a los rodillos, ha terminado quitando la tira de fieltro o de lo que sea que le ponen para que resbale menos? Lo curioso es que así el ratón me solía funcionar mejor, se atascaba menos y se limpiaba más fácilmente (incluso la roña podría mejorar el agarre :D).
Yo tengo ya sentimientos encontrados. Los de bola, al final, terminan por atascarse, pero los ópticos pueden dar saltos inesperados... Ahora ya menos porque parece que incorporan algún algoritmo que "suaviza" el movimiento y previene atascos o saltos.
De los que sí reniego son de los inalámbricos: por tener que estar pendiente de las pilas/batería, y por los problemas en la comunicación, tanto los cortes como los saltos que pueden meter.
De todas formas, para las superficies de cristal se usa una alfombrilla y listo. Te quitas el problema de que no reconoce la superficie, y evitas dejar huellas de la muñeca, y en verano, del brazo :D
blindrulo
21/10/2020, 18:33
Efectivamente que entretenimiento mejor se puede tener que quitarle la roña que se queda pegada a los rodillos de la bola y si tienes mascotas los pelufos que se cuelan cada mes, es utilidad y diversión en el mismo paquete :D, los de laser no funcionan en cristal pero como no soy spiderman y no me pego a las ventanas, solo uso mesas normales no me fallan :D.
Ahora sin coñas, llevo usando ratones opticos mucho tiempo y en el unico sitio que fallan es en las mesas con cristal o superpulidas, que son raras.
En mi curro hay unas mesas de madera y no van, bueno algunos no van otros sí. xDD
Un saludo. :brindis:
Para los ratones ópticos que dan problemas en la oficina existen unas cosas llamadas FOLIOS que te sacan del apuro
masteries
22/10/2020, 09:54
Para los ratones ópticos que dan problemas en la oficina existen unas cosas llamadas FOLIOS que te sacan del apuro
¡Cómo ha degenerado el hilo!
¡Aún hay quien va a la oficina!
Ahora en serio: ¿Os gusta Metal Slug, no? xD
Para los ratones ópticos que dan problemas en la oficina existen unas cosas llamadas FOLIOS que te sacan del apuro
¡Pero qué salvajada es esa! ¿Dónde queda tu conciencia con el medio ambiente? Un folio te sirve para un día o dos, luego ya estará mojado, arrugado y lleno de coronavirus de esos. No, mejor un paquete de 100 sin abrir :D
Es más fácil pedirle una alfombrilla al jefe, que seguro que tiene veinte llenas de mugre en algún cajón de la oficina, de las distintas empresas que les han ido a llevar acuerdos, publicidad o algo
¡Cómo ha degenerado el hilo!
¡Aún hay quien va a la oficina!
Ahora en serio: ¿Os gusta Metal Slug, no? xD
A mi no, pero porque tengo que mantener mi cuota de enfadar a los fans de las sagas sin ninguna razón. :awesome:
¿Has hecho cálculos de cuanta memoria saldría meter todos los niveles? ¿O vas hacer otra cosa?
masteries
22/10/2020, 14:25
¿Has hecho cálculos de cuanta memoria saldría meter todos los niveles? ¿O vas hacer otra cosa?
Hay que cosas que no serían posibles sin borrar y cargar de nuevo; por ejemplo el último nivel de Metal Slug 1; cuando caes al vacío y apareces en la cubierta de un submarino antiguo; a partir de ahí hay animaciones que si quisieras meterlas en un STE, te haría falta hacer una nueva carga.
Pero si adaptas el juego a lo mejor que puedas, entonces cada nivel lo metes en 3,5 MB más o menos. Te saldría unos 20 - 25 MB para un juego completo con los detalles mostrados hasta ahora y de duración en tiempo como el Metal original. Alguna cosa tienes que sacrificar, pero tampoco sería un port que lo perdiera todo; tal vez te puedes quedar con el 70 - 80 % de los detalles.
Puede que sea complicado de implementar, pero tal vez se pueda ir cargando el decorado a medida que avanzas, como lo hace el SWIV. O partir el nivel en trozos, todo depende de lo rápido que puedas leer.
masteries
22/10/2020, 15:41
Puede que sea complicado de implementar, pero tal vez se pueda ir cargando el decorado a medida que avanzas, como lo hace el SWIV. O partir el nivel en trozos, todo depende de lo rápido que puedas leer.
La verdad, es que ahora pudiendo disponer del lector de tarjetas SD; sabemos que son 20 KB/s; pero ya no sólo el escenario, más bien los sprites, porque éstos ocupan lo suyo... porque poder cargar y descargar los sprites sería fantástico.
Espera, lo voy a probar uno de estos días, porque en la demo ya uso 3 tareas distintas; ¡en una de ellas podría probar a hacer un "load" mientras funciona el juego a ver qué sucede!
Se supone que mientras no accedas a los recursos gráficos y de colisión de ese sprite, no debiera reventar, y la función de load podría verse interrumpida por las otras tareas; para continuar después,
lo pruebo y te cuento,
También abriría las puertas a los Amiga con 2 MB de RAM, 1 MB se sigue quedando corto, lo siento amigueros,
Probado:
Se pueden cargar sprites al vuelo, el juego no se cuelga, ni le sucede nada raro. Esto abre las puertas a un universo aún mayor de detalles sin fín.
Jefes finales con animaciones y tamaños increíbles de 512 KB o incluso 1 MB, así sin despeinarte. Y aún mayor detalle en los niveles.
Perdonadme la expresión, pero creo que Masteries acaba de tener un orgasmo :D
No he llegado tan lejos en el Metal Slug, pero yo te iba a decir que, si entre una sección y otra del nivel hay una caída o algún tipo de transición, hagas como en los juegos de las últimas dos décadas: amplia un poco esa sección (en los juegos 3D se hace añadiendo un pasillo con algo que te entretenga los suficiente para que cargue) y añade una especie de minijuego... No sé, siendo una caída, pues que vayan apareciendo enemigos, como la primera fase de Sly Spy, o helicopteros, o algo a lo que disparar mientras se va cargando.
La gente de amiga pensando que es un fake :lol:
https://eab.abime.net/showpost.php?p=1433928&postcount=590
Offtopic: Unas paginas mas adelante, que pasada el algoritmo para rebajar los colores de la imagen a 16!!!!
https://eab.abime.net/showpost.php?p=1435457&postcount=675
masteries
23/10/2020, 14:36
La gente de amiga pensando que es un fake :lol:
https://eab.abime.net/showpost.php?p=1433928&postcount=590
Offtopic: Unas paginas mas adelante, que pasada el algoritmo para rebajar los colores de la imagen a 16!!!!
https://eab.abime.net/showpost.php?p=1435457&postcount=675
jajaja ¡Los amigueros están entrando en catatonia! Me encanta ese que balbucea... Metal Slug on STE.... but !LionHeart! LionHert on Amiga.... Lionheart on Amiga.... y se repite con la cantinela... [wei]
El Amiga me gusta mucho, pero no tiene 4 MB de chip RAM.
Pobres, si supieran lo que les espera... jefes gigantes, con animaciones brutales...
y eso que apenas han visto a los soldados enemigos en movimiento; pese a que ya tenía todas las animaciones cargadas en la versión demo, no tenía programados sus comportamientos.
¿Por cierto, cómo responder en los hilos de ese foro? Me he registrado y no puedo escribir... me han debido ver llegar xD
¿Por cierto, cómo responder en los hilos de ese foro? Me he registrado y no puedo escribir... me han debido ver llegar xD
Tal vez tengas que escribir primero en el hilo de bien venida, IIRC en un foro de Atari los primeros mensajes que escribes te los tienen que validar para ver que no eres un troll y que aportas algo.
princemegahit
23/10/2020, 16:31
Tal vez tengas que escribir primero en el hilo de bien venida, IIRC en un foro de Atari los primeros mensajes que escribes te los tienen que validar para ver que no eres un troll y que aportas algo.
si, tienes que ir al hilo de bienvenida, y creo que tienes que tener 3 mensajes para poder crear un hilo propio.
si, tienes que ir al hilo de bienvenida, y creo que tienes que tener 3 mensajes para poder crear un hilo propio.
Hola, soy masteries, programo en un Atari STE y vengo a tocar las narices a los amigueros :lol:
Baneado.
masteries
27/10/2020, 02:20
¡Lo que se nos viene encima!
¡Lo que dan de sí 16 colores!
AtaGeo lo llamaban,
Resultados de depurar aún más el algoritmo de búsqueda de colores, para poder dar soporte a niveles muy complejos, donde haya gran repertorio de colorido:
He tomado fotografías, porque el coloreado dualfield no se puede capturar con un print-screen
53933
53937
53934
53935
53936
53938
53940
53939
53941
Eso es un fake, es imposible que eso lo haga un Atari STE sin ser un Amiga :awesome:
*****, dan ganas de coger las librerías y hacer alguna conversion decente de las muchas "truño" conversiones de arcade que nos tragamos en los 16bits.
romeroca
27/10/2020, 18:06
masteseries si haces eso con 16 colores ... ¿qué podrías hacer con 32 colores en un AMIGA? Piensa, piensa
masteseries si haces eso con 16 colores ... ¿qué podrías hacer con 32 colores en un AMIGA? Piensa, piensa
¿Has visto "Ori and the Blind Forest"?
https://i.ytimg.com/vi/zJ0rxUTGav4/mqdefault.jpg
¿Y qué tal está el juego, que yo todavía no...?
(Tenía que haberlo puesto vestido de astronauta, pero no encuentro ninguna captura ^^U)
masteries
28/10/2020, 02:18
masteseries si haces eso con 16 colores ... ¿qué podrías hacer con 32 colores en un AMIGA? Piensa, piensa
Masteries hace eso con 16 colores, masteseries no se qué hará...
Los 32 colores del Amiga, sus 5 planos de bits...
vamos a abrir el cajón; suponiendo que los planos del Amiga estén organizados de la misma forma que los del Atari STE; que según la gente de eab.abime no es así.
Contemos la historia técnica y lo que es un STE:
Sobre los anchos de banda y el monstruo del blitter de la gama STE:
En el STE los píxeles constan de 4 bits y se organizan en grupos de 16, y sólo puedes escribir de 16 en 16 bits, cada vez que mueves a pantalla con el blitter, mueves la información de 16 píxeles; se estructuran así:
16 píxeles
-------------------------------------------------------------- --------------------------------------------------------------
64 bits: Bit0-Pixel0 Bit0-Pixel1 Bit0-Pixel2 ... Bit0-Pixel15 | Bit1-Pixel0 Bit1-Pixel1 Bit1-Pixel2 ... Bit1-Pixel15 ... y así otras 2 palabras de 16 bits más
si Amiga lo estructurase igual:
16 píxeles
-------------------------------------------------------------- --------------------------------------------------------------
80 bits: Bit0-Pixel0 Bit0-Pixel1 Bit0-Pixel2 ... Bit0-Pixel15 | Bit1-Pixel0 Bit1-Pixel1 Bit1-Pixel2 ... Bit1-Pixel15 y así otras 3 palabras más de 16 bits
En Amiga, respecto a STE, tienes que mover un 25% más de datos; sin en STE 4 palabras es el 100%, en Amiga 5 palabras es un 125%
El Amiga presenta una RAM con un reloj de entrada inferior a 7 MHz, mientras que el STE presenta un reloj en la RAM de 8 MHz; hay más ancho de banda disponible para mover datos en STE.
Sigamos,
el blitter del Amiga es muy poderoso de por sí, pero se diseñó para funcionar por el método tradicional, emplear máscaras, hacer operaciones lógicas entre máscara y gráfico... dibujar empleando varias pasadas; que se traducen en varias pasadas por la RAM.
El blitter del STE parte del diseñado para el Mega ST, que monta un 68k con caché a 16 MHz; este blitter se diseñó de forma que supusiera una ventaja a utilizar respecto a su CPU; no habría tenido sentido un blitter que aportará poco respecto a hacer ese trabajo con la CPU. El blitter del MegaST corre a 16 MHz, se alimenta del reloj de su CPU, y consume muy pocos ciclos de reloj en sus tareas, bastantes menos que la CPU. Quedaos con la copla de los 16 MHz del blitter en el MegaST, pues es muy importante para lo que viene después. En el MegaST, el blitter tiene 2 modos de funcionamiento, más unas 12 formas de utilizarse.
Llegamos al STE, y recibe una actualización del mismo blitter que monta el MegaST... sí señores, no es el mismo del MegaST, es un update con un nuevo modo de funcionamiento y algunas formas más de utilizarse; cuya documentación apenas tuvieron algunos desarrolladores, entre ellos el autor de las AGT... jajaja por aquí va llegando la magia... el nuevo modo de funcionamiento le permite al blitter tomar el control de la máquina, supendiendo el reloj de la CPU; pero manteniendo el circuito DMA de audio digital en funcionamiento; así mismo una nueva forma de utilizarse bajo este modo, es el de mover datos de un sitio a otro, pero conociendo de antemano los bits que no se verán alterados por el proceso de escritura; lo que antes se hacía mediante operaciones lógicas de máscaras, ¡ahora no requiere máscaras! ¡Pudiendo dibujar sprites de una sola pasada! ¡Y para limpiar el escenario de los sprites también puede conocer de antemano los dirty rect. y limpiarlos de una pasada! Un par de cosas que no podía hacer la anterior versión del blitter del MegaST, y que se parecen más a dibujar sprites en un modo de video chunky que en uno planar.
Y si esto no fuera suficiente, cuando el blitter entra en el modo maestro en el STE, ¡pasa a funcionar a 16 MHz! (duplica el reloj de entrada en su interior) y el sistema rinde como un MegaST en lo que a ancho de banda y movimiento de datos se refiere; la CPU sigue restringida a 8 MHz, pero en estas tareas no interviene, se la manda a dormir. El DMA accede a memoria de forma alterna al blitter, las frecuencias del audio de salida son algo peculiares para mantener este sincronismo con el blitter, y que no se estorben. En este modo es también el blitter quien se encarga de leer y escribir en la RAM, y lo hace al mismo rendimiento que un MegaST, o un MegaSTE.
Así que una vez explicadas las diferencias entre los anchos de banda de un Amiga 500 o 500 Plus o 600; y un STE; nos queda decir que si con todo esto, ya está al límite con unos 18 - 20 sprites de 32x32 a 4 bits, si tuviera que mover esto mismo a 5 bits; no llegabas a 50 frames por segundo, y sin los 50 frames la técnica del dualfield no funcionaría bien; por debajo de 40 ya se empieza a notar flickeo.
Así que en Amiga no sería nada fácil o directamente extrapolable hacer dualfield con 32 colores; quizá con 16 si se pudiera, pero desconozco si en Amiga te ves obligado a escribir siempre los 5 planos de bits.
Y ahora más trucos recien descubiertos e indocumentados del blitter del STE:
-Si en lugar de utilizar los end mask como fueron pensados, los utilizamos para escribir datos gráficos en ellos; se te permite concatenar dos sprites... y si en el siguiente haces lo mismo... se vuelve a concatenar... (técnicamente no será así de sencillo, pero así es como podemos dibujar sprites gigantes con buen rendimiento; porque no se desaprovechan datos; descubrimiento del autor de las AGT de este año 2020). En eab.abime, expertos del Amiga han probado ha intentar replicar esto en el blitter del Amiga, y no realiza esta función de concatenado.
-Y otro truco descubierto del blitter del STE, si no configuras zonas vacías (píxeles que no se verán alterados por la escritura) entre las zonas vacías del principio y el final del gráfico, se te permite dibujar una línea de textura de hasta 256 píxeles de ancho. O lo que es lo mismo, el blitter del STE hace rasters con textura. Vamos, con lo que se hace el suelo de Street Fighter 2 Alguien ya descubrió esto en 1994, colgué un vídeo por aquí. En AGT es el formato de sprites tipo SLAB. Recordad, que son hasta 256 píxeles sin que el blitter deje de funcionar, 256 píxeles copiados sin que la CPU se despierte, 256 píxeles copiados con el rendimiento de un MegaST/E
-Otro descubrimiento del autor de las AGT, de cuando programó el juego Cisco Heat y añadió soporte para STE; el blitter del STE puede rellenar áreas con un color elegido de la paleta, así dibuja la carretera en Cisco Heat. También puede hacer otras primitivas gráficas sencillas. Esto lo hace sin necesidad de mover datos, sólo escribe sabiendo lo que está haciendo, lo que le permite pintar muy rápido las primitivas.
Ahora vamos a por el consumo de memoria:
-Para el asunto del dualfield y el frame-slipping (que la tasa de cuadros no baje a la mitad en caso de sobrecarga, sino que se queda a 40 y tantos cuadros), necesitas unos 160 KB de RAM. Otros 128 más o menos para los drivers gráficos, unos 4 KB más para mi driver de audio. Los sprites, al ser sprites compilados (ya contienen lo que la CPU tiene que escribir en el blitter, la CPU a nivel gráfico sólo lee las órdenes y se las transmite al blitter), ocupan bastante y un 10% más si los quieres con dualfield; el mapeado al ser dualfield, ocupa como si los tiles estuvieran en color de 8 bits.
En definitiva, que con menos de 2 MB de RAM no puedes hacer todo esto. Y han de ser 2 MB de Chip RAM, aquí está el verdadero problema del Amiga, sólo los A500 Plus y el A600 pueden montar 2 MB de Chip RAM sin hacer trucos raros. El STE puede montar 4 MB, y son todo chip RAM.
-Respecto al audio:
-Solo empleo audio digital mono de 8 bits a 12,5 KHz, el Amiga creo que no puede trabajar con .wav directamente. El YM2149 ni lo toco siquiera.
-Respecto al scroll:
-En contra de la creencia popular, el scroll hardware del STE consta de dos ventanas independientes, dos scrolles independientes; que si bien no hacen un parallax puro como el de MegaDrive, si puede emplearse el segundo para desplazar una zona de la pantalla a distinta velocidad y crear un efecto parallax algo más limitado. Pero usando el hardware; el autor de las AGT está estudiando su uso e implementación.
----------------------------------------------------------------------
Resumiendo, el Amiga nació con mucho hardware y muchas ventajas;
El STE recibió el blitter del MegaSTE con modos de funcionamiento mucho más modernos y eso le confiere a nivel gráfico un ancho de banda mayor.
También recibió una dosis de memoria RAM bastante mayor, que se suele antojar necesaria para sprites compilados y dualfield.
Ambas máquinas no pueden espejar horizontalmente los sprites, al menos no cuando son sprites compilados, lo que no deja de sentarme mal por la cantidad de RAM que se merienda el mismo gráfico mirando hacia el otro lado. El STE si puede espejar verticalmente, que ahora mismo no sé para qué sirve, pero para algo servirá. Supongo que el Amiga también podrá hacer esto último.
Y yo que siempre he pensado que el blitter del STE, era igual al del MegaST, que era el que iba a llevar el ST si les hubiera dado tiempo a terminarlo...
rafa-lito
28/10/2020, 22:22
Masteries hace eso con 16 colores, masteseries no se qué hará...
Los 32 colores del Amiga, sus 5 planos de bits...
vamos a abrir el cajón; suponiendo que los planos del Amiga estén organizados de la misma forma que los del Atari STE; que según la gente de eab.abime no es así.
Contemos la historia técnica y lo que es un STE:
Sobre los anchos de banda y el monstruo del blitter de la gama STE:
En el STE los píxeles constan de 4 bits y se organizan en grupos de 16, y sólo puedes escribir de 16 en 16 bits, cada vez que mueves a pantalla con el blitter, mueves la información de 16 píxeles; se estructuran así:
16 píxeles
-------------------------------------------------------------- --------------------------------------------------------------
64 bits: Bit0-Pixel0 Bit0-Pixel1 Bit0-Pixel2 ... Bit0-Pixel15 | Bit1-Pixel0 Bit1-Pixel1 Bit1-Pixel2 ... Bit1-Pixel15 ... y así otras 2 palabras de 16 bits más
si Amiga lo estructurase igual:
16 píxeles
-------------------------------------------------------------- --------------------------------------------------------------
80 bits: Bit0-Pixel0 Bit0-Pixel1 Bit0-Pixel2 ... Bit0-Pixel15 | Bit1-Pixel0 Bit1-Pixel1 Bit1-Pixel2 ... Bit1-Pixel15 y así otras 3 palabras más de 16 bits
En Amiga, respecto a STE, tienes que mover un 25% más de datos; sin en STE 4 palabras es el 100%, en Amiga 5 palabras es un 125%
El Amiga presenta una RAM con un reloj de entrada inferior a 7 MHz, mientras que el STE presenta un reloj en la RAM de 8 MHz; hay más ancho de banda disponible para mover datos en STE.
Sigamos,
el blitter del Amiga es muy poderoso de por sí, pero se diseñó para funcionar por el método tradicional, emplear máscaras, hacer operaciones lógicas entre máscara y gráfico... dibujar empleando varias pasadas; que se traducen en varias pasadas por la RAM.
El blitter del STE parte del diseñado para el Mega ST, que monta un 68k con caché a 16 MHz; este blitter se diseñó de forma que supusiera una ventaja a utilizar respecto a su CPU; no habría tenido sentido un blitter que aportará poco respecto a hacer ese trabajo con la CPU. El blitter del MegaST corre a 16 MHz, se alimenta del reloj de su CPU, y consume muy pocos ciclos de reloj en sus tareas, bastantes menos que la CPU. Quedaos con la copla de los 16 MHz del blitter en el MegaST, pues es muy importante para lo que viene después. En el MegaST, el blitter tiene 2 modos de funcionamiento, más unas 12 formas de utilizarse.
Llegamos al STE, y recibe una actualización del mismo blitter que monta el MegaST... sí señores, no es el mismo del MegaST, es un update con un nuevo modo de funcionamiento y algunas formas más de utilizarse; cuya documentación apenas tuvieron algunos desarrolladores, entre ellos el autor de las AGT... jajaja por aquí va llegando la magia... el nuevo modo de funcionamiento le permite al blitter tomar el control de la máquina, supendiendo el reloj de la CPU; pero manteniendo el circuito DMA de audio digital en funcionamiento; así mismo una nueva forma de utilizarse bajo este modo, es el de mover datos de un sitio a otro, pero conociendo de antemano los bits que no se verán alterados por el proceso de escritura; lo que antes se hacía mediante operaciones lógicas de máscaras, ¡ahora no requiere máscaras! ¡Pudiendo dibujar sprites de una sola pasada! ¡Y para limpiar el escenario de los sprites también puede conocer de antemano los dirty rect. y limpiarlos de una pasada! Un par de cosas que no podía hacer la anterior versión del blitter del MegaST, y que se parecen más a dibujar sprites en un modo de video chunky que en uno planar.
Y si esto no fuera suficiente, cuando el blitter entra en el modo maestro en el STE, ¡pasa a funcionar a 16 MHz! (duplica el reloj de entrada en su interior) y el sistema rinde como un MegaST en lo que a ancho de banda y movimiento de datos se refiere; la CPU sigue restringida a 8 MHz, pero en estas tareas no interviene, se la manda a dormir. El DMA accede a memoria de forma alterna al blitter, las frecuencias del audio de salida son algo peculiares para mantener este sincronismo con el blitter, y que no se estorben. En este modo es también el blitter quien se encarga de leer y escribir en la RAM, y lo hace al mismo rendimiento que un MegaST, o un MegaSTE.
Así que una vez explicadas las diferencias entre los anchos de banda de un Amiga 500 o 500 Plus o 600; y un STE; nos queda decir que si con todo esto, ya está al límite con unos 18 - 20 sprites de 32x32 a 4 bits, si tuviera que mover esto mismo a 5 bits; no llegabas a 50 frames por segundo, y sin los 50 frames la técnica del dualfield no funcionaría bien; por debajo de 40 ya se empieza a notar flickeo.
Así que en Amiga no sería nada fácil o directamente extrapolable hacer dualfield con 32 colores; quizá con 16 si se pudiera, pero desconozco si en Amiga te ves obligado a escribir siempre los 5 planos de bits.
Y ahora más trucos recien descubiertos e indocumentados del blitter del STE:
-Si en lugar de utilizar los end mask como fueron pensados, los utilizamos para escribir datos gráficos en ellos; se te permite concatenar dos sprites... y si en el siguiente haces lo mismo... se vuelve a concatenar... (técnicamente no será así de sencillo, pero así es como podemos dibujar sprites gigantes con buen rendimiento; porque no se desaprovechan datos; descubrimiento del autor de las AGT de este año 2020). En eab.abime, expertos del Amiga han probado ha intentar replicar esto en el blitter del Amiga, y no realiza esta función de concatenado.
-Y otro truco descubierto del blitter del STE, si no configuras zonas vacías (píxeles que no se verán alterados por la escritura) entre las zonas vacías del principio y el final del gráfico, se te permite dibujar una línea de textura de hasta 256 píxeles de ancho. O lo que es lo mismo, el blitter del STE hace rasters con textura. Vamos, con lo que se hace el suelo de Street Fighter 2 Alguien ya descubrió esto en 1994, colgué un vídeo por aquí. En AGT es el formato de sprites tipo SLAB. Recordad, que son hasta 256 píxeles sin que el blitter deje de funcionar, 256 píxeles copiados sin que la CPU se despierte, 256 píxeles copiados con el rendimiento de un MegaST/E
-Otro descubrimiento del autor de las AGT, de cuando programó el juego Cisco Heat y añadió soporte para STE; el blitter del STE puede rellenar áreas con un color elegido de la paleta, así dibuja la carretera en Cisco Heat. También puede hacer otras primitivas gráficas sencillas. Esto lo hace sin necesidad de mover datos, sólo escribe sabiendo lo que está haciendo, lo que le permite pintar muy rápido las primitivas.
Ahora vamos a por el consumo de memoria:
-Para el asunto del dualfield y el frame-slipping (que la tasa de cuadros no baje a la mitad en caso de sobrecarga, sino que se queda a 40 y tantos cuadros), necesitas unos 160 KB de RAM. Otros 128 más o menos para los drivers gráficos, unos 4 KB más para mi driver de audio. Los sprites, al ser sprites compilados (ya contienen lo que la CPU tiene que escribir en el blitter, la CPU a nivel gráfico sólo lee las órdenes y se las transmite al blitter), ocupan bastante y un 10% más si los quieres con dualfield; el mapeado al ser dualfield, ocupa como si los tiles estuvieran en color de 8 bits.
En definitiva, que con menos de 2 MB de RAM no puedes hacer todo esto. Y han de ser 2 MB de Chip RAM, aquí está el verdadero problema del Amiga, sólo los A500 Plus y el A600 pueden montar 2 MB de Chip RAM sin hacer trucos raros. El STE puede montar 4 MB, y son todo chip RAM.
-Respecto al audio:
-Solo empleo audio digital mono de 8 bits a 12,5 KHz, el Amiga creo que no puede trabajar con .wav directamente. El YM2149 ni lo toco siquiera.
-Respecto al scroll:
-En contra de la creencia popular, el scroll hardware del STE consta de dos ventanas independientes, dos scrolles independientes; que si bien no hacen un parallax puro como el de MegaDrive, si puede emplearse el segundo para desplazar una zona de la pantalla a distinta velocidad y crear un efecto parallax algo más limitado. Pero usando el hardware; el autor de las AGT está estudiando su uso e implementación.
----------------------------------------------------------------------
Resumiendo, el Amiga nació con mucho hardware y muchas ventajas;
El STE recibió el blitter del MegaSTE con modos de funcionamiento mucho más modernos y eso le confiere a nivel gráfico un ancho de banda mayor.
También recibió una dosis de memoria RAM bastante mayor, que se suele antojar necesaria para sprites compilados y dualfield.
Ambas máquinas no pueden espejar horizontalmente los sprites, al menos no cuando son sprites compilados, lo que no deja de sentarme mal por la cantidad de RAM que se merienda el mismo gráfico mirando hacia el otro lado. El STE si puede espejar verticalmente, que ahora mismo no sé para qué sirve, pero para algo servirá. Supongo que el Amiga también podrá hacer esto último.
Como novato pregunto? Y el amiga 1200? Porque si comparamos sería el Atari ST con el amiga 500. Si cogemos un modelo superior de Atari, hagámoslo con Amiga también, no?
Pero un amiga 1200 lo tendrías que comparar con un Falcon. De todas formas creo que sigues teniendo la misma limitación de chip ram, hasta 2MB.
rafa-lito
28/10/2020, 23:01
Pero un amiga 1200 lo tendrías que comparar con un Falcon. De todas formas creo que sigues teniendo la misma limitación de chip ram, hasta 2MB.
Pero tendrías que comparar el STE con un modelo intermedio . Pero creo que el Amiga 600 no valdría, ni el 500+ tampoco. No r cuerdo el Amiga 2000 y el 4000 cómo iban de chip Ram
El 4000 no se pero el 2000 IIRC es de la misma época que el 500 (quizás un poco anterior).
-----Actualizado-----
Aqui viene, 2MB como mucho
https://es.wikipedia.org/wiki/Chip_de_RAM_de_Amiga
romeroca
30/10/2020, 15:41
No hay nada equivalente de Amiga en la época que salió el STE. Como mucho el 600 y el 3000.
Para mí el 1200 fue una decepción. Muy lento y con un sistema gráfico recortado de lo que debería haber sido.
masteries
30/10/2020, 16:04
Ahora más, con transparencias:
53951
Una pequeña prueba, para poder implementar las cascadas del primer nivel de Metal Slug, pero con un efecto de transparencia que parezca más real.
También se ha añadido soporte a muchas cositas más, tales como:
-Doble background, para tener un plano por delante (foreground) y otro por detrás (background).
-Poder colocar los sprites en el background de fondo, entre medias o por encima de todo.
-El efecto este de las transparencias, pero para cualquier sprite; una forma de generalizar la creación de sprites transparentes.
-Sprites compilados que ocupan mucho menos (en la demo que ya conocéis se están ahorrando 400 KB de RAM, disponibles para mayores brutalidades); dependiendo de si tu sprite no se desplaza, se mueve de 1 en 1 pixel, de 2 en 2... estos últimos casos son los más interesantes, pues si se mueve de 2 en 2 píxeles, el sprite compilado ocupa sólo la mitad... si no se va a desplazar (como los sacos de arena) entonces ahora ocupa 16 veces menos.
-Sprites que no consumen blitter siempre que no se muevan o cambie su fotograma; esto está proporcionando mucha más potencia gráfica disponible, si juegas bien con las animaciones de los sprites.
En desarrollo:
-Parallax usando la segunda ventana de scroll hardware. Esto va para más largo, pero se está trabajando en ello.
-Carga dinámica de sprites y gráficos; se cargarán durante el juego usando sólo el tiempo que le quede libre a la CPU; modalidad de carga No Blocking.
Las transparencias son al estilo sega saturn (XD), ¿no?
masteries
30/10/2020, 18:15
Las transparencias son al estilo sega saturn (XD), ¿no?
Bueno, más o menos es eso; duplicando cada fotograma y desplazando el entramado un pixel.
A 50 frames por segundo el efecto es resultón, creo que más lejos no se va a poder llegar; pero ya son más resultonas que las transparencias de otras máquinas.
masteries
06/11/2020, 19:02
Actualización,
Scroll Parallax por hardware en el STE:
Por fin se ha descubierto como usar el sistema de dos ventanas independientes, y resulta que los segundos controles no manejan una sola ventana... si no que permiten crear diferentes zonas de scroll;
de la misma forma que una MegaDrive.
En este vídeo hay 4 zonas de scroll,
https://www.youtube.com/watch?v=L-H-lZFWg6k
¡Esto promete mucho!
Actualización,
Scroll Parallax por hardware en el STE:
Por fin se ha descubierto como usar el sistema de dos ventanas independientes, y resulta que los segundos controles no manejan una sola ventana... si no que permiten crear diferentes zonas de scroll;
de la misma forma que una MegaDrive.
En este vídeo hay 4 zonas de scroll,
https://www.youtube.com/watch?v=L-H-lZFWg6k
¡Esto promete mucho!
pero eso es raster, no? eso no son capas distintas.
masteries
06/11/2020, 23:06
pero eso es raster, no? eso no son capas distintas.
Se pueden superponer, efectivamente para que se comporten como capas distintas,
Pero, y mientras se superponen, una capa se desplaza respecto a otra un incremento de 16 pixels; una de las dos capas se va al traste y se empiezan a ver los gráficos de esa capa como corruptos.
Se desconoce completamente por qué sucede eso.
Lo que se ha logrado hasta ahora es que mientras no se superpongan, se mantenga estable.
Todo esto parte de descubrir y emplear usos de direcciones de memoria que eran desconocidos, de hecho están más allá del espacio de los 14 MB físicos direccionables.
Lo que hacen estos supuestos registros, qué significa lo que se escribe en ellos, y si hay otros desconocidos que hay que tocar o leer y estar atentos... es desconocido.
De hecho ya me parece raro que esto se haya descubierto,
Estos planos admiten clipping automático:
https://www.youtube.com/watch?v=XLKd-f9QJcY
para hacer rasters, hmmm.... parece que la mínima altura que manejan son 16 pixels; los rasters a nivel de 1 o 2 píxeles, mejor con el blitter y su modo de pintar líneas de hasta 256 pixels de ancho.
Por otra parte, tal vez todo esto era desconocido, porque forma parte de un diseño hardware sin terminar; es una suposición, pero parece tener su lógica.
De todas formas, al poder gobernarlos a tu antojo, se pueden hacer muchas cosas para disponer de scroll parallax; como por ejemplo empezar un nivel sin ningún parallax, y luego empezar a hacer parallax con una parte... y ya te currarás algo para solapar.
No pillo como va el parallax con capas superpuestas, si tienes que usar el blitter para dibujar encima de una capa normal no debería tener la restricción de los 16 pixels, se supone que el blitter tienes el desplazamiento a pixel gratis, y si es cosa del shifter indicaría que tendría que leer mas datos/planos por pixel...
masteries
07/11/2020, 18:39
No pillo como va el parallax con capas superpuestas, si tienes que usar el blitter para dibujar encima de una capa normal no debería tener la restricción de los 16 pixels, se supone que el blitter tienes el desplazamiento a pixel gratis, y si es cosa del shifter indicaría que tendría que leer mas datos/planos por pixel...
Con múltiples capas lo que haces es indicar que tienes tantas zonas de memoria dedicadas para acabar siendo distintas ventanas; aunque varias de ellas tengan su coordenada Y o X superpuesta;
al nivel de dibujar en ellas con el blitter lo haces de forma normal, pintas en todas ellas, como cuando pintabas en una sola (más el segundo búfer).
Es en el momento de crear las líneas analógicas, lo que es tarea del shifter si no me equivoco, cuando éste sabe, a través de esos nuevos registros de memoria, que para crear una línea concreta debe leer de dos zonas de memoria; para combinar dos líneas (es el color transparente donde se pintará la zona con menos prioridad); en todo esto (que sepamos) no interviene la CPU; es el propio shifter quien lo hace (el shifter del STE es más diferente de lo que se pensaba hasta ahora), pero cuando la diferencia llega a cierto punto (parecen ser 16 pixels) esta tarea empieza a crear píxeles de colores erróneos (deja de trabajar bien y no sabemos por qué).
¿El shifter tiene una memoria interna de trabajo donde copia las dos líneas y se queda sin espacio? ¿Sucede algo que requiere atender una interrupción? ¿O sencillamente no funciona bien porque esto no está terminado? Por cierto, que el sistema estalla con muchas bombas si quieres combinar más de dos zonas / planos.
El clipping lo hace el solito, y lo hace bien, aunque si no tienes cuidado, puedes llegar a pintar sprites que no se van a dibujar.
El blitter sólo lo usas para actualizar las zonas de memoria de los planos, cuando el shifter no interviene; como bien sabes porque pudiste verlo en la demo más temprana al caminar hacia la izquierda :)
Entonces el shifter el STE es bastante mas distinto al de un ST normal, que es bastante simple, lee 4 palabras de 16 bits y las combina para generar 16 Pixels con 4 bits por cada pixel. Yo solo vi documentación de como funcionaba el scroll por hardware, IIRC tienes un registro nuevo para indicar la dirección baja de memoria (ultimo byte de una direccion), otro para indicar el desplazamiento entre 0 y 16 pixels, y otro para indicar el ancho de la linea. Pero parece que hay más registros sin documentar.
masteries
13/11/2020, 14:03
Entonces el shifter el STE es bastante mas distinto al de un ST normal, que es bastante simple, lee 4 palabras de 16 bits y las combina para generar 16 Pixels con 4 bits por cada pixel. Yo solo vi documentación de como funcionaba el scroll por hardware, IIRC tienes un registro nuevo para indicar la dirección baja de memoria (ultimo byte de una direccion), otro para indicar el desplazamiento entre 0 y 16 pixels, y otro para indicar el ancho de la linea. Pero parece que hay más registros sin documentar.
Pues cuando os cuente lo que se acaba de descubrir, verás que es aún más diferente,
Se acaba de descubrir que configurando, en un registro más allá de los 14 MB que todos pensábamos que era el límite; el shifter del STE pasa a replicar las funcionalidades del Copper del Amiga (en lo que a modificación de la paleta de color se refiere), sin requerir la asistencia de la CPU.
En ese registro puedes escribir la dirección de memoria de una tabla que contenga una nueva paleta de 16 colores y la línea donde deseas que se produzca el cambio (son 32 bits, 24 de la dirección y 8 para la línea). Y ¡voila!, cuando llega esa línea los 16 colores del shifter cambian, dado que el shifter ha leído el solito (durante los blanking horizontales) los 16 colores nuevos durante la línea anterior, y al llegar la línea marcada se produce el swap de los 16 colores del shifter (el shifter del STE debe tener estos registros duplicados, y un contador de líneas para que pueda hacer esas comparaciones).
Hay tres modos de operación para esto:
1-) Puedes cambiar los 16 colores.
2-) Puedes configurarlo para cambiar y leer sólo el color de background; lo que te permitiría hacer gradientes de color
3-) Puedes cambiar 2 colores ¿? No sé para que sirve, pero esto lo hace necesitando sólo un único blanking horizontal, por lo que podrías cambiar un par de colores en todas las líneas.
Nos gustan mucho los modos 1 y 2; el 2 ya se venía utilizando en el ST mediante interrupciones del Timer B; supongo que el 1 también sería posible.
Pero el hecho de que lo haga sólo nos ha llamado mucho la atención.
El autor de las AGT ya se está poniendo manos a la obra para que al crear un mapeado te genere varios juegos de paletas, en lugar de sólo dos paletas de 16 colores.
Queremos ver cómo se ven los mapeados con 2 o 4 juegos de paletas. :awesome:
Editado: Lo de los planos solapados aún no se sabe cómo solucionar, pero vamos ya con todas estas cosas nuevas, el STE se está viniendo muy arriba.
fbustamante
13/11/2020, 14:31
Voy a mirar cuanto valen antes de que suban de precio. :awesome:
-----Actualizado-----
Ya miré...
Os juro que me partiré de risa cuando nuestra generación chochee, nuestros hijos no quieran para nada nuestras mierdas ochenteras y los pootos especuladores se metan por el culo toda su especulación. :(
masteries
13/11/2020, 14:49
Voy a mirar cuanto valen antes de que suban de precio. :awesome:
-----Actualizado-----
Ya miré...
Os juro que me partiré de risa cuando nuestra generación chochee, nuestros hijos no quieran para nada nuestras mierdas ochenteras y los pootos especuladores se metan por el culo toda su especulación. :(
Si quieres uno, un STE funcionando, puedo mirártelo de gente decente del Reino Unido, donde hay muchos ST y STE, incluso hay mucho Falcon;
y te lo pueden dejar a un precio decente. Tampoco lo van a regalar, pero no te van a pedir 300€ ni 400€ como joyeros que acabo de ver; una vez encontrado te paso el contacto del guiri que encuentre,
En ebay acabo de ver éste que todavía está a precio razonable (ahora, a ver cuánto tarda en inflarse de precio):
https://www.ebay.es/itm/Atari-1040STE-boxed-and-working-Excellent-Condition-in-original-box-No-Monitor/114505123093?hash=item1aa9098515:g:FewAAOSwxe9fprE 2
No parece traer 4 MB, pero no es el mayor de los problemas,
Se acaba de descubrir que configurando, en un registro más allá de los 14 MB que todos pensábamos que era el límite; el shifter del STE pasa a replicar las funcionalidades del Copper del Amiga (en lo que a modificación de la paleta de color se refiere), sin requerir la asistencia de la CPU.
En ese registro puedes escribir la dirección de memoria de una tabla que contenga una nueva paleta de 16 colores y la línea donde deseas que se produzca el cambio (son 32 bits, 24 de la dirección y 8 para la línea). Y ¡voila!, cuando llega esa línea los 16 colores del shifter cambian, dado que el shifter ha leído el solito (durante los blanking horizontales) los 16 colores nuevos durante la línea anterior, y al llegar la línea marcada se produce el swap de los 16 colores del shifter (el shifter del STE debe tener estos registros duplicados, y un contador de líneas para que pueda hacer esas comparaciones).
Hay tres modos de operación para esto:
1-) Puedes cambiar los 16 colores.
2-) Puedes configurarlo para cambiar y leer sólo el color de background; lo que te permitiría hacer gradientes de color
3-) Puedes cambiar 2 colores ¿? No sé para que sirve, pero esto lo hace necesitando sólo un único blanking horizontal, por lo que podrías cambiar un par de colores en todas las líneas.
WTF!?! Supongo que esto lo habrá comentado en algún chat interno o algo así, porque en Atari-forum no ha comentado nada.
-----Actualizado-----
Como sigan asi tal vez se encuentren de que tiene sprites por hardware XD
-----Actualizado-----
Si quieres uno, un STE funcionando, puedo mirártelo de gente decente del Reino Unido, donde hay muchos ST y STE, incluso hay mucho Falcon;
y te lo pueden dejar a un precio decente. Tampoco lo van a regalar, pero no te van a pedir 300€ ni 400€ como joyeros que acabo de ver; una vez encontrado te paso el contacto del guiri que encuentre,
En ebay acabo de ver éste que todavía está a precio razonable (ahora, a ver cuánto tarda en inflarse de precio):
https://www.ebay.es/itm/Atari-1040STE-boxed-and-working-Excellent-Condition-in-original-box-No-Monitor/114505123093?hash=item1aa9098515:g:FewAAOSwxe9fprE 2
No parece traer 4 MB, pero no es el mayor de los problemas,
Yo hace unos dias encontré uno que vendía un 520STE y un 1040STE franceses (teclado azerty), decía que no los había probado y no sabia si funcionaban, que los pillo en un rastro, la puja iba por 20€. En el anuncio ponía ST pero mirando las fotos ponía STE.
masteries
13/11/2020, 16:34
Voy a mirar cuanto valen antes de que suban de precio. :awesome:
-----Actualizado-----
Ya miré...
Os juro que me partiré de risa cuando nuestra generación chochee, nuestros hijos no quieran para nada nuestras mierdas ochenteras y los pootos especuladores se metan por el culo toda su especulación. :(
Un 520 STE por unos 100€; total sólo quedaría ampliarle la RAM a 4 MB
https://www.ebay.es/itm/ordinateur-vintage-ATARI-520ste-jeux-et-joystick/143830638827?_trkparms=aid%3D1110006%26algo%3DHOME SPLICE.SIM%26ao%3D1%26asc%3D20131231084308%26meid% 3D86fc64e4a0c547e5b9573408ea45da31%26pid%3D100010% 26rk%3D6%26rkt%3D12%26sd%3D143838243183%26itm%3D14 3830638827%26pmt%3D0%26noa%3D1%26pg%3D2047675%26al gv%3DDefaultOrganic%26brand%3DAtari&_trksid=p2047675.c100010.m2109
Le queda 1 hora a la puja,
-----Actualizado-----
WTF!?! Supongo que esto lo habrá comentado en algún chat interno o algo así, porque en Atari-forum no ha comentado nada.
-----Actualizado-----
Como sigan asi tal vez se encuentren de que tiene sprites por hardware XD
-----Actualizado-----
Yo hace unos dias encontré uno que vendía un 520STE y un 1040STE franceses (teclado azerty), decía que no los había probado y no sabia si funcionaban, que los pillo en un rastro, la puja iba por 20€. En el anuncio ponía ST pero mirando las fotos ponía STE.
Mira el anuncio, le queda 1 hora a la puja, y por aproximadamente 100€ está bastante bien.
Editado: -Es de coña... en el último momento se ha ido directamente a 200€ más envío xD
Mejor, si quereis uno, lo buscamos entre los coleguillas ingleses,
Lo otro, lo sé porque soy su betatester xD
fbustamante
13/11/2020, 21:16
Muchas gracias @masteries (https://www.gp32spain.com/foros/member.php?u=28729), pero por ahora voy a dejarlo.
Ya me gasté mi 'cuota' en el UMPC.
Visto los precios, al menos esperaré al año que viene, porque me iban a echar a los perros. :D
masteries
19/11/2020, 00:58
Flipemos un poco más...
Parallax con superposición y cambios dinámicos en las paletas de color (empleando las nuevas funciones similares al Copper de los Amigas):
https://www.youtube.com/watch?v=QxKVdhiuEic&feature=youtu.be
Zañó, dehe de emitir fakes a este rezpetable foro o zerá baneao de por bida [wei]
Juer, con tanto hackeo del HW del ordenador, prácticamente habéis conseguido que el Atari STE se parezca a su siguiente modelo. ¿Qué os queda ya para que parezca un ordenador de 16bits? ¿Que haga tostadas? :lol:
Enhorabuena :D
Ahora haced un juego :awesome:
masteries
19/11/2020, 10:31
Zañó, dehe de emitir fakes a este rezpetable foro o zerá baneao de por bida [wei]
Juer, con tanto hackeo del HW del ordenador, prácticamente habéis conseguido que el Atari STE se parezca a su siguiente modelo. ¿Qué os queda ya para que parezca un ordenador de 16bits? ¿Que haga tostadas? :lol:
Enhorabuena :D
Ahora haced un juego :awesome:
En eso estoy... he incorporado la funcionalidad de los mapas de durezas al engine (si, me las ingenio para que programar juegos ahí sea los más 1:1 a utilizar Fénix/Bennu xD );
claro que no se guarda la imagen en sí, sino sólo la información relevante... ahora, vaya dolor de cabeza que me ha supuesto optimizarlo, funciona en base a sólo seis comparaciones if-else,
54010
Pues precisamente en eso estaba yo pensando para un proyecto nuevo, en los mapas de durezas.
¿Cómo lo vas a hacer tú? ¿Dónde vas a poner el punto de control para detectar las durezas en los diferentes casos? Tengo una idea más o menos de cómo hacerlo, pero cuantas más vueltas le doy, más se complica, y no quiero hacerlo más complejo de lo necesario.
masteries
19/11/2020, 13:48
Pues precisamente en eso estaba yo pensando para un proyecto nuevo, en los mapas de durezas.
¿Cómo lo vas a hacer tú? ¿Dónde vas a poner el punto de control para detectar las durezas en los diferentes casos? Tengo una idea más o menos de cómo hacerlo, pero cuantas más vueltas le doy, más se complica, y no quiero hacerlo más complejo de lo necesario.
Pues haces bien en pensarlo, porque que funcione bien es bastante jo****.
A primera vista parece algo sencillo, pero se complica en extremo; porque el personaje puede estar saltando (se obvian los walkways), o en el suelo (tienes que comprobar en que walkway estás, si en el A (rojo) o si en el B (naranja), o cayendo (comprobando si estás por encima de B y entras dentro del rango de B; o de contrario comprobar sólo A).
He tenido que reescribirlo dos veces, ya te lo estás oliendo; porque aparecían comportamiento anómalos... o se complicaba el código... la versión que tengo ahora es relativamente sencilla; y para shooters horizontales o juegos tipo Mario / Sonic servirá bien. Más complejo sería un juego con muchos más walkways.
El punto de control está en los pies (y se comprueba un rango de 8 píxeles, 4 por arriba y 4 por debajo, para evitar no detectar la línea del walkway), de hecho las piernas son el sprite padre, y el torso es el hijo; el padre arrastra al hijo y le va cambiando el gráfico a mostrar, al cambiar valores de la estructura de datos asociada a cada sprite... igual que puedes hacer en Fénix/Bennu
Al final, todos los engines de juegos terminas haciendo que se parezcan a Fénix/Bennu, porque es la única forma lógica de no morir en el intento de hacer un videojuego xD
Yo he usado el mismo motor de detección de durezas desde los tiempos de FenixLand, pero claro, yo usaba tiles de durezas, en lugar de ir al pixel... luego resulta que tengo tiles de pared, en rampa, en medias rampas, techos inclinados... las combinaciones eran una exageración ¡Y eso que el prota sólo tenía 1 tile de altura! Incluso empecé a hacer una modificación para 2 tiles.
Luego pensé en eso, que lo que me ahorraba en Fenix/Bennu con el MAP_GET_PIXEL lo perdía en unos switchs enoooormes y le estoy dando vueltas a cómo simplificarlo.
Más que nada porque ahora quiero hacer un RPG en vista aérea, o algo así, con mapas de tiles de durezas con varias capas (en 3D por decirlo de alguna forma, es que quiero añadirle salto y movimiento a distintas alturas), y estoy mirando si puedo hacerlo con tiles o con algo híbrido entre tiles y píxels. La ventaja es que ahora sólo voy a tener 8 durezas de pared (y se repetirían por cada tipo de suelo) y eso simplifica mucho el algoritmo, pero claro, si el prota no está en el centro del tile, debería poder pararse ante una esquina, o no atravesar la pared con medio cuerpo por tener el punto de control entre los pies.
No sé si habrá en alguna parte una explicación sencilla de cómo se detectan las durezas o el sistema que use en el Super Mario Bros o Super Mario Bros 3.
¿Y no es mas fácil tener otro mapa de "tiles" que te diga el tipo de colisión que hay? Otra opción es tener definido unas cajas donde se colisiona, para las comprobaciones solo serán una restas.
¿Y no es mas fácil tener otro mapa de "tiles" que te diga el tipo de colisión que hay? Otra opción es tener definido unas cajas donde se colisiona, para las comprobaciones solo serán una restas.
De eso estoy hablando, de un mapa de tiles de durezas. Pero tengo 25 tipos de durezas diferentes (tile sólido, 2 rampas, 2 techos inclinados, 4 rampas de 22'5º, lo mismo pero pudiendo traspasar desde abajo hacia arriba pero no al revés...), y cuando se ha avanzado dentro de uno, empieza a afectarle el tile siguiente... y si tiene rampa también le afecta el de arriba, pero si el de abajo está vacío, también hay que tenerlo en cuenta. Las combinaciones se multiplican, y por eso el Echo tiene como 2000 líneas de código sólo para comprobar las durezas. Sólo se ejecutan 500 líneas en cada frame, pero ahí están escritas, cuando usando lo que propone Masteries no llegan a 200, pero el problema es que obtener el color de un pixel en un mapa en Fenix/Bennu tarda mucho, y con las durezas en tiles tengo el color de 16x16 o 32x32 pixels y puedo actuar en bloque y no punto a punto.
Pero a veces pienso que ir pixel a pixel sería más eficiente... no me cuadran las matemáticas.
Lo bueno de un juego en vista aérea es eso, que sólo tengo 6 durezas (sólido, sin dureza, y las 4 diagonales). Mucho más fácil. Si le sumamos que puedo ponerle un valor de forma que cada bit indique si un lado es traspasable o no, puedo reducir las comprobaciones usando máscaras binarias, e incluso aplicar efectos curiosos, como que me deje entrar desde la derecha pero no desde la izquierda :P
Creo que lo has complicado demasiado, la colisión con un tile no debería depender de lo que tiene alrededor.
Sí, cuando te acercas a sus límites, a no ser que no te importe que parte del personaje atraviese paredes o techos... o que dichos tiles de paredes o techos, en el mapa visible, no estén ocupando todo el tile, pero eso te complica mucho la creación de los tiles, sobre todo para las rampas.
O cuando cambias de tile. Por ejemplo, si estás en una rampa ascendente y te desplazas a la derecha, puede pasar que el próximo tile en el que acabes no sea el de la derecha, sino el de la derecha-arriba... pero si el tile de la derecha es una rampa descendente, sí que te vas a desplazar al tile de la derecha, contando con que el tile de la derecha-arriba te lo permita (que no sea una pared o una rampa ascendente) y ya suponiendo que el tile que tienes encima no sea de techo y te impida avanzar.
masteries
20/11/2020, 10:57
Un post cargado de humor :awesome:
He empezado a escribie en eab.abime...
me temo que van a suspender mi cuenta porque no se ajusta a las normas de ese foro, en dos condiciones:
-Religión: Me gustan los Amigas, pero no soy Amiguero de Pro; le rindo culto a Atari y me lo van a notar
-Racismo: Atento contra la supuesta supremacía Amiguera... no soy partidario de aquellos que hacen zas en toda la boca con solo pronunciar "Amiga"
jajaja xD
Yo creo que si lo divides por componentes/movimientos se queda el código bastante mas simple y claro. Para un plataformas de toda la vida, tienes 3 tipos de movimiento, caer, saltar, andar (izq/der). La idea seria:
Descompones el movimiento en vX y vY.
Si vX != 0 nos estamos moviendo hacia los lados => Guardo en una lista los tiles con los que puedo colisionar según la dirección (listaX).
Si vY != 0 estamos saltando/cayendo => Guardo en una lista los tiles con los que puedo colisionar (listaY)
Miro si hay algún elemento en listaX que me pueda hacer parar => vX = 0 ( en cuanto me encuentre con un elemento dejo de recorrer la lista)
Lo mismo para listaY => vY = 0
Mover personaje según vX y vY
En caso de encontrar una rampa a los lados solo tienes que modificar al coordenada Y, y en caso de caer tienes que hacer que coincida con la posición en la rampa.
masteries
20/11/2020, 16:56
Yo creo que si lo divides por componentes/movimientos se queda el código bastante mas simple y claro. Para un plataformas de toda la vida, tienes 3 tipos de movimiento, caer, saltar, andar (izq/der). La idea seria:
Descompones el movimiento en vX y vY.
Si vX != 0 nos estamos moviendo hacia los lados => Guardo en una lista los tiles con los que puedo colisionar según la dirección (listaX).
Si vY != 0 estamos saltando/cayendo => Guardo en una lista los tiles con los que puedo colisionar (listaY)
Miro si hay algún elemento en listaX que me pueda hacer parar => vX = 0 ( en cuanto me encuentre con un elemento dejo de recorrer la lista)
Lo mismo para listaY => vY = 0
Mover personaje según vX y vY
En caso de encontrar una rampa a los lados solo tienes que modificar al coordenada Y, y en caso de caer tienes que hacer que coincida con la posición en la rampa.
Un vídeo que me ha pedido el bueno de Douglas,
https://drive.google.com/file/d/1D8kWhG46fxeIHX5FmFRlygsFoTlkNYkI/view?usp=sharing
*****, y pensar que solo hay 16 colores en pantalla.
¿Libreria soporta que hay partes del decorado por encima del protagonista, o habría que hacerlo un poco a mano? por ejemplo, poniendo un sprite sobre el protagonista cuando este en determinada zona.
-----Actualizado-----
PD: no subas el video al foro de amiga que te banean XDXDXD
masteries
20/11/2020, 18:54
*****, y pensar que solo hay 16 colores en pantalla.
¿Libreria soporta que hay partes del decorado por encima del protagonista, o habría que hacerlo un poco a mano? por ejemplo, poniendo un sprite sobre el protagonista cuando este en determinada zona.
-----Actualizado-----
PD: no subas el video al foro de amiga que te banean XDXDXD
Eso lo estamos integrando ahora, son los foreground sprites; en un principio son sólo parte del decorado; pero cuando un sprite entre dentro del rectángulo de colisión, estos foreground se dibujarán como si fueran sprites; para intentar ahorrar el máximo de blitter posible.
Por las pruebas que he hecho, si no te pasas muchos con el número de ellos, ni se nota que están ahí.
Y si por ejemplo, los haces con un ancho múltiplo de 16 pixels, y no guardas ningún preescalado de ese gráfico (para que sólo se pueda dibujar en posiciones múltiplo de 16); pues entonces ya el engine ni siquiera tiene que limpiar los dirty rects, porque ese sprite no necesitaría limpiado.
Otra cosa que comentó DML en Atari Forum; ahora puedes elegir, al generar los gráficos de un sprite; si quieres generar los 16 preescalados, u 8, o 4, o 2. Y así tu sprite ocupa 16 veces menos, u 8 veces menos... ahora mismo como muchos sprites se mueven 2 pixels a la vez, o incluso 4 píxeles... pues he ahorrado muchísima memoria respecto de la demo mostrada; de hecho se ahorran 400 KB, que estoy utilizando para más sorpresas.
P.S. DML se ha puesto a recrear partes de R-Type lo más 1:1 posible a la versión arcade, incluso los lasers que rebotan, los fondos con parallax, el nivel de la nave gigante... supongo que habrás visto el vídeo suyo que puse en la página anterior xD
-Versión de la demo con destrucción del escenario:
54011
54012
Yo creo que si lo divides por componentes/movimientos se queda el código bastante mas simple y claro. Para un plataformas de toda la vida, tienes 3 tipos de movimiento, caer, saltar, andar (izq/der). La idea seria:
Descompones el movimiento en vX y vY.
Si vX != 0 nos estamos moviendo hacia los lados => Guardo en una lista los tiles con los que puedo colisionar según la dirección (listaX).
Si vY != 0 estamos saltando/cayendo => Guardo en una lista los tiles con los que puedo colisionar (listaY)
Miro si hay algún elemento en listaX que me pueda hacer parar => vX = 0 ( en cuanto me encuentre con un elemento dejo de recorrer la lista)
Lo mismo para listaY => vY = 0
Mover personaje según vX y vY
En caso de encontrar una rampa a los lados solo tienes que modificar al coordenada Y, y en caso de caer tienes que hacer que coincida con la posición en la rampa.
Eso es lo que hago, solo que yo divido el movimiento en 9 casos: cambio de tile en 8 posibles direcciones (según velx y vely), y movimiento dentro del mismo tile.
Es más, se puede dar la posibilidad de que, según el tile al que avances, cambies la dirección: usando los valores del teclado numérico como guía, donde 8 es movimiento hacia arriba, 6 a la derecha... Si tu movimiento es 6 y en tu actual posición hay una rampa ascendente, si a la derecha no hay un tile de suelo, comprobar movimiento hacia 9, en caso contrario, comprobar que 9 está libre (o que permite el paso, con un techo descendente, por ejemplo) para moverte hacia 6... pero si estás en suelo y la posición es libre, comprobar si 3 (tile de la derecha-abajo) permite el paso y cambiar el tipo de movimiento a 3...
Y eso es sólo una parte del código. Como digo todos los casos se contemplan, y el resultante es un mastodonte... pero puedo crear cualquier tipo de escenario sin límites, y salvo error, funciona perfectamente con cualquier combinación de durezas, para cualquier alto y ancho en pixel del prota o del objeto que sea.
Pero ya digo, necesito simplificar :S
Por cierto, Masteries, perdón por ensuciar tu hilo. Si lo crees conveniente, me abro un hilo aparte ;)
masteries
25/11/2020, 18:38
Aquí vamos, al autor de las AGT se le ha metido en la cabeza recrear la recreativa de R-Type... xD
Podemos ver varios planos de scroll, ya no sólo haciendo parallax, sino desplazándose verticamente entre ellos; haciendo las funciones de sprite gigante.
Los efectos de disparos de los lásers azules y rebotantes no están dibujados por el blitter; se ha añadido una capa invisible de mapa de caracteres; y para dibujar esos gráficos, se escribe texto en esas partes; lo curioso es que escribir texto en esa capa no exige usar el blitter, sólo marcar esas posiciones de 8x8, con un valos ASCII; y haber cambiado la representación de las letras por otros gráficos, el shifter del STE hace la composición de planos playfield + mapa de caracteres al crear la imagen.
Cuando me lo ha explicado me he quedado... Wooo!
Corre a 50 fps:
https://www.youtube.com/watch?v=D1oAdc6MjQM
Por lo que veo en el hilo es STe esta parejo en potencia con la mega drive y la snes, no como es ST a secas, que se queda por debajo.
Por lo que veo en el hilo es STe esta parejo en potencia con la mega drive y la snes, no como es ST a secas, que se queda por debajo.
Que va, ten en cuenta que la megadrive puedes poner mas colores en pantalla y que puedes mover eso y mas sin tener que calentarte la cabeza, estas rutinas están muy optimizadas, pero lo que esta claro es que la maquina da más de lo que se pensaba.
masteries
26/11/2020, 11:15
Por lo que veo en el hilo es STe esta parejo en potencia con la mega drive y la snes, no como es ST a secas, que se queda por debajo.
Con el esfuerzo titánico que se está haciendo, se acerca de mejor o peor manera a lo que estábamos acostumbrados a ver en una Mega Drive.
Pero que conste, que Mega Drive a nivel de hardware de vídeo es mucho más potente; pues dispone del chip de vídeo de una máquina arcade System 16; salvo porque le recortaron 2 paletas de 16 colores y redujeron a la mitad la RAM de vídeo.
Y aquí viene el gran problema de Mega Drive; se diseño para montar 128 KB de VRAM, y por abaratar lo dejaron en sólo 64 KB. De los cuales, te quedan 52 KB libres para gráficos; si deshechas el uso del segundo plano de scroll y otros detalles casi sin importancia, puedes llegar a disponer de 58 KB para gráficos. También estaréis pensando: ¿Qué importancia tiene si los datos están en una ROM? Pues, la ROM no es tán rápida; puedes obtener de ella unos 7 KB de gráficos nuevos por fotograma; así que te conviene poder tener bastantes sprites y gráficos ya cargados en la VRAM. Por ejemplo, el protagonista, los disparos y explosiones más pequeñas y comunes, te conviene tenerlas en la VRAM de Mega Drive, para que puedas dedicar el ancho de banda de esos 7 KB por fotograma para ir cargando y descargando los frames del resto de sprites; y también ir obteniendo nuevos gráficos del escenario.
Respecto a las paletas de color, Mega Drive dispone de 4 paletas de 16 colores de un repertorio de 512 y puede manejar 80 sprites de 32x32, 20 máximos por línea; la revisión de hardware de System 16 en la que se basa MD dispone de 6 paletas de 16 colores, de un repertorio de 4096 y 128 KB de VRAM, 128 sprites de 32x32 y 32 máximos por línea. Por lo demás son hardwares idénticos en rendimiento, capas de gráficos, nombres de los registros... el de MD algo recortado en prestaciones.
El Z80 de MegaDrive puede mezclar por software 4 voces PCM con sus 2 KB de RAM, y el 68000 puede acceder a toda la ROM y dispone de 64 KB listos para él. A este respecto la consola es fantástica, pero tenían que haberla dejado con 128 KB de VRAM. Que enseguida llegó Super NES con sus 128 KB (accesibles por el adaptador gráfico), su ROM (parte de ella también accesible por el adaptador gráfico) y 64 KB de frame buffer. Y también 64 KB para el chip de sonido; y con modos de color de 5,6 y 7 bits de profundidad de color por capa; los dos últimos admiten dos capas más los sprites. Sus 128 sprites en pantalla, de hasta 64x64 píxeles y 32 sprites máximos por línea. De verdad Nintendo no escatimó tanto como Sega, de origen trae 256 KB de RAM frente a los 130 KB de MD. Se nota que Sega en el diseño de MD, se fijó sólo en los 16 bits que ya había: Atari ST y Amiga; sin pensar en lo que estaba por llegar.
Como anécdota: En una nota que SEGA entregaba a los programadores de Atari ST/E y Amiga, Sega les decía que con su MD, se podía espejar horizontal y verticalmente los gráficos; porque sabían que esto era un dolor de cabeza muy grande en ST y Amiga, pues ambas máquinas carecen de algo tan básico, y que cuando dispones de 512 KB o 1 MB de RAM, te limita mucho.
Resumiendo que MD, pese a estar coja de VRAM, tiene un hardware muy bueno.
¿Por qué el STE le puede ir más o menos a la zaga? Porque sus 4 MB de RAM, son 4 MB de vídeo, o 4 MB de audio o 4 MB de lo que quieras... y te puedes permitir hacer virguerías; eso sí, como bien apuntaban, te sube la fiebre al currarte todo esto; lo bueno, que se está haciendo siguiendo el principio de DirectX, en forma de librerías que aportan funcionalidades fácilmente reutilizables, no hay nada ad-hoc.
Y con los últimos descubrimientos sobre su hardware oculto o desconocido, pues se le puede sacar más partido; entonces logras que se asemeje. Pero en sprites, ahora mismo estamos en 18 - 20 sprites de 32x32 manteniendo los 50 fps; los señores Anima y DML están trabajando en conjunto para alcanzar 22. Pero de ahí no creo que logre pasar, y eso gracias al blitter a 16 MHz que hereda de la serie Mega, y a que su RAM corre a 8 MHz frente a los 6 MHz de la RAM de Amiga, que de lo contrario no llegabas a esto ni de lejos.
"(En NeoGeo sucede algo parecido a MD con la VRAM, sólo tiene 64 KB, tienes que cargar todo lo que quieras mostrar en pantalla en esa memoria; y aunque el acceso al cartucho es de 10 MHz a 24 bits, la cantidad y detalle de los gráficos (recordemos que a menudo en NeoGeo, los fondos también están animados) es tan grande, que cuando se ralentiza no es por otra cosa, sino porque no le da el ancho de banda para cargar y descargar en esos 64 KB. Si tuviera 128 KB o 256 KB de VRAM, se mantendría a 60 fps todo el tiempo.)"
Parece que no es esta la explicación... ¿entonces los tirones a NeoGeo de dónde le vienen?
Editado: Por cierto, ¿cuántos sabíais que la MD puede manejar cartuchos de hasta 8 MB, así sin mapeadores raros ni trucos?
¿Y qué lo máximo que usaron fueron 5 MB en Super Street Fighter 2? ¿Y Super Nintendo puede manejar hasta 16 MB? ¿Pero lo máximo que usaron en SNES fueron 6 MB?
MD y SNES se quedaron con mucho que decir, porque en un cartucho de 8 MB en MD, te cabe un juegaco cargado de detalles y sonidos digitales; que lo más que nos enseñaron fueron unos pocos samples, pero de ahí a mezclar audio digital... como que nunca lo hicieron en MD.
yo pensaba que la megadrive podia manejar hasta 4MB, o sea 32 megabits. Es lo que siempre he leido en la documentacion que hay por internet. De hecho, el super street fighter 2 tiene un mapper porque tiene 40.
Y de snes siempre leí que 4 megabits. Por eso TODOS los cartuchos de snes tienen mapeadores. Que sentido tiene esto entonces si no los necesaitaban?
Y hombre... decir que supernintendo se quedó en unos pocos samples cuando todo su sonido era sampleado...
En NeoGeo sucede algo parecido a MD con la VRAM, sólo tiene 64 KB, tienes que cargar todo lo que quieras mostrar en pantalla en esa memoria; y aunque el acceso al cartucho es de 10 MHz a 24 bits, la cantidad y detalle de los gráficos (recordemos que a menudo en NeoGeo, los fondos también están animados) es tan grande, que cuando se ralentiza no es por otra cosa, sino porque no le da el ancho de banda para cargar y descargar en esos 64 KB. Si tuviera 128 KB o 256 KB de VRAM, se mantendría a 60 fps todo el tiempo.
Esto no es cierto, tiene 64kb de RAM, los gráficos los lee directamente de la ROM, no tienes que copiarlos a la VRAM, de la RAM solo lee la tabla de los sprites para saber donde ponerlos y que grafico usar.
La neo geo cada chip tiene su bus independiente, por eso los cartuchos son tan grandes, porque necesitan un bus para el 68000, otro para el z80, otro para el chip de sonido y otro para el gráfico.
Mola la lección de historia del HW. Gracias.
La cosa es que SNES está mejor construida porque, para empezar, tuvo 2-3 años para ver los fallos de MD y arreglarlos. Luego, la tecnología se abarató, y a lo mejor pudieron ponerle toda esa memoria extra sin encarecer el producto respecto a la competencia. Pero de todas formas, según he visto en vídeos, no todas las características de la Súper estaban disponibles a la vez, dependía mucho del modo gráfico, y a más virguerías gráficas por HW, menos colores y recursos se podían usar. A ver, que no soy un experto, pero al final el resultado no es tanto como se menciona a bombo y platillo, no podía usar todos los colores mientras tenía scroll parallax o las funciones esas de acceso directo a memoria.
Lo del tamaño del cartucho puede ser por lo dicho antes, el precio de las memorias. No llegué a vivir tan intensamente la época de SNES, pero en la de N64 veía cómo aumentaban los precios a medida que subían la capacidad de los cartuchos. De las 8500ptas de SM64 hasta las 12000ptas de Mario Party 3... y la locura vino de la mano de RE2, que si no me patinan las neuronas a estas horas, se subieron a la parra con un cartucho de ¿15000 ptas? ¿O fueron 12000ptas porque no perteneció al club de juegos de la última hormada? El caso es que era como 3000ptas más caro que el resto de juegos por tener esos 512 megabits (64 megabytes), el doble que cualquier otro.
Además, las Console Wars, las Bit Wars, que el ciclo de 5 años de vida llegaba a su fin, y probablemente, salvo lo que dices de los cartuchos, el resto del HW estaba ya exprimido y no se podía mejorar... a menos que hicieran como estáis haciendo con el Atari, y se sacasen de la manga trucos, pero los tiempos de desarrollo...
Volviendo al hilo:
Muy original la idea de usar los caracteres para dibujar los disparos :D
Claro que eso te limita la posición en la que se dibujan, y se nota con el disparo ese que sigue los contornos de la nave enemiga, pero es un muy buen compromiso de cara a hacer que funcione todo con tan pocos recursos.
muy cierto lo que dice drumpi. El precio de las memorias era altisimo en la epoca. No era tan sencillo meter megas y megas a un cartucho por mucho que la maquina lo permitisese.
masteries
26/11/2020, 12:36
yo pensaba que la megadrive podia manejar hasta 4MB, o sea 32 megabits. Es lo que siempre he leido en la documentacion que hay por internet. De hecho, el super street fighter 2 tiene un mapper porque tiene 40.
Y de snes siempre leí que 4 megabits. Por eso TODOS los cartuchos de snes tienen mapeadores. Que sentido tiene esto entonces si no los necesaitaban?
Y hombre... decir que supernintendo se quedó en unos pocos samples cuando todo su sonido era sampleado...
Hablaba de MegaDrive, que también podía;
Lo del límite de 4 MB en MD es porque los otros 4 MB son para comunicarse con el 32x, el Sega CD, o el chip 3D del Virtua Racing.
Si pones un cartucho con 8 MB, no puedes tener conectado el 32x o el Sega CD. Por eso Super Street Fighter lleva mapeador, para no montar ese MB extra en los otros 4 MB.
Sobre los mapeadores de SNES... a ver es un sistema muy japonés... les gusta complicarlo todo al extremo (recuerdo que cuando viví allí, para poder poner el aire acondicionado en marcha le tenías que indicar al aparato el ratio o ritmo al que querías que deshumedeciera el aire, que sin instrucciones así se negaba a arrancar, y para poner en marcha la lavadora ya ni os cuento...). Como algunos de sus chips pueden acceder a la ROM, resulta que sólo pueden hacerlo a ciertas partes... mientras que el programa hay que leerlo de forma lineal y puede solapar con unos u otros espacios y esto no puede ser; entonces hay muchos esquemas de memoria dentro de los comunes LoROM y HiROM... y los mapeadores están para eso, para saber quién está accediendo y redirigir.
En MD se complicaron menos la vida, un espacio de 8 MB y las expansiones... pues en los 4 MB de más allá. Lo lógico en SNES habría sido hacer como estos señores de SEGA, el espacio de 16 MB y como tienes chips que pueden acceder, pues te dejas 4 MB para CPU, otros tantos MB para que puedan acceder los chips gráficos, otro para el de sonido... e intentas que no solapen ni cosas raras y cuando rutas la ROM puedes disponer las direcciones de esa forma... pero en realidad está como mezclado todo, que si 256 KB de esto, y luego 512 KB para los otros seguidos de 1 MB para ROM... de ahí los mapeadores. En snes es muy raro todo, demasiado japonés xD
Este último ejemplo no es exacto, pero viene a ser lo que hay cuando te encuentras un esquema completo de los 16 MB
Por cierto, me comentaron, que los esquemas de memoria para el ensamblador de SNES te los vendía Nintendo aparte del SDK; así que antes de empezar con tu juego, tenías que darle la pensada de cómo ibas a estructurar la ROM y tal. Y si luego resulta que te quedabas corto de gráficos, o de sonido... pues te aguantabas.
-----Actualizado-----
Esto no es cierto, tiene 64kb de RAM, los gráficos los lee directamente de la ROM, no tienes que copiarlos a la VRAM, de la RAM solo lee la tabla de los sprites para saber donde ponerlos y que grafico usar.
La neo geo cada chip tiene su bus independiente, por eso los cartuchos son tan grandes, porque necesitan un bus para el 68000, otro para el z80, otro para el chip de sonido y otro para el gráfico.
¿Entonces sus tirones cómo se explican? Hasta ahora me los explicaba de esta forma, porque parece todo coherente; pero ahora no veo la razón de los tirones en NeoGeo.
-----Actualizado-----
muy cierto lo que dice drumpi. El precio de las memorias era altisimo en la epoca. No era tan sencillo meter megas y megas a un cartucho por mucho que la maquina lo permitisese.
Si, esa debe ser la explicación para ahorrar 64 KB de VRAM en MD, e intentar que todos los cartuchos andasen en torno a 1 o 2 MB; porque los de 3 o 4 MB eran menos comunes.
Como ahora, que nos columpiamos con los 4 MB de un STE; pero en su día sólo conocí unos pocos STE con esa cantidad de memoria instalada; y los usaban profesionales del mundo musical y diseño de PCBs para electrónica; esa cantidad de memoria no era para jugar precisamente.
¿Entonces sus tirones cómo se explican? Hasta ahora me los explicaba de esta forma, porque parece todo coherente; pero ahora no veo la razón de los tirones en NeoGeo.
Porque no les dara tiempo a mover todo (ejecutar la lógica del juego) en un frame.
masteries
26/11/2020, 13:03
La cosa es que SNES está mejor construida porque, para empezar, tuvo 2-3 años para ver los fallos de MD y arreglarlos. Luego, la tecnología se abarató, y a lo mejor pudieron ponerle toda esa memoria extra sin encarecer el producto respecto a la competencia. Pero de todas formas, según he visto en vídeos, no todas las características de la Súper estaban disponibles a la vez, dependía mucho del modo gráfico, y a más virguerías gráficas por HW, menos colores y recursos se podían usar. A ver, que no soy un experto, pero al final el resultado no es tanto como se menciona a bombo y platillo, no podía usar todos los colores mientras tenía scroll parallax o las funciones esas de acceso directo a memoria.
Te puedo decir que programar para MD mola bastante, y no te ves limitado a ese respecto; todo lo que hay lo puedes usar. Luego ya si el ancho de banda se te queda algo corto, o te falta VRAM; pues te vas apañando.
En SNES y Amiga hay muchas cosas que son muy ad-hoc; te las tienes que currar muchísimo y luego resulta que no puedes reutilizarlas en otras partes o en otros juegos.
Según comentan los que trabajaron con ambos sistemas, que era complicado construirte un engine reutilizable que aprovechara mucho de la máquina.
Sí, he visto que SNES se complicaban mucho con la memoria.
https://www.youtube.com/watch?v=-U76YvWdnZM
https://www.youtube.com/watch?v=PvfhANgLrm4
De hecho, me ha costado mucho seguir estos vídeos, convirtiendo valores a binario y demás. No sé exactamente qué HW tiene que acceder a qué partes del cartucho pero ¿eso no es configurable? ¿No usan el mismo bus de direcciones para acceder a los datos del cartucho? ¿Los puertos del cartucho no te dan igual si están conectados todos a una ROM, o al SuperFX o a cualquier chip, ya que es el código el que decide cómo tratar la información que se le pasa o la que contiene?
Es más, si era Nintendo quien suministraba los cartuchos ¿cómo les explicabas que necesitabas una configuración específica de HW dentro del cartucho? ¿O que tenían que añadir tal chip especial, como el de descompresión de datos ese del SF2?
Tiene que ser divertido poder programar en ASM para un aparato de estos, ya sea MD, SNES o Amstrad CPC :D, y tener el control total de todo el HW. Lo que pasa es que se necesita tiempo para aprender todas las partes del HW, los comandos en ensamblador, experimentar, poder diseñar tus propios cartuchos de memoria con HW extra... Ojalá tuviera tiempo :D
Respecto a los precios de las memorias, creo recordar que fue por esa época que hubo escasez de chips en todo el mundo y se dispararon. No recuerdo si fue al principio de la salida de MD o de la siguiente generación, pero se juntaron el hambre con las ganas de comer.
masteries
27/11/2020, 16:16
Avances técnicos:
El colega Anima, descubrió una forma de usar el blitter que ahorra un 25% de ciclos de reloj necesarios cada 16 pixels.
En la colaboración conjunta de Anima y DML, han llegado a un formato de sprites en el que se pueden agrupar múltiplos de 16 pixels; aunque estén desplazados, para que todo el conjunto ahorre un 25% de tiempo.
En este sprite se ahorra una barbaridad de tiempo:
54038
Todas las secciones de 16 pixels de longitud (los trocitos como este :1111111111111111: ) ahorran ahora un 25%, junto a que los píxeles utilizados en muchas líneas suman un múltiplo de 16 píxels; tienes que puedes llegar a ahorrar en torno al 30% del tiempo que antes hacía falta para pintar el mismo sprite.
También se ha mejorado el proceso de limpiado:
-Si hasta ahora también se comprobaba si un tile del escenario estaba oculto y seguía oculto para no redibujarlo; ahora aquellos tiles (de 16x16) que hay que volver a pintar, no tienen porque ser repintados por completo, sino que puede repintarse 1/3 del mismo, o 2/3 o el tile completo. De forma que se ahorre más tiempo al limpiar el fotograma anterior.
Cielos, que pasada de explicaciones Masteries!
Aqui somos todos lo suficientemente geeks para saber mas o menos de donde viene la mega y su comparacion con system 16 con sus ventajas y sus inconvenientes, pero leerte esa master class técnica es una pasada.
fbustamante
27/11/2020, 21:21
¿Me podrías explicar, intentando que me entere, cómo se descubren las nuevas funciones? :D
Porque en mi corto ensamblador del z80 no se me ocurre nada para ver si el Z80 tiene funciones indocumentadas. :(
Para descubrir registros no documentados lo normal es ponerse a escribir valores en zonas correspondientes a los registros a ver si pasa algo.
z80 tiene bastantes instrucciones no documentadas y son bastante útiles, ya se sabían en la época del spectrum.
http://www.myquest.nl/z80undocumented/ (http://www.myquest.nl/z80undocumented/)
Para descubrir registros no documentados lo normal es ponerse a escribir valores en zonas correspondientes a los registros a ver si pasa algo.
z80 tiene bastantes instrucciones no documentadas y son bastante útiles, ya se sabían en la época del spectrum.
http://www.myquest.nl/z80undocumented/ (http://www.myquest.nl/z80undocumented/)
Si lo he entendido bien, es como si te ponen a manejar una máquina que se controla con un monton de palancas que se pueden poner en varias posiciones, y te dan un manual de uso, pero te das cuenta de que el manual que te han dado no cubre todas las combinaciones de palancas y posiciones, entonces tu simplemente pruebas que pasa poniendo las palancas en esas posiciones que no vienen en el manual, observas que hace la máquina y deduces la funcionalidad de esas palancas por el funcionamiento de la máquina al accionarlas.
Lo que no me queda claro es si el z80 estaba diseñado así y no se documentaron esas funciones por algún motivo, o si simplemente algunas de esas funciones son "accidentes afortunados" que ocurren al dar una entrada que no se tuvo en cuenta durante el diseño de la circuitería, pero que da una salida predecible y util.
En el caso del Z80 son códigos de instrucciones que no estaban implementados, y el decodificador se "liaba" y mandaba señales "raras", algunas de las instrucciones tienen poco uso, pero al parecer hay otras que te hacen desplazamientos hacia los lados pero te meten unos en vez de ceros, lo que viene bien en algunos casos para los gráficos. En la revista microhobby daban unas fichas con cada intruccion del z80 y como funcionaba y estas instrucciones estaban comentadas.
Respecto a registros indocumentados en un foro unos programadores franceses descubrieron que en la Jaguar si escribías en un registro, los graficos en formato CrY (chroma/color + intensidad) no hacia caso de la parte del color, por lo que te salían los graficos en blanco y negro (bueno, en una escala de grises), supongo que lo usarían para depurar el hardware y después no lo documentaron por verlo de poca utilidad. Lo descubrieron escribiendo valores aleatorios en las zonas donde no hay ningún registro hardware documentado.
En otros casso es "engañar" al hardware, por ejemplo cuando se abren los bordes en un ST. La cosa funciona así, el shifter va contando por que linea de pantalla va (se cuentan todas no solo las 200 donde puedes dibujar), cuando llega a la linea 250 (no se el numero exacto) y estamos en 60hz, baja la señal dibujar los pixels (a partir de ahi empieza el borde), si llega a la linea 260 y esta en 50Hz baja la misma señal... sabiendo esto la forma de abrir el borde de abajo es poner una interrupción en la linea 260 y ponemos 60hz (la condición no se cumple y seguirá dibujando), esperamos a que llegue la linea 261 y volvemos a poner 50Hz, a partir de ahi tendremos graficos en las lineas correspondientes al borde de abajo (es el mas fácil e intuitivo de abrir).
masteries
17/12/2020, 16:46
Para que la cosa no decaiga...
los ejércitos de Morden ya se empiezan a pasear a pie por los territorios del Atari STE:
54073
54074
En esta última hemos cazado a un soldado dando un culatazo a Marco,
¿Por que el helicóptero y el avión no tienen dithering? ¿Da mucho el cante en movimiento o no se aprecia tanto como en una captura?
masteries
18/12/2020, 09:41
¿Por que el helicóptero y el avión no tienen dithering? ¿Da mucho el cante en movimiento o no se aprecia tanto como en una captura?
Porque al crear los sprites se puede elegir que sean dualfield (lo que hace que ocupen el doble, pues para mostrarse correctamente necesitas verlos mezclados con su complementario), o sean singlefield (no usen complementario, y se apañe con los pocos colores que pueda).
En primera instancia pruebo los sprites en modo normal de toda la vida sin dithering, luego con dithering y por último si se siguen viendo mal, pues paso a dualfield.
Por ejemplo, tanto el helicóptero, como el avión, como Marco se ven bien sin usar complementarios; en cambio los soldados ganan colorido...
ya sabéis que las capturas de un sólo fotograma no permiten mostrar el coloreado dualfield; cuando juegas, el fúsil de los soldados se ve de color marrón; cuando en realidad es una combinación de rojo + un color bastante oscuro (en un fotograma) + un color mucho más claro (en el otro fotograma) y el resultado sale marrón. Pero ocupa más memoria por necesitar un segundo fotograma (aunque esto se solucionó en gran medida al guardar sólo los predesplazamientos que se van a utilizar). El mapeado completo emplea esta técnica, pero el mapeado ocupa menos al no haber predesplazamientos.
De todas formas, aparte del colorido; se está avanzando mucho en el dibujado de los sprites; ahora se está llegando a burradas como mostrar un sprite de 256x128 píxeles consumiendo 2/3 del tiempo disponible en un fotograma.
masteries
17/01/2021, 17:16
Para que veáis que esto continúa en marcha,
Una prueba con el nuevo formato de sprites EMX2, junto con el nuevo sistema de control sobre el limpiado de los gráficos.
Ahora puedes decidir cuando un gráfico limpia su fotograma anterior o no; y puedes activar un sistema de limpiado más óptimo para sprites que se desplazan de maneras sencillas; por ejemplo el tanque. Este gráfico se desplaza sólo en línea recta de derecha a izquierda, por lo tanto sólo limpia el mínimo rastro que va dejando tras de sí, sin tocar el resto. También cuando está quieto, desactivo por código el limpiado
y cuando explota tampoco lo limpio, es el gráfico de la explosión quien limpia el tanque, y aún la explosión no la limpio hasta su quinto fotograma, donde empieza a disminuir de tamaño y ya tienes que limpiar los restos del cuadro anterior.
La explosión pequeña, igual, sólo se activa su limpiado cuando sus fotogramas dejan de crecer en tamaño; y también se desactiva el limpiado de los gráficos que permanecen quietos y sin cambiar de fotograma (esto ya lo hace le engine de forma automática).
Con esto se ha logrado mostrar cantidades ingentes (para un STE) de sprites en pantalla sin que caiga de los 50 cuadros por segundo.
En esta imagen hay el equivalente a unos 28 sprites de 32x32, y como se aprecia (el color verde representa el tiempo que queda sin usar) se podría mostrar otro soldado enemigo (con su código IA, bueno son patrones pseudo aleatorios, ejecutándose también), y un soldado enemigo son dos sprites de 32x32. Lo que hace un total de 30 sprites (de 32x32) a 50 fps en color dualfield.
54149
mills332
23/01/2021, 12:02
Que burrada cuantos sprites :). Hay alguna demo que se pueda testear con las últimas mejoras?.
masteries
23/01/2021, 14:10
Que burrada cuantos sprites :). Hay alguna demo que se pueda testear con las últimas mejoras?.
Pues os puedo subir la versión actual, estoy trabajando en tener lista la primera misión de Metal Slug;
pero antes le coloco unos cuantos generadores de soldados enemigos en los sitios precisos,
y programo también una tecla con la que podáis generar un soldado aleatorio cada vez que pulseis dicha tecla.
Hoy mismo he estado probando esta versión en la máquina actual (a mi mismo me resulta impresionante que se mueva tan ágil, aceleré los movimientos de todos los sprites, scroll, y tasa de disparos para asemejarlo al original), con una interfaz de disco duro que he estado construyendo esta semana; la interfaz es todo un éxito, compatible con todo tipo de tarjetas SD (desde SD antiguas, pasando por 4 GB normales, 4 GB SDHC, 8 GB SDHC... ninguna me ha dado problemas; tasa de lectura al carga los 3,5 MB de Metal Slug de 300 KB/s, ha tardado 12 segundos en cargar, y aún cuando cargas un sprite la CPU tiene que moverlo del buffer temporal, el segundo buffer de vídeo, a otra parte de la RAM).
masteries
03/02/2021, 20:44
Un update de cómo progresa Metal Slug en STE.
Ahora también desde disco duro:
https://www.youtube.com/watch?v=uRT_0jq9o8w&feature=emb_logo
mills332
05/02/2021, 12:00
No se si me perdí algo, pero no entiendo como suena tan bien, no tenia ese pc un sonido mas simple?
Tiene un Yamaha 2149 (ST) y dos DAC de 8 bits (STE)
masteries
05/02/2021, 13:27
No se si me perdí algo, pero no entiendo como suena tan bien, no tenia ese pc un sonido mas simple?
Si, parece que te perdiste algo, y gordo.
El sonido que estás escuchando, aparte de ser los samples originales de NeoGeo, proviene de un mezclador software escrito en ensamblador, me costó bastante conseguir que no colgase el ordenador xD y manejarme con el ensamblador de 68k también, tiene sus cosillas.
El mezclador te permite reproducir a la vez varios sonidos digitales .WAV de 8 bits a una frecuencia de 12,5 KHz. Aunque la salida puede ser estéreo, el mezclador sólo produce salida mono. También el mezclador presenta funcionalidades completas; puedes reproducir un sonido en bucle, detener o pausar un sonido, reemplazar un sonido por otro, o reproducir los WAV a partir de una partitura. Esto último es la manera en que se está gestionando la música; estando la música compuesta de diferentes sonidos .WAV, en los que el primer sonido se reproduce tantas veces seguidas, después se reproduce el segundo sonido tantas veces... o se reproduce el sonido cuarto y quinto varias veces antes de pasar al sexto... y volver al principio.
Es todo sonido digitalizado que sale por la salida digital-analógica del STE (como ya te han comentado); elemento hardware del que no se dispone en un ST. Como ventaja adicional, a esa salida de sonido analógica no tienes que alimentarla con el procesador; funciona por DMA; las muestras de sonido ya mezcladas le van llegando al conversor DAC, sin necesitar el concurso de la CPU . Mientras que el Yamaha2149F lo tienes que alimentar con la CPU; también se puede lograr reproducir sonido .WAV a través del Yamaha, pero necesitarías alimentarlo con señales PWM a 4 veces la frecuencia deseada; se comería la CPU.
Para terminar, no utilizo el Yamaha para nada; sólo utilizo la salida DAC.
masteries
16/03/2021, 14:37
Se ha optimizado el proceso de limpiado de los gráficos de muy gran tamaño; ahora se emplea un 20% menos de tiempo en limpiar el escenario "manchado" por estos sprites gigantescos.
Lo que permite llegar a meter en 50 fotogramas por segundo: El jefe gigantesco, los dos sprites del jugador, los dos sprites del soldado enemigo, la explosión de la bomba del avión, el avión con su bomba (son dos sprites), y apurando al máximo te llega a caber también el sprite del tanque. Y todo moviéndose,
54413
54414
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.