User Tag List

Página 2 de 3 PrimerPrimer 123 ÚltimoÚltimo
Resultados 16 al 30 de 43

Tema: Metal Slug (Mission 1) completa para Atari STE - Ata Geo

  1. #16

    Fecha de ingreso
    Oct 2007
    Ubicación
    Madrid
    Mensajes
    3,439
    Mencionado
    111 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    327
    Agradecer Thanks Received 
    1,180
    Thanked in
    Agradecido 584 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por swapd0 Ver mensaje
    Creo que lo de las explosiones es parte de las optimizaciones para que corra mas, parece que al convertir los graficos puedes decir que si hay muy pocos pixels transparentes se los salte (no he mirado las AGT).
    Efectivamente, como son gráficos muy recurrentes; se han modificado los originales para que muchas de las líneas que componen cada frame, tengan la misma longitud; intentando mantener un compromiso entre aspecto y rendimiento, pero hay que favorecer más el rendimiento en esta máquina. Al compartir longitud de muchas líneas, pueden compartir la misma configuración del blitter, y te ahorras muchas reconfiguraciones del mismo.

    Estos gráficos se pintan línea a línea, pero el orden de dibujado de las líneas está salteado... incluso se agrupan las líneas que comparten misma máscara de comienzo, misma máscara de final...


    También ambas explosiones son sprites con un predesplazamiento de 4 píxeles, para ahorrar memoria; y algo muy importante, y de ahí también la naturaleza algo cuadrada de las explosiones.
    Las explosiones sirven para limpiar los sprites que has destruido, el helicóptero, el avión, el tanque... y se limpian a sí mismas.

    Una explosión no tiene activada la limpieza del fondo, hasta que alcanza su fotograma número 5, entonces empieza a limpiar porque la explosión decrece de tamaño.
    Esto permite limpiar el helicóptero, el avión, el tanque e incluso los sprites más grandes.

    ¿De dónde sale el rendimiento? De mil trucos como este.... xD


    Hay más trucos, como un mecanismo de limpiado, que sólo limpia en la dirección en la que el sprite ha ido dejando el rastro: el tanque, el avión, el slug tocho (lo que swapd0 llama el cangrejo), el barco.


    Y un mecanismo de dibujado que permite dibujar hasta 16 segmentos "middle" (256 píxels) del blitter sin que intervenga la CPU para nada, éste es un mecanismo ilegal, pues la primera vez que lo usas salta una trap del sistema; pero esta trap tiene un código que la atiende y deja configurado el blitter de manera que la próxima vez que salte, en lugar de tener que atender la trap; uno de los registros del blitter queda configurado como contador decreciente, lo que te permite dibujar hasta 256 pixels sin que el blitter realice operación de máscara, es el dibujado más rápido que hay. Cuando el blitter ha leído y enviado una palabra de 16 bits, envía la siguiente de forma automática... y el contador decrece sólo... cuando llega a 0, el blitter devuelve el control a la CPU

    Si la línea es mayor de 256 píxeles, terminas con un "end" mask, y concatenas los siguientes 16 y más píxeles con un "start" mask y a seguir pintando sin middle mask.
    Y si hay un hueco por en medio, pues un "end" y un "start" mask, no queda otra.



    Y luego existe también, la operación de rellenado de superficies rectangulares con el blitter; esto ya se había usado anteriormente (en Metal Slug no lo estoy usando, pero lo he probado a modo de debug para ver los cuadros de colisión, y me he quedado sorprendido de que pintar un cuadrado enorme 50 veces por segundo, come muy poquito tiempo), estoy seguro de que el juego Robocop 3 para STE se ejecuta tan bien; porque usa el blitter de esta manera. Puedes elegir un color de relleno de la paleta, o un patrón alternante de dos colores de la paleta, para rellenar el área de la pantalla que especifiques; y todo sin necesidad de acceder a la RAM para recuperar datos gráficos, con lo que el blitter rellena áreas muy deprisa... como si fuera el primer rasterizador 3D acelerado de la historia. No realiza operaciones de geometría, pero las tarjetas Voodoo / TNT 2 tampoco lo hacían, necesitaban conocer de antemano la infomación de las superficies a pintar... aquí las superficies son rectangulares, en lugar de triangulares, pero salvando la distancia de capacidades, puedes rellenar caras de polígonos muy rápido... como hace Robocop 3


    Me gustraría grabar un vídeo contando el cómo se ha hecho el port,
    Última edición por masteries; 14/07/2021 a las 12:16

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

    fbustamante (14/07/2021), JoJo_ReloadeD (14/07/2021)

  3. #17

    Fecha de ingreso
    Sep 2005
    Mensajes
    15,180
    Mencionado
    247 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    670
    Agradecer Thanks Received 
    1,845
    Thanked in
    Agradecido 1,263 veces en [ARG:2 UNDEFINED] posts
    Juer, pues para ser un port de una recreativa que ni la propia placa podía mover, es todo un logro.
    Si bien es cierto que no hay tantos enemigos como en el original, y faltan algunos efectos sutiles que le darían más empaque al asunto (como hacer que los helicópteros no se muevan de forma tan robótica, aplicarle un ligero movimiento sinusoidal vertical), tener ese juego en el STE es increíble. En los 90, las distribuidoras hubieran matado por conseguirlo... seguirían pagando una m***** pero habrían hecho locuras
    Ya sé que los "fallos" son cosa de las limitaciones de la máquina, no estoy criticando eso, pero es más que sorprendente los pocos defectos que se le puede sacar a una demo.

    Mi enhorabuena por el grandísimo trabajo que hay detrás.
    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%

  4. #18

    Fecha de ingreso
    Oct 2007
    Ubicación
    Madrid
    Mensajes
    3,439
    Mencionado
    111 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    327
    Agradecer Thanks Received 
    1,180
    Thanked in
    Agradecido 584 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por Drumpi Ver mensaje
    Juer, pues para ser un port de una recreativa que ni la propia placa podía mover, es todo un logro.
    Si bien es cierto que no hay tantos enemigos como en el original, y faltan algunos efectos sutiles que le darían más empaque al asunto (como hacer que los helicópteros no se muevan de forma tan robótica, aplicarle un ligero movimiento sinusoidal vertical), tener ese juego en el STE es increíble. En los 90, las distribuidoras hubieran matado por conseguirlo... seguirían pagando una m***** pero habrían hecho locuras
    Ya sé que los "fallos" son cosa de las limitaciones de la máquina, no estoy criticando eso, pero es más que sorprendente los pocos defectos que se le puede sacar a una demo.

    Mi enhorabuena por el grandísimo trabajo que hay detrás.

    Muchas gracias,

    Pues mira, justo eso es lo que falta, pulir algún detalle y pulir la dificultad.
    Pero vamos que comparado con el inmenso trabajo de preparar las funciones que gestionan el dibujado, las colisiones y la lógica del juego;
    pulir eso es mucho menos trabajo. Porque lo que hay ahora es como un engine de Metal Slugs...

    Lo del helicóptero es fácil, creo con Matlab una look up table de un seno y que se su coordenada Y se vea alterada según va avanzando la look up table.
    Donde hay que tener más cuidado, es en que no baje más de altura, porque entonces se empiezan a limpiar los 4 tiles de 16x16 del escenario que tiene justo debajo, y eso no mola.
    Tal vez habría que quitarle 8 píxels de altura al helicóptero, para que con esos 8 píxels disponer de margen suficiente para moverlo arriba y abajo sin que limpie más tiles.

    Todas las trayectorias, excepto las rectas, que veis en el juego, son look up tables, incluso el salto del protagonista.
    Ahorrándole trabajo matemático al 68000.

  5. #19

    Fecha de ingreso
    Jun 2003
    Ubicación
    Madrid
    Mensajes
    570
    Mencionado
    9 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    26
    Agradecer Thanks Received 
    128
    Thanked in
    Agradecido 61 veces en [ARG:2 UNDEFINED] posts
    Sí, la chip está limitada a un mega... supongo que no se podría suplir con FastRam
    El pasado ha pasado y por él nada hay que hacer... el presente es un fracaso y el futuro no se ve... (Cerebros destruidos/Eskorbuto)

  6. #20

    Fecha de ingreso
    Sep 2006
    Ubicación
    Malaga
    Mensajes
    7,551
    Mencionado
    47 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    1,660
    Agradecer Thanks Received 
    1,915
    Thanked in
    Agradecido 1,285 veces en [ARG:2 UNDEFINED] posts
    Ya que te pones, creo que el helicóptero debería de tener un poco de inercia en horizontal para que no te siga tan linealmente, y cuando coges el robot también, para que se note pesado.
    No es lo mismo tener diez años de experiencia, que tener un año de experiencia diez veces.


    It is an undisputed truth that the Atari ST gets the best out of coders. No dedicated hardware, just the CPU and a frame buffer! Some call it Spartan, others name it Power Without The Price, and a select few say `challenge accepted'! --- by spkr from smfx

  7. #21

    Fecha de ingreso
    Jul 2009
    Mensajes
    8,737
    Mencionado
    64 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    937
    Agradecer Thanks Received 
    571
    Thanked in
    Agradecido 345 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por masteries Ver mensaje
    Efectivamente, como son gráficos muy recurrentes; se han modificado los originales para que muchas de las líneas que componen cada frame, tengan la misma longitud; intentando mantener un compromiso entre aspecto y rendimiento, pero hay que favorecer más el rendimiento en esta máquina. Al compartir longitud de muchas líneas, pueden compartir la misma configuración del blitter, y te ahorras muchas reconfiguraciones del mismo.

    Estos gráficos se pintan línea a línea, pero el orden de dibujado de las líneas está salteado... incluso se agrupan las líneas que comparten misma máscara de comienzo, misma máscara de final...


    También ambas explosiones son sprites con un predesplazamiento de 4 píxeles, para ahorrar memoria; y algo muy importante, y de ahí también la naturaleza algo cuadrada de las explosiones.
    Las explosiones sirven para limpiar los sprites que has destruido, el helicóptero, el avión, el tanque... y se limpian a sí mismas.

    Una explosión no tiene activada la limpieza del fondo, hasta que alcanza su fotograma número 5, entonces empieza a limpiar porque la explosión decrece de tamaño.
    Esto permite limpiar el helicóptero, el avión, el tanque e incluso los sprites más grandes.

    ¿De dónde sale el rendimiento? De mil trucos como este.... xD


    Hay más trucos, como un mecanismo de limpiado, que sólo limpia en la dirección en la que el sprite ha ido dejando el rastro: el tanque, el avión, el slug tocho (lo que swapd0 llama el cangrejo), el barco.


    Y un mecanismo de dibujado que permite dibujar hasta 16 segmentos "middle" (256 píxels) del blitter sin que intervenga la CPU para nada, éste es un mecanismo ilegal, pues la primera vez que lo usas salta una trap del sistema; pero esta trap tiene un código que la atiende y deja configurado el blitter de manera que la próxima vez que salte, en lugar de tener que atender la trap; uno de los registros del blitter queda configurado como contador decreciente, lo que te permite dibujar hasta 256 pixels sin que el blitter realice operación de máscara, es el dibujado más rápido que hay. Cuando el blitter ha leído y enviado una palabra de 16 bits, envía la siguiente de forma automática... y el contador decrece sólo... cuando llega a 0, el blitter devuelve el control a la CPU

    Si la línea es mayor de 256 píxeles, terminas con un "end" mask, y concatenas los siguientes 16 y más píxeles con un "start" mask y a seguir pintando sin middle mask.
    Y si hay un hueco por en medio, pues un "end" y un "start" mask, no queda otra.



    Y luego existe también, la operación de rellenado de superficies rectangulares con el blitter; esto ya se había usado anteriormente (en Metal Slug no lo estoy usando, pero lo he probado a modo de debug para ver los cuadros de colisión, y me he quedado sorprendido de que pintar un cuadrado enorme 50 veces por segundo, come muy poquito tiempo), estoy seguro de que el juego Robocop 3 para STE se ejecuta tan bien; porque usa el blitter de esta manera. Puedes elegir un color de relleno de la paleta, o un patrón alternante de dos colores de la paleta, para rellenar el área de la pantalla que especifiques; y todo sin necesidad de acceder a la RAM para recuperar datos gráficos, con lo que el blitter rellena áreas muy deprisa... como si fuera el primer rasterizador 3D acelerado de la historia. No realiza operaciones de geometría, pero las tarjetas Voodoo / TNT 2 tampoco lo hacían, necesitaban conocer de antemano la infomación de las superficies a pintar... aquí las superficies son rectangulares, en lugar de triangulares, pero salvando la distancia de capacidades, puedes rellenar caras de polígonos muy rápido... como hace Robocop 3


    Me gustraría grabar un vídeo contando el cómo se ha hecho el port,
    y por que no reducir el tamaño de esas explosiones para que no queden feas con esos bordes rectos?
    ...

  8. #22

    Fecha de ingreso
    Oct 2007
    Ubicación
    Madrid
    Mensajes
    3,439
    Mencionado
    111 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    327
    Agradecer Thanks Received 
    1,180
    Thanked in
    Agradecido 584 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por SplinterGU Ver mensaje
    y por que no reducir el tamaño de esas explosiones para que no queden feas con esos bordes rectos?

    Considero que debéis coger los spritesheets de las originales y éstas, y entonces empezar a buscar las diferencias, porque son bien pocas.

    -----Actualizado-----

    Cita Iniciado por OscarBraindeaD Ver mensaje
    Sí, la chip está limitada a un mega... supongo que no se podría suplir con FastRam
    Un sólo megabyte de chip limita demasiado, y si no utilizas sprites compilados; pues entonces el rendimiento cae en picado en ambas máquinas (STE y Amiga 500/500+/600) y ya no podrías mostrar todo lo necesario en pantalla.

    Con 2 MB, en los 500+ y los 600, se podría si dejas de usar el dithering complementario, pero recordando quedarte en 16 colores o 4 bit planes; como quieras usar los 5 bit planes del Amiga puedes pasarlo mal igualmente. Y luego hay técnicas del blitter, que según DML, no están disponibles en el Amiga. Pero tienes los sprites hardware y por ahí podrías suplir.
    Y ya si quieres bajarlo a 25 fps, pues tienes que reprogramar muchísimas cosas de la lógica del juego.

    Recordad que a 5 bitplanes en el Amiga trabaja muy poquita gente, porque el rendimiento de verdad está en el color de 4 bits, incluso el buen juego en desarrollo "Metro Siege", utiliza 16 colores y corre a 25 / 30 fps. Lo que hacen es resevar 8 colores para los sprites y cambiar alguno colores del escenario de forma dinámica con el copper.

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

    fbustamante (17/07/2021), swapd0 (16/07/2021)

  10. #23

    Fecha de ingreso
    Jul 2009
    Mensajes
    8,737
    Mencionado
    64 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    937
    Agradecer Thanks Received 
    571
    Thanked in
    Agradecido 345 veces en [ARG:2 UNDEFINED] posts
    si los originales tienen bordes asi cuadrados rectos, entonces no dije nada... pero igual quedarian mejor no sean cuadrados, como en una caja...

    si no dices eso, pues no te entendi...
    ...

  11. #24

    Fecha de ingreso
    Sep 2006
    Ubicación
    Malaga
    Mensajes
    7,551
    Mencionado
    47 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    1,660
    Agradecer Thanks Received 
    1,915
    Thanked in
    Agradecido 1,285 veces en [ARG:2 UNDEFINED] posts
    He estado mirando los graficos del metal slug y que pasada, las explosiones tienen un montón de frames y el detalle es brutal, lastima que tengas que recortar porque un juego en el STE usando los mismos graficos aunque mostrando menos en pantalla seria brutal... yo que tu empezaba de nuevo e iría cargando los datos a medida que los necesites como el Ninja Warriors o el SWIV para no quitar nada XDXDXD
    No es lo mismo tener diez años de experiencia, que tener un año de experiencia diez veces.


    It is an undisputed truth that the Atari ST gets the best out of coders. No dedicated hardware, just the CPU and a frame buffer! Some call it Spartan, others name it Power Without The Price, and a select few say `challenge accepted'! --- by spkr from smfx

  12. #25

    Fecha de ingreso
    Jan 2005
    Mensajes
    1,012
    Mencionado
    18 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    25
    Agradecer Thanks Received 
    29
    Thanked in
    Agradecido 23 veces en [ARG:2 UNDEFINED] posts
    Es una pasada!

  13. #26

    Fecha de ingreso
    Jul 2009
    Mensajes
    8,737
    Mencionado
    64 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    937
    Agradecer Thanks Received 
    571
    Thanked in
    Agradecido 345 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por swapd0 Ver mensaje
    He estado mirando los graficos del metal slug y que pasada, las explosiones tienen un montón de frames y el detalle es brutal, lastima que tengas que recortar porque un juego en el STE usando los mismos graficos aunque mostrando menos en pantalla seria brutal... yo que tu empezaba de nuevo e iría cargando los datos a medida que los necesites como el Ninja Warriors o el SWIV para no quitar nada XDXDXD
    empezar de nuevo no sera mucho?

    el trabajo esta magnifico, solo que no entendi bien que quiso decir con lo de las explosiones... pero el trabajo salvo ese detalle esta impecable... realmente es maravilloso...
    ...

  14. #27

    Fecha de ingreso
    Sep 2006
    Ubicación
    Malaga
    Mensajes
    7,551
    Mencionado
    47 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    1,660
    Agradecer Thanks Received 
    1,915
    Thanked in
    Agradecido 1,285 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por SplinterGU Ver mensaje
    empezar de nuevo no sera mucho?

    el trabajo esta magnifico, solo que no entendi bien que quiso decir con lo de las explosiones... pero el trabajo salvo ese detalle esta impecable... realmente es maravilloso...
    Si, lo decía de broma por eso el XD del final.

    -----Actualizado-----

    Cuando dibujas un Sprite tienes que tener una mascara para borrar los Pixels que ocupan el sprite, y dibujas el sprite haciendo un OR. Las librerías estas están optimizadas para que en caso de dibujar un sprite grande (en el Atari ST los pixels se dibujan de 16 en 16) no hagas mascara en la zona central, solo en los extremos, en la zona central solo copias los datos, de esta forma se dibuja mas rápido que realizando una mascara completa del sprite.
    No es lo mismo tener diez años de experiencia, que tener un año de experiencia diez veces.


    It is an undisputed truth that the Atari ST gets the best out of coders. No dedicated hardware, just the CPU and a frame buffer! Some call it Spartan, others name it Power Without The Price, and a select few say `challenge accepted'! --- by spkr from smfx

  15. #28

    Fecha de ingreso
    Jul 2009
    Mensajes
    8,737
    Mencionado
    64 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    937
    Agradecer Thanks Received 
    571
    Thanked in
    Agradecido 345 veces en [ARG:2 UNDEFINED] posts
    claro, pero eso aplica solo si la parte central es solida... si tiene agujeros o zonas transparentes, debe ir con mascara...
    ...

  16. #29

    Fecha de ingreso
    Oct 2007
    Ubicación
    Madrid
    Mensajes
    3,439
    Mencionado
    111 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    327
    Agradecer Thanks Received 
    1,180
    Thanked in
    Agradecido 584 veces en [ARG:2 UNDEFINED] posts
    Publicado, en primerísima plana, en el foro de los Amigueros

    Eab abime. Para el que no lo sepa,

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

    Drumpi (19/07/2021), fbustamante (18/07/2021), selecter25 (22/07/2021), SplinterGU (19/07/2021)

  18. #30

    Fecha de ingreso
    Oct 2007
    Ubicación
    Madrid
    Mensajes
    3,439
    Mencionado
    111 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    327
    Agradecer Thanks Received 
    1,180
    Thanked in
    Agradecido 584 veces en [ARG:2 UNDEFINED] posts
    Una respuesta a una cuestión técnica interesante, que han planteado en Va de Retro:


    Desconozco la plataforma en detalle, no conocía el videojuego pero noto que en algunos momentos cuando el sprite del protagonista supera cierta altura, desaparece parcial o totalmente. Por curiosidad, ¿es normal?



    Si, es normal para los sprites que emplean el formato EMX2

    El protagonista, los soldados enemigos y el mecha; están compuestos de 2 sprites EMX2. El torso y las piernas... obviamente con la intención de ahorrar memoria.
    Habéis visto que desaparece el torso (se deja de dibujar cuando atraviesa el borde superior (con el inferior también pasaría).

    Este formato de sprites es el más rápido de dibujar, pero no admite clipping vertical.


    En cambio, si habéis visto el gran primer enemigo al que te enfrentas con el mecha, que se descuelga desde lo más alto, desde fuera de la pantalla... y en este sprite si está funcionando el clipping vertical; pese a que también está en formato EMX2, incluye a su vez, la misma versión del sprite en formato EMS, que si admite clipping vertical.

    Pero el formato EMS es entre un 10% y un 15% más lento de dibujar que el EMX2. En contra, el formato EMX2 requiere más memoria que el EMS para guardar el mismo sprite.
    Y ya si en un sprite EMX2, incluyes también la versión EMS (El gran Slug incluye las dos versiones a la vez), el consumo de memoria es aún mas elevado.


    De todas formas, si este mapa de la primera misión de Metal Slug, tuviera sus tiles correctamente alineados, en lugar de 5556 tiles de 16x16 pixels, habría 4000 tiles o cosa así.
    En NeoGeo les importaba bien poco colocar bien los tiles, para poder reutilizarlos.
    Lo que te daría memoria libre suficiente, para incrustar versión EMS al sprite del torso del protagonista y al torso del mecha, y evitar el efecto de desaparición por la falta de clipping vertical.


    En los nuevos juegos comerciales que estamos desarrollando, ya estamos teniendo esa precaución. Al menos colocar bien los tiles, para que la máquina los reutilice y nos deje más memoria xD

Página 2 de 3 PrimerPrimer 123 Ú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
  •