User Tag List

Página 4 de 5 PrimerPrimer 12345 ÚltimoÚltimo
Resultados 46 al 60 de 71

Tema: Cuando un Atari STE se cree una NeoGeo

  1. #46

    Fecha de ingreso
    Sep 2005
    Mensajes
    12,096
    Mencionado
    190 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    290
    Agradecer Thanks Received 
    710
    Thanked in
    Agradecido 505 veces en [ARG:2 UNDEFINED] posts
    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.
    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%

  2. #47

    Fecha de ingreso
    Oct 2007
    Ubicación
    Madrid
    Mensajes
    2,772
    Mencionado
    80 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    164
    Agradecer Thanks Received 
    438
    Thanked in
    Agradecido 255 veces en [ARG:2 UNDEFINED] posts
    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


    Última edición por masteries; 07/10/2020 a las 14:09

  3. Los siguientes 5 usuarios agradecen a masteries este post:

    fbustamante (22/07/2020), Karkayu (22/07/2020), romeroca (22/07/2020), selecter25 (22/07/2020), swapd0 (22/07/2020)

  4. #48

    Fecha de ingreso
    Feb 2005
    Ubicación
    Málaga
    Mensajes
    1
    Mencionado
    0 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    0
    Agradecer Thanks Received 
    0
    Thanked in
    Agradecido 0 veces en [ARG:2 UNDEFINED] posts
    Esté muy currado. Ya quisiera yo saber hacer eso

  5. #49

    Fecha de ingreso
    Sep 2005
    Mensajes
    12,096
    Mencionado
    190 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    290
    Agradecer Thanks Received 
    710
    Thanked in
    Agradecido 505 veces en [ARG:2 UNDEFINED] posts
    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.
    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%

  6. #50

    Fecha de ingreso
    Sep 2006
    Ubicación
    Malaga
    Mensajes
    5,443
    Mencionado
    33 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    820
    Agradecer Thanks Received 
    807
    Thanked in
    Agradecido 585 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por Drumpi Ver mensaje
    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.
    No es lo mismo tener diez años de experiencia, que tener un año de experiencia diez veces.

  7. #51

    Fecha de ingreso
    Sep 2006
    Ubicación
    Malaga
    Mensajes
    5,443
    Mencionado
    33 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    820
    Agradecer Thanks Received 
    807
    Thanked in
    Agradecido 585 veces en [ARG:2 UNDEFINED] posts
    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.
    No es lo mismo tener diez años de experiencia, que tener un año de experiencia diez veces.

  8. #52

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


    Código:
    (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.
    Última edición por masteries; 23/07/2020 a las 19:33

  9. Los siguientes 3 usuarios agradecen a masteries este post:

    fbustamante (23/07/2020), Karkayu (23/07/2020), selecter25 (23/07/2020)

  10. #53

    Fecha de ingreso
    Sep 2006
    Ubicación
    Malaga
    Mensajes
    5,443
    Mencionado
    33 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    820
    Agradecer Thanks Received 
    807
    Thanked in
    Agradecido 585 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por masteries Ver mensaje
    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.
    Última edición por swapd0; 23/07/2020 a las 20:24
    No es lo mismo tener diez años de experiencia, que tener un año de experiencia diez veces.

  11. #54

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

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

    chipan (11/08/2020), fbustamante (10/08/2020), romeroca (12/08/2020), swapd0 (10/08/2020)

  13. #55

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

  14. #56

    Fecha de ingreso
    Oct 2007
    Ubicación
    Madrid
    Mensajes
    2,772
    Mencionado
    80 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    164
    Agradecer Thanks Received 
    438
    Thanked in
    Agradecido 255 veces en [ARG:2 UNDEFINED] posts
    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:

    Última edición por masteries; 08/10/2020 a las 02:09

  15. Los siguientes 9 usuarios agradecen a masteries este post:

    chipan (10/10/2020), dj syto (08/10/2020), Drumpi (08/10/2020), fbustamante (08/10/2020), Kabanya (08/10/2020), Karkayu (08/10/2020), romeroca (10/10/2020), selecter25 (08/10/2020), swapd0 (08/10/2020)

  16. #57

    Fecha de ingreso
    Apr 2003
    Ubicación
    HACAPULCO (MEHICO)
    Mensajes
    60,573
    Mencionado
    124 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    364
    Agradecer Thanks Received 
    3,147
    Thanked in
    Agradecido 1,957 veces en [ARG:2 UNDEFINED] posts
    Entradas de blog
    24
    que maravilla.

  17. #58

    Fecha de ingreso
    Sep 2006
    Ubicación
    Zaragoza
    Mensajes
    1,168
    Mencionado
    5 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    1,143
    Agradecer Thanks Received 
    94
    Thanked in
    Agradecido 76 veces en [ARG:2 UNDEFINED] posts
    Sorpendido me quedo con lo que estás haciendo. Enhorabuena.
    "256K son suficientes para cualquier tarea" Bill Gates

  18. #59

    Fecha de ingreso
    Oct 2003
    Mensajes
    178
    Mencionado
    0 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    0
    Agradecer Thanks Received 
    0
    Thanked in
    Agradecido 0 veces en [ARG:2 UNDEFINED] posts
    Impresionante.
    Los videojuegos no afectan a los niños. Si fuera así y el Comecocos nos hubiera afectado a nosotros cuando éramos niños, ahora estaríamos deambulando por lugares oscuros, comiendo píldoras mágicas y escuchando ritmos electrónicos repetitivos.

  19. #60

    Fecha de ingreso
    Oct 2007
    Ubicación
    Madrid
    Mensajes
    2,772
    Mencionado
    80 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    164
    Agradecer Thanks Received 
    438
    Thanked in
    Agradecido 255 veces en [ARG:2 UNDEFINED] posts
    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


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

    Drumpi (19/10/2020), fbustamante (17/10/2020), Kabanya (18/10/2020), Karkayu (17/10/2020), Raydenito (18/10/2020), romeroca (18/10/2020), selecter25 (17/10/2020), swapd0 (18/10/2020)

Página 4 de 5 PrimerPrimer 12345 Ú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
  •