Sobre la capacidad de multiplicación de snes, y sus posibles usos

Eteream escribió:

magno escribió:Aunque se pudiera, eso no se haría nunca porque te da poca capacidad de reutilizar sprites, además de por la detección de colisiónes, sobra mucho espacio "vacío" entre el perfil del personaje y el "bounding-box" que forma la rejilla 64x64.

¿Que tendrá que ver el sistema gráfico con la detección de colisiones?

Se refiere a que incide en la detección de colisiones, no que de eso se encargue el sistema gráfico.

Es que no incide en nada, @Señor Ventura, la detección de colisiones se hace por software y no interviene para nada el sistema gráfico por hardware de ninguna manera.

Usualmente tienes un rectángulo (o más) que es el área de colisión, el cual es completamente independiente de cuantos sprites tengas o de que tamaño sean.

...

¿ @Señor Ventura estas diciendo que las colisiones en SNES, o en general en las consolas 2D, se hacen por hardware cuando dos sprites colisionan gráficamente ?

Eso seria absurdo, por ejemplo:
- No podrías ajustar la jugabilidad
- Un mismo personaje, con cierta complejidad de sprites, colisionaría con sigo mismo

@magno

Sigo sin poder disponer de un buen rato de mi tiempo para dedicarme a una respuesta merecedora de tu empeño, pero intentaré acercarme lo mas que pueda.

En primer lugar agradecerte tanta info, siempre es un placer contar con tus conocimientos por aquí


Está claro que a base de animación pura siempre se puede simular la rotación de un objeto, y que si te buscas las maneras, siempre acabas encontrando la forma de realizar la tarea, pero lo que me choca es que cuando se ha hecho algo así a base de animación, nunca se ha hecho de una forma tan fina. Habitualmente no se quiere gastar memoria en algo así, y mas aún, en el propio super aleste sería el único elemento en recibir una animación que desde luego es mas fina que a base de 15º en 15º.

He grabado la animación a cámara lenta, y efectivamente la rotación se sucede desplazando unos 3 pixels por frame. Además sucede algo curioso, cada tres frames de animación, hay un parón que dura un frame.

La forma en que suede, y lo fino de la animacion, me lleva a pensar que es una rotación... pero es que además está el detalle de que nunca en un juego se ha simulado un efecto de scaling o rotación de una manera tan detallista, y esto mismo choca aún mas cuando incluso dentro del propio juego ninguna clase de animación goza de tanto cuidado como esa bola.

Si fuese una animación desde la ROM, sin duda sería toda una excepción.

magno escribió:Es justo lo contrario... Las limitaciones vienen por la resolución vertical, no la horizontal. La explicación es porque todos los cálculos para la pantalla los tienes que hacer antes de que llegue la siguiente interrupción NMI (eso quiere decir, antes de que llegue el siguiente VBlank), por tanto, cuando menos líneas tengas que "calcular" mejor. Por eso la SNES tiene el modo "overscan", en el NMI salta en la línea 226 de pantalla o en la 240: si salta en la 240, tienes más tiempo en el frame para calcular las cosas, pero menos tiempo en el NMI para enviarlas a VRAM, por lo que igual no te sirve de nada calcular tanto para luego no poder enviarlo a pantalla. Lo normal en el 90% de juegos es dejar configurado el modo sin overscan, saltando el NMI en la lñinea 226.

Si, tal vez se me haya entendido mal. Lo que decía es que la resolución vertical es la que mas fuerza a la cpu, mientras que la resolución horizontal influye al sistema de vídeo (gracias por las info ).

Sobre el debate de forzar las resoluciones in game a 320x240, ¿que consecuencias habrían para el sistema de vídeo implementar algo así? (en cuánto a fill rate, manejo de sprites total y por scanline, retrasos en el dibujado de cada scanline, etc).

magno escribió:Es lo que se suele hacer normalmente en los juegos si no hay muchas cosas que giren; programar una rutina de rotación de sprites solo para 1 sprite en todo el juego es algo tedioso, aunque estaría bien comprobarlo porque nunca me he topado con ninguna rutina así en la SNES y querría analizarla en profundidad.

Realmente me gustaría saber cual sería el coste en ciclos de reloj implementar algo así por software (y mas aún si se hace con varios simultáneamente).

Me recuerda a al pseudo efecto de escalado de los sprites del art of fighting 1 y 2 de snes. Básicamente no es un escalado, sino que esconde parte de la información de cada sprite (desaparecen pixels). En cuestión de alteración de un sprite, no sería muy diferente de una rotación, ¿no?.

Eteream escribió:¿ @Señor Ventura estas diciendo que las colisiones en SNES, o en general en las consolas 2D, se hacen por hardware cuando dos sprites colisionan gráficamente ?

Eso seria absurdo, por ejemplo:
- No podrías ajustar la jugabilidad
- Un mismo personaje, con cierta complejidad de sprites, colisionaría con sigo mismo

No, no, lo que ocurre con esto es que en el propio sprite habrían muchos pixels "invisibles", pero que se interponen entre el dibujo, y el objeto contra el que colisionarían.

La cpu establece conforme a una rutina de colisiones, un resultado específico, pero si dos sprites de 64x64 pixels tienen el dibujio en el centro, y en el exterior un montón de pixels "sin usar", lo que colisiona es un vacío, y ambos objetos reaccionarían entre si sin que realmente los dibujos se estén tocando (pero los sprites si).

Señor Ventura escribió:

Eteream escribió:¿ @Señor Ventura estas diciendo que las colisiones en SNES, o en general en las consolas 2D, se hacen por hardware cuando dos sprites colisionan gráficamente ?

Eso seria absurdo, por ejemplo:
- No podrías ajustar la jugabilidad
- Un mismo personaje, con cierta complejidad de sprites, colisionaría con sigo mismo

No, no, lo que ocurre con esto es que en el propio sprite habrían muchos pixels "invisibles", pero que se interponen entre el dibujo, y el objeto contra el que colisionarían.

La cpu establece conforme a una rutina de colisiones, un resultado específico, pero si dos sprites de 64x64 pixels tienen el dibujio en el centro, y en el exterior un montón de pixels "sin usar", lo que colisiona es un vacío, y ambos objetos reaccionarían entre si sin que realmente los dibujos se estén tocando (pero los sprites si).

¿ Y que más da que hayan pixels transparentes ? Como programador seleccionas el área que te interesa para detectar las colisiones y esa área no tiene ninguna relación con los sprites, obviamente buscarás que coincida con la parte interior del "dibujo" pero es totalmente arbitrario. Aunque crees un máscara de colisión para hacer colisión a pixeles, eliges que pixeles cuales pixeles entran y cuales no, sin embargo no tengo noticia que eso se use en 16bits.

Eteream escribió:¿ Y que más da que hayan pixels transparentes ? Como programador seleccionas el área que te interesa para detectar las colisiones y esa área no tiene ninguna relación con los sprites, obviamente buscarás que coincida con la parte interior del "dibujo" pero es totalmente arbitrario. Aunque crees un máscara de colisión para hacer colisión a pixeles, eliges que pixeles cuales pixeles entran y cuales no, sin embargo no tengo noticia que eso se use en 16bits.

Me temo que la snes no funciona así, de ahí su importancia.

@Señor Ventura soy todo orejas, pues.

Y no olvides también documentar las colisiones con elementos que no son sprites, p. ej. los fondos (o backgrounds), a ver como se hacen en SNES. Ejemplo de juego: zelda o cualquier plataformas.

Eteream escribió:¿Que tendrá que ver el sistema gráfico con la detección de colisiones?

¿Y quién ha dicho que tenga que ver? No inventes cosas que no he dicho, anda...
Simplemente he dicho que ningún programador usa sprites 64x64 para personajes jugables por el bounding-box de la detección de colisiones, nada que ver con que la detección de colisiones se haga por hardware ni nada por el estilo.
Por si necesitas información, así se suele hacer la detección:
http://games.greggman.com/game/programming_m_c__kids/

Hay un ejemplo sobre cómo mover al personaje por un terreno inclinado: si el bounding-box es de 64x64, un pedazo de él ya se habrá metido por detrás del escenario cuando el personaje suba o baje una cuesta. Esto implica tener calculado el orden de las capas en todo momento para que no quede oculto parte del personaje.
Pero esto, que puede ser sencillo de controlar en un sistema como la SNES que permite por hardware cambiar la prioridad de cada sprite individual para que aparezca en el stack de capas visibles en una o en otra.

Pero es que ni tan siquiera me refería a esto: la verdadera dificulltad de calcular las colisiones de sprites 64x64 es que tienes que saber para cada línea de píxeles en qué punto colisiona el personaje, es decir, que tendrías que saber cuánto ocupa de ancho en píxeles el personaje a la altura de la cabeza, a la altura de las piernas o a la altura del tronco, valores todos ellos diferentes por el perfil curvado de los personajes.
Por ejemplo, un personaje como Mario tendría 1 píxel hasta el bounding-box de 64x64 por delante, y 3 por detrás a la altura de la cabeza por donde sobresale la gorra, pero esa distancia desde el perfil del personaje hasta el borde del bounding-box no se mantiene constante, así que para cada línea de píxeles necesitas almacenar por delante y por detrás cuántos píxeles quedan "vacíos".

Un ejemplo claro está en Treasure Hunter G: los personajes son bastante más grandes de lo normal para un juego de RPG, de ahí que en vez de usar la típica configuración de 32x16 o 24x16 como en otros juegos, los sprites son una configuración irregular de sub-sprites de tamaño 16x16 y 8x8; el fondo de pantalla (los BG) son 16x16 por lo que la detección de colisiones sería "poco fina", sin embargo, ésta se hace en base a una rejilla de 8x8: cada tile 16x16 del escenario se asocia en una tabla con 4 bytes, uno por tile 8x8, que dice qué acción se realiza cuando el personaje está cerca, pisa la tile o pulsa el botón de acción sobre ella. Esto implica varias detecciones de colisiones
* Se comprueba en qué tile está el centro de gravedad del personaje (hot-spot le llaman en el artículo que te he pasado) para:
- comprobar si en alguna de las 8 tiles circundantes (una por dirección del espacio) hay alguna acción a ejecutar
- comprobar si en vertical se está tocando alguna parte sólida
- comprobar si salta alguna acción automática o desencadenada por pulsar un botón
* Se comprueba si las tiles más a la derecha (o a la izquierda, dependiendo de hacia dónde ande el personaje) toca con alguna tile sólida (del fondo o de otro personaje que se mueve por pantalla)

Así que imagínate si estas comprobaciones tuviera que hacerse con una máscara binaria como decías para cada una de las posiciones de animación de cada personaje (4 a la vez manejables en pantalla).


Por favor, infórmate antes de soltar "acusaciones"

Señor Ventura escribió:Me recuerda a al pseudo efecto de escalado de los sprites del art of fighting 1 y 2 de snes. Básicamente no es un escalado, sino que esconde parte de la información de cada sprite (desaparecen pixels). En cuestión de alteración de un sprite, no sería muy diferente de una rotación, ¿no?.

Realmente ese efecto de escalado se hace en muchos sitios; por ejemplo, la fuente de los menús del Seiken Densetsu 3 es la misma que la fuente de los diálogos a la que se le quitan algunos píxeles horizontalmente. La primera vez que vi esto flipé bastante y pensé que algo se me escapaba, que no podría ser que ese "escalado" de la fuente se viera bien por pantalla, pero se veía.
Y ahora con el Star Ocean, el escalado de los items que encuentras en los cofres se hace de esa misma manera, quitando píxeles en vez de hacer algún tipo de interpolación lineal simplona.

magno escribió:

Eteream escribió:¿Que tendrá que ver el sistema gráfico con la detección de colisiones?

¿Y quién ha dicho que tenga que ver? No inventes cosas que no he dicho, anda...
Simplemente he dicho que ningún programador usa sprites 64x64 para personajes jugables por el bounding-box de la detección de colisiones, nada que ver con que la detección de colisiones se haga por hardware ni nada por el estilo.
Por si necesitas información, así se suele hacer la detección:
http://games.greggman.com/game/programming_m_c__kids/

Hay un ejemplo sobre cómo mover al personaje por un terreno inclinado: si el bounding-box es de 64x64, un pedazo de él ya se habrá metido por detrás del escenario cuando el personaje suba o baje una cuesta. Esto implica tener calculado el orden de las capas en todo momento para que no quede oculto parte del personaje.
Pero esto, que puede ser sencillo de controlar en un sistema como la SNES que permite por hardware cambiar la prioridad de cada sprite individual para que aparezca en el stack de capas visibles en una o en otra.

Pero es que ni tan siquiera me refería a esto: la verdadera dificulltad de calcular las colisiones de sprites 64x64 es que tienes que saber para cada línea de píxeles en qué punto colisiona el personaje, es decir, que tendrías que saber cuánto ocupa de ancho en píxeles el personaje a la altura de la cabeza, a la altura de las piernas o a la altura del tronco, valores todos ellos diferentes por el perfil curvado de los personajes.
Por ejemplo, un personaje como Mario tendría 1 píxel hasta el bounding-box de 64x64 por delante, y 3 por detrás a la altura de la cabeza por donde sobresale la gorra, pero esa distancia desde el perfil del personaje hasta el borde del bounding-box no se mantiene constante, así que para cada línea de píxeles necesitas almacenar por delante y por detrás cuántos píxeles quedan "vacíos".

Un ejemplo claro está en Treasure Hunter G: los personajes son bastante más grandes de lo normal para un juego de RPG, de ahí que en vez de usar la típica configuración de 32x16 o 24x16 como en otros juegos, los sprites son una configuración irregular de sub-sprites de tamaño 16x16 y 8x8; el fondo de pantalla (los BG) son 16x16 por lo que la detección de colisiones sería "poco fina", sin embargo, ésta se hace en base a una rejilla de 8x8: cada tile 16x16 del escenario se asocia en una tabla con 4 bytes, uno por tile 8x8, que dice qué acción se realiza cuando el personaje está cerca, pisa la tile o pulsa el botón de acción sobre ella. Esto implica varias detecciones de colisiones
* Se comprueba en qué tile está el centro de gravedad del personaje (hot-spot le llaman en el artículo que te he pasado) para:
- comprobar si en alguna de las 8 tiles circundantes (una por dirección del espacio) hay alguna acción a ejecutar
- comprobar si en vertical se está tocando alguna parte sólida
- comprobar si salta alguna acción automática o desencadenada por pulsar un botón
* Se comprueba si las tiles más a la derecha (o a la izquierda, dependiendo de hacia dónde ande el personaje) toca con alguna tile sólida (del fondo o de otro personaje que se mueve por pantalla)

Así que imagínate si estas comprobaciones tuviera que hacerse con una máscara binaria como decías para cada una de las posiciones de animación de cada personaje (4 a la vez manejables en pantalla).


Por favor, infórmate antes de soltar "acusaciones"

Cuando llegamos al punto de inventarnos cosas para "ganar" una discusión mal vamos. En 16bits y juegos 2D similares NO SE USA NINGUNA BOUNDING BOX PARA MOVERSE POR EL TERRENO!!!. Léete mejor la documentos que tu mismo posteas.

Eeeh... @magno , me encantan todos tus brillantes aportes al mundillo del hackeo de juegos y la programación; tus traducciones, ayudas a otros traductores/hackers, tus respuestas, etc.. e igualmente me gusta el buen talante y estos hilos con cuestiones e inquietudes técnicas del @Señor Ventura . Todo esto es aporte.

@Eteream

Al menos en megadrive encuentro muy util el uso de bounding box para deteccion de coliciones en mapas

Puede transformar al inutil registro de coliciones en algo potable, y tirar de vdp para una parte al menos

Ahora q algun juego lo use, ni idea

theelf escribió:Al menos en megadrive encuentro muy util el uso de bounding box para deteccion de coliciones en mapas

Por supuesto, es un cálculo muy rápido y se usa en todos los juegos, no sólo los de MD. Pero para deslizarse por terrenos ya sean 2D o 3D, tiene problemas y suele usarse otros métodos.

theelf escribió:Puede transformar al inutil registro de coliciones en algo potable, y tirar de vdp para una parte al menos

Ahora q algun juego lo use, ni idea

No se de ningún juego que lo use, ni creo que lo haya por que creo recordar que funciona mal. Además tampoco sabes que sprites han colisionado ¿¿?? Posiblemente fuera ideado para cuestiones gráficas internas del chip.

Eteream escribió:Cuando llegamos al punto de inventarnos cosas para "ganar" una discusión mal vamos. En 16bits y juegos 2D similares NO SE USA NINGUNA BOUNDING BOX PARA MOVERSE POR EL TERRENO!!!. Léete mejor la documentos que tu mismo posteas.

Eteream escribió:

theelf escribió:Al menos en megadrive encuentro muy util el uso de bounding box para deteccion de coliciones en mapas

Por supuesto, es un cálculo muy rápido y se usa en todos los juegos, no sólo los de MD. Pero para deslizarse por terrenos ya sean 2D o 3D, tiene problemas y suele usarse otros métodos.

No hace falta decir más, ¿verdad? Tú solo te has dado cuenta de tu metida de pata, ¿no? Pues eso, si quieres tener pruebas y no quedar en evidencia de nuevo, te pones a analizar el código fuente de juegos como yo para saber de qué hablas.

Suerte

Perdón, un inciso...

¿Cual hubiera sido la función de una memoria VRAM para el PPU2?, ¿mezclar colores?.

Veo que se está hablando de colisiones, un par de apuntes. Primero, los vdp pueden tener en efecto bit de colisión que se activa si 2 sprites han colisionado. Por otro, las colisiones se comprueban por software en efecto y existen diversas técnicas, la mayoría orientadas a colisiones geométricas (circular, elipsoidal, rectangular...)

El bit de colisión del vdp es un buen aliado pues evita comprobar a cada frame si 2 sprites colisionan, ahorrando proceso. Si el bit se activa, entonces pasamos a la comprobación software para ver quienes han colisionado.

AxelStone escribió:Veo que se está hablando de colisiones, un par de apuntes. Primero, los vdp pueden tener en efecto bit de colisión que se activa si 2 sprites han colisionado. Por otro, las colisiones se comprueban por software en efecto y existen diversas técnicas, la mayoría orientadas a colisiones geométricas (circular, elipsoidal, rectangular...)

El bit de colisión del vdp es un buen aliado pues evita comprobar a cada frame si 2 sprites colisionan, ahorrando proceso. Si el bit se activa, entonces pasamos a la comprobación software para ver quienes han colisionado.

Eso estaría bien en la SNES, pero no existe ese método por hardware; es por eso que hablaba de que es más dificultoso hacer una detección de colisiones precisa con un sprite 64x64 a menos de que el perfil del personaje se ajuste más o menos bien al bounding-box.

Refloto para colgar la aclaratoria respuesta que Gasega68k dió al respecto en otro hilo, para que quienes hayan podido acceder a éste desde Google puedan también llegar a una conclusión:

gasega68k escribió:He estado leyendo un poco este hilo desde hace unos días, pero me llamó la atención lo de la "rotacion de la bola de Super Aleste", y para los que se estaban preguntando, ya sé como lo hicieron.

Para averiguar esto, estuve probandolo con el emulador no$sns, solo hay que jugar un rato en el primer nivel hasta llegar al "jefe" de ese nivel (aunque no seguí jugando a partir de alli, pero me imagino que es el "jefe").

Primero, en "vram viewer" (en la pestaña tiles 4bpp) se puede ver que la bola solo rota 90 grados en total, asi que para completar la rotacion se usa "vflip" y "hflip".

Ahora, en "I/O Map" en la pestaña DMA, se puede ver en el canal 7(que está en modo "normal") que se hacen transferencias hacia vram desde diferentes locaciones en Ram, dependiendo del "frame" de la bola, he podido "contar" que son 9 frames.

Así que mi conclusión sería que en Rom solo debe existir un unico frame, y que luego se crean (por software) los "frames" de la rotación y estos se almacenan en Ram, de esta manera dependiendo del frame(o del grado de rotación) de la bola que se quiere mostrar, se tranfiere a vram el frame correspondiente, ademas de "jugar" con los "hflip" y "vflip" de los sprites.

@Señor Ventura , @Magno y otros que estén interesados, como el emulador no$sns no tiene "savestates", tienen que probarlo por ustedes mismos para confirmar (ó negar) lo que he dicho.

Saludos.

Es una rotación, pero vía C.P.U en la ram principal y después el DMA lo pasa a la vram.

Así que rota un metasprite de los grandecitos, y todavía queda libre la potencia épica de los PPU's para acompasar con aún mas efectos de rotación.


Hubiera tenido... bolas, la cosa.