User Tag List

Página 9 de 9 PrimerPrimer ... 56789
Resultados 121 al 131 de 131

Tema: Cuando un Atari STE se cree una NeoGeo

  1. #121

    Fecha de ingreso
    Sep 2005
    Mensajes
    12,221
    Mencionado
    192 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    320
    Agradecer Thanks Received 
    740
    Thanked in
    Agradecido 526 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,557
    Mencionado
    35 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    845
    Agradecer Thanks Received 
    841
    Thanked in
    Agradecido 607 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,221
    Mencionado
    192 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    320
    Agradecer Thanks Received 
    740
    Thanked in
    Agradecido 526 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,557
    Mencionado
    35 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    845
    Agradecer Thanks Received 
    841
    Thanked in
    Agradecido 607 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,221
    Mencionado
    192 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    320
    Agradecer Thanks Received 
    740
    Thanked in
    Agradecido 526 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,815
    Mencionado
    82 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    174
    Agradecer Thanks Received 
    490
    Thanked in
    Agradecido 273 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

  7. #127

    Fecha de ingreso
    Sep 2006
    Ubicación
    Malaga
    Mensajes
    5,557
    Mencionado
    35 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    845
    Agradecer Thanks Received 
    841
    Thanked in
    Agradecido 607 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,815
    Mencionado
    82 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    174
    Agradecer Thanks Received 
    490
    Thanked in
    Agradecido 273 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

  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,557
    Mencionado
    35 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    845
    Agradecer Thanks Received 
    841
    Thanked in
    Agradecido 607 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,815
    Mencionado
    82 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    174
    Agradecer Thanks Received 
    490
    Thanked in
    Agradecido 273 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: 135
Tamaño: 153.1 KB
    Última edición por masteries; 20/11/2020 a las 22:12

  12. #131

    Fecha de ingreso
    Sep 2005
    Mensajes
    12,221
    Mencionado
    192 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    320
    Agradecer Thanks Received 
    740
    Thanked in
    Agradecido 526 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%

Página 9 de 9 PrimerPrimer ... 56789

Permisos de publicación

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