User Tag List

Página 3 de 4 PrimerPrimer 1234 ÚltimoÚltimo
Resultados 31 al 45 de 53

Tema: Cuando un Atari STE se cree una NeoGeo

  1. #31

    Fecha de ingreso
    Oct 2007
    Ubicación
    Madrid
    Mensajes
    2,739
    Mencionado
    79 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    162
    Agradecer Thanks Received 
    406
    Thanked in
    Agradecido 244 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por mills332 Ver mensaje
    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.
    Última edición por masteries; 13/07/2020 a las 10:43

  2. #32

    Fecha de ingreso
    Oct 2012
    Mensajes
    190
    Mencionado
    1 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    1
    Agradecer Thanks Received 
    77
    Thanked in
    Agradecido 30 veces en [ARG:2 UNDEFINED] posts
    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.

  3. #33

    Fecha de ingreso
    Oct 2007
    Ubicación
    Madrid
    Mensajes
    2,739
    Mencionado
    79 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    162
    Agradecer Thanks Received 
    406
    Thanked in
    Agradecido 244 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por mills332 Ver mensaje
    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".

  4. #34

    Fecha de ingreso
    Oct 2012
    Mensajes
    190
    Mencionado
    1 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    1
    Agradecer Thanks Received 
    77
    Thanked in
    Agradecido 30 veces en [ARG:2 UNDEFINED] posts
    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).

  5. #35

    Fecha de ingreso
    Oct 2007
    Ubicación
    Madrid
    Mensajes
    2,739
    Mencionado
    79 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    162
    Agradecer Thanks Received 
    406
    Thanked in
    Agradecido 244 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por mills332 Ver mensaje

    ¿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.

  6. #36

    Fecha de ingreso
    Sep 2006
    Mensajes
    5,334
    Mencionado
    31 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    781
    Agradecer Thanks Received 
    766
    Thanked in
    Agradecido 556 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por masteries Ver mensaje
    En el STE real utilizo disquetes; otros desarrolladores tienen discos duros físicos conectados.
    Pillate un SatanDisk
    http://joo.kie.sk/?page_id=55
    No es lo mismo tener diez años de experiencia, que tener un año de experiencia diez veces.

  7. #37

    Fecha de ingreso
    Oct 2007
    Ubicación
    Madrid
    Mensajes
    2,739
    Mencionado
    79 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    162
    Agradecer Thanks Received 
    406
    Thanked in
    Agradecido 244 veces en [ARG:2 UNDEFINED] posts
    ¡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.


    Nombre:  SAM_3433.JPG
Visitas: 87
Tamaño: 291.0 KB
    Nombre:  SAM_3434.JPG
Visitas: 87
Tamaño: 269.7 KB
    Nombre:  SAM_3435.JPG
Visitas: 84
Tamaño: 255.3 KB

    Nombre:  SAM_3436.JPG
Visitas: 89
Tamaño: 266.7 KB

    Nombre:  SAM_3437.JPG
Visitas: 88
Tamaño: 268.3 KB

    Nombre:  SAM_3438.JPG
Visitas: 91
Tamaño: 249.4 KB


    La foto para los escépticos, sí es un ST/E; este mismo scroll con la técnica multicolor también funciona en ST

    Nombre:  SAM_3441.JPG
Visitas: 99
Tamaño: 160.6 KB

  8. Los siguientes 4 usuarios agradecen a masteries este post:

    fbustamante (16/07/2020), Karkayu (15/07/2020), selecter25 (16/07/2020), swapd0 (16/07/2020)

  9. #38

    Fecha de ingreso
    Sep 2005
    Mensajes
    11,890
    Mencionado
    185 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    264
    Agradecer Thanks Received 
    650
    Thanked in
    Agradecido 459 veces en [ARG:2 UNDEFINED] posts
    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.


    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 ).
    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.
    PROYECTOS REALIZADOS: FrikiMusic, Motor Scroll Tileado v3.2, Venturer2X (GP2X/WIZ), Echo, Screen Break Time
    PROYECTOS EN MARCHA (algunos): Bennu GP2X: 95% (necesito ayuda) ¡Antes de Halloween!: 92% SpaceH2H: 8%

  10. #39

    Fecha de ingreso
    Sep 2009
    Ubicación
    Donde quiero
    Mensajes
    5,210
    Mencionado
    136 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    1,368
    Agradecer Thanks Received 
    1,584
    Thanked in
    Agradecido 919 veces en [ARG:2 UNDEFINED] posts
    Majia

  11. #40

    Fecha de ingreso
    Sep 2006
    Mensajes
    5,334
    Mencionado
    31 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    781
    Agradecer Thanks Received 
    766
    Thanked in
    Agradecido 556 veces en [ARG:2 UNDEFINED] posts
    ¿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?
    No es lo mismo tener diez años de experiencia, que tener un año de experiencia diez veces.

  12. #41

    Fecha de ingreso
    Oct 2007
    Ubicación
    Madrid
    Mensajes
    2,739
    Mencionado
    79 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    162
    Agradecer Thanks Received 
    406
    Thanked in
    Agradecido 244 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por swapd0 Ver mensaje
    ¿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-----

    Cita Iniciado por Drumpi Ver mensaje
    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.


    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 ).
    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.
    Última edición por masteries; 17/07/2020 a las 13:24

  13. Los siguientes 2 usuarios agradecen a masteries este post:

    fbustamante (17/07/2020), selecter25 (18/07/2020)

  14. #42

    Fecha de ingreso
    Sep 2006
    Mensajes
    5,334
    Mencionado
    31 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    781
    Agradecer Thanks Received 
    766
    Thanked in
    Agradecido 556 veces en [ARG:2 UNDEFINED] posts
    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.
    No es lo mismo tener diez años de experiencia, que tener un año de experiencia diez veces.

  15. #43

    Fecha de ingreso
    Oct 2012
    Mensajes
    190
    Mencionado
    1 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    1
    Agradecer Thanks Received 
    77
    Thanked in
    Agradecido 30 veces en [ARG:2 UNDEFINED] posts
    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.

  16. #44

    Fecha de ingreso
    Sep 2006
    Mensajes
    5,334
    Mencionado
    31 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    781
    Agradecer Thanks Received 
    766
    Thanked in
    Agradecido 556 veces en [ARG:2 UNDEFINED] posts
    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.
    No es lo mismo tener diez años de experiencia, que tener un año de experiencia diez veces.

  17. #45

    Fecha de ingreso
    Apr 2003
    Ubicación
    HACAPULCO (MEHICO)
    Mensajes
    60,518
    Mencionado
    124 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    359
    Agradecer Thanks Received 
    3,116
    Thanked in
    Agradecido 1,934 veces en [ARG:2 UNDEFINED] posts
    Entradas de blog
    24
    Cita Iniciado por mills332 Ver mensaje
    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.

Página 3 de 4 PrimerPrimer 1234 ÚltimoÚltimo

Permisos de publicación

  • No puedes crear nuevos temas
  • No puedes responder temas
  • No puedes subir archivos adjuntos
  • No puedes editar tus mensajes
  •