User Tag List

Página 9 de 11 PrimerPrimer ... 567891011 ÚltimoÚltimo
Resultados 121 al 135 de 155

Tema: Cuando un Atari STE se cree una NeoGeo

  1. #121

    Fecha de ingreso
    Sep 2005
    Mensajes
    12,340
    Mencionado
    197 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    331
    Agradecer Thanks Received 
    776
    Thanked in
    Agradecido 550 veces en [ARG:2 UNDEFINED] posts
    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.
    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. #122

    Fecha de ingreso
    Sep 2006
    Ubicación
    Malaga
    Mensajes
    5,675
    Mencionado
    35 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    891
    Agradecer Thanks Received 
    890
    Thanked in
    Agradecido 633 veces en [ARG:2 UNDEFINED] posts
    ¿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.
    Última edición por swapd0; 19/11/2020 a las 16:13
    No es lo mismo tener diez años de experiencia, que tener un año de experiencia diez veces.

  3. #123

    Fecha de ingreso
    Sep 2005
    Mensajes
    12,340
    Mencionado
    197 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    331
    Agradecer Thanks Received 
    776
    Thanked in
    Agradecido 550 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por swapd0 Ver mensaje
    ¿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
    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. #124

    Fecha de ingreso
    Sep 2006
    Ubicación
    Malaga
    Mensajes
    5,675
    Mencionado
    35 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    891
    Agradecer Thanks Received 
    890
    Thanked in
    Agradecido 633 veces en [ARG:2 UNDEFINED] posts
    Creo que lo has complicado demasiado, la colisión con un tile no debería depender de lo que tiene alrededor.
    No es lo mismo tener diez años de experiencia, que tener un año de experiencia diez veces.

  5. #125

    Fecha de ingreso
    Sep 2005
    Mensajes
    12,340
    Mencionado
    197 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    331
    Agradecer Thanks Received 
    776
    Thanked in
    Agradecido 550 veces en [ARG:2 UNDEFINED] posts
    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.
    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. #126

    Fecha de ingreso
    Oct 2007
    Ubicación
    Madrid
    Mensajes
    2,873
    Mencionado
    84 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    189
    Agradecer Thanks Received 
    547
    Thanked in
    Agradecido 298 veces en [ARG:2 UNDEFINED] posts
    Un post cargado de humor

    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
    La maestría interior...

    Metal Slug para Atari STE: Video-1 Video-2

    En venta memorias de 512 KB y 1 MB para Amiga 500 y Amiga 500 Plus

  7. #127

    Fecha de ingreso
    Sep 2006
    Ubicación
    Malaga
    Mensajes
    5,675
    Mencionado
    35 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    891
    Agradecer Thanks Received 
    890
    Thanked in
    Agradecido 633 veces en [ARG:2 UNDEFINED] posts
    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:
    1. Descompones el movimiento en vX y vY.
    2. 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).
    3. Si vY != 0 estamos saltando/cayendo => Guardo en una lista los tiles con los que puedo colisionar (listaY)
    4. 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)
    5. Lo mismo para listaY => vY = 0
    6. 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.
    No es lo mismo tener diez años de experiencia, que tener un año de experiencia diez veces.

  8. #128

    Fecha de ingreso
    Oct 2007
    Ubicación
    Madrid
    Mensajes
    2,873
    Mencionado
    84 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    189
    Agradecer Thanks Received 
    547
    Thanked in
    Agradecido 298 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por swapd0 Ver mensaje
    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:
    1. Descompones el movimiento en vX y vY.
    2. 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).
    3. Si vY != 0 estamos saltando/cayendo => Guardo en una lista los tiles con los que puedo colisionar (listaY)
    4. 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)
    5. Lo mismo para listaY => vY = 0
    6. 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/1D8k...ew?usp=sharing
    La maestría interior...

    Metal Slug para Atari STE: Video-1 Video-2

    En venta memorias de 512 KB y 1 MB para Amiga 500 y Amiga 500 Plus

  9. El siguiente usuario agradece a masteries este mensaje:

    swapd0 (20/11/2020)

  10. #129

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

  11. #130

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

    rungunpf.rar

    Nombre:  Captura.PNG
Visitas: 199
Tamaño: 153.1 KB
    Última edición por masteries; 20/11/2020 a las 22:12
    La maestría interior...

    Metal Slug para Atari STE: Video-1 Video-2

    En venta memorias de 512 KB y 1 MB para Amiga 500 y Amiga 500 Plus

  12. #131

    Fecha de ingreso
    Sep 2005
    Mensajes
    12,340
    Mencionado
    197 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    331
    Agradecer Thanks Received 
    776
    Thanked in
    Agradecido 550 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por swapd0 Ver mensaje
    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:
    1. Descompones el movimiento en vX y vY.
    2. 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).
    3. Si vY != 0 estamos saltando/cayendo => Guardo en una lista los tiles con los que puedo colisionar (listaY)
    4. 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)
    5. Lo mismo para listaY => vY = 0
    6. 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
    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%

  13. #132

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

    La maestría interior...

    Metal Slug para Atari STE: Video-1 Video-2

    En venta memorias de 512 KB y 1 MB para Amiga 500 y Amiga 500 Plus

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

    fbustamante (25/11/2020), selecter25 (25/11/2020)

  15. #133

    Fecha de ingreso
    Jan 2005
    Ubicación
    Madrid
    Mensajes
    4,635
    Mencionado
    18 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    75
    Agradecer Thanks Received 
    284
    Thanked in
    Agradecido 169 veces en [ARG:2 UNDEFINED] posts
    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.

  16. #134

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

  17. #135

    Fecha de ingreso
    Oct 2007
    Ubicación
    Madrid
    Mensajes
    2,873
    Mencionado
    84 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    189
    Agradecer Thanks Received 
    547
    Thanked in
    Agradecido 298 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por Iced Ver mensaje
    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.
    Última edición por masteries; 26/11/2020 a las 18:37
    La maestría interior...

    Metal Slug para Atari STE: Video-1 Video-2

    En venta memorias de 512 KB y 1 MB para Amiga 500 y Amiga 500 Plus

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

    Drumpi (26/11/2020), fbustamante (26/11/2020), Iced (27/11/2020), juanvvc (26/11/2020), selecter25 (27/11/2020)

Página 9 de 11 PrimerPrimer ... 567891011 Ú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
  •