Duda sobre el apartado técnico de Art of Fighting 2 Snes -Zoom Vs gráficos-

Si, podria haber tenido prácticamente los mismos escenarios que en neo geo.

A nivel de color, todo lo que den de si 256 colores.

A nivel de animación, todo lo que de de si el DMA después de dejar el suficiente tiempo para que la cpu ejecute toda la lógica del frame actual.


Todo se puede calcular para ver con exactitud como podría llegar a ser. Yo solo me molesté en mirar cuanto tamaño de sprites sería posible alcanzar, cuanto ancho de banda consumiría, y poco mas.




Sobre tu mensaje, lo resumo un poco:

1-Ni el aof 1 ni el aof2 originales tienen scroll parallax (por regla general, no se si el escenario de eiji tenía algo, aunque creo que era directamente un segundo plano).

2-Si, es posible hacer interrupciones en un plano en modo 7 para obtener scroll parallax, además de otros efectos.

3-Los planos en modo 7 no son gráficamente mas simples por ser modo 7, son mas simples porque los diseñaban así. Un plano en modo 7 ocupa un área de hasta 1024x1024 pixels, con tiles de 64 Bytes, así que el límite está en los aproximadamente 62,96 KB de VRAM que quedan libres después de lidiar con la tabla OAM, y la CGRAM, puesto que la tabla de atributos del modo 7 se guardan en la WRAM. Es decir, alcanza para hacer planos en modo 7 con mucho lujo de detalles. Todo depende de cuanto quieras dispersarlos

4-Ni aof 1 ni aof 2 en snes realiza escalado de sprites. Tiene un nombre que no recuerdo, pero básicamente consiste en apilar los sprites unos encima de otros, además de que creo que borra pixels dentro de cada tile, o algo así, tendría que mirarlo. Sale mas barato que procesar un escalado real.

5-Usar el método de turbo grafx para el zoom no es posible porque en primer lugar la snes implementa un escalado real que supera a aquel resultado, y porque en segundo lugar la snes no almacena sprites de dos tamaños diferentes simultáneame como presuponiblemente si debe estar haciendo la arcade card de la turbo grafx.

6- Los personajes en snes están diseñados para que casi en el peor caso posible no puedan haber parpadeos, pero podría alcanzarse el tamaño de la versión turbo grafx sin ningún problema a cambio de encontrarte en alguna ocasión algún parpadeo, o igualar el tamaño de los personajes de la versión neo geo con parpadeos mas o menos frecuentes.

@Señor_Ventura, mil gracias por tomarte la molestia de responderme con tanto detalle, me ha quedado muy claro y estaba confundido en varias cosas. Es reconfortante saber que con dedicación y un cartucho de mayor capacidad, Snes podría haber tenido una versión mucho más cercana al original.

Señor Ventura escribió:Ni el aof 1 ni el aof2 originales tienen scroll parallax (por regla general, no se si el escenario de eiji tenía algo, aunque creo que era directamente un segundo plano).

Si, el escenario de Eiji parece tener scroll o segundo plano (no sé diferenciarlos), se muestra a la altura del coche o Hummer, como bien dices parece ser el único escenario de AOF 2 que lo tiene,



hay varios juegos de Neo Geo con zoom en los que ciertos escenarios tienen scroll, dos de ellos creo que son Galaxy Fight y Kizuna Encounter, del que pienso que es de lo más bruto que puede verse en Neo Geo a pesar de ser -diría- un título algo tapado. Pararme en esto vino al pensar en los juegos de Konami que utilizan placas más potentes, como Dragoon Might, donde zoom+scroll es muy común, aunque la diferencia de capacidad entre un sistema y otro es enorme logicamente, la diferencia es que esas placas apenas fueron exprimidas, mientras que Neo Geo sí lo fue... quizás Violent Storm o el propio Dragoon Might, sí dieron muestras de parte de ese potencial. En este sentido el mayor desperdicio fué a mi juicio CPS-3, donde un sólo juego mostró una pequeña parte de lo que lleva dentro, Warzard.

Señor Ventura escribió:Si, es posible hacer interrupciones en un plano en modo 7 para obtener scroll parallax, además de otros efectos.

En verdad dí por hecho que no era posible o bien, que de poder hacerlo, el impacto en el rendimiento sería prohibitivo, el motivo de pensarlo siempre fueron las ralentizaciones en esta fase de Super Castlevania IV, (vista desde mi enorme ignorancia), que sabiendo ahora lo vital que resulta utilizar FastRom, quizás no se limitaba a una posible falta de optimizacion..

https://youtu.be/VAGCkr380NU?t=324

Señor Ventura escribió:Los planos en modo 7 no son gráficamente mas simples por ser modo 7, son mas simples porque los diseñaban así. Un plano en modo 7 ocupa un área de hasta 1024x1024 pixels, con tiles de 64 Bytes, así que el límite está en los aproximadamente 62,96 KB de VRAM que quedan libres después de lidiar con la tabla OAM, y la CGRAM, puesto que la tabla de atributos del modo 7 se guardan en la WRAM. Es decir, alcanza para hacer planos en modo 7 con mucho lujo de detalles. Todo depende de cuanto quieras dispersarlos

Otro grave error de concepto, desde el total desconocimiento, mi teoría era que debian de ser simples porque a la hora de ser gestionados, a mayor parquedad, mayor facilidad para la consola y en consecuencia, mayor rendimiento.
Pero además, me empeciné en que la sencillez de trazo era algo rígido, no opcional, cuando en el mapa de varios juegos de Rol sí que se ve mayor riqueza.. incluso en los propios AOF parcialmente.

Hace meses y tambien ahora, busqué info en esa dirección, pero para mi es empezar la casa por el tejado,

https://www.reddit.com/r/snes/comments/ ... g_on_snes/

https://www-reddit-com.translate.goog/r ... pto=nui,sc

https://www.reddit.com/r/gamemaker/comm ... esolution/

Señor Ventura escribió:Ni aof 1 ni aof 2 en snes realiza escalado de sprites. Tiene un nombre que no recuerdo, pero básicamente consiste en apilar los sprites unos encima de otros, además de que creo que borra pixels dentro de cada tile, o algo así, tendría que mirarlo. Sale mas barato que procesar un escalado real.

Usar el método de turbo grafx para el zoom no es posible porque en primer lugar la snes implementa un escalado real que supera a aquel resultado, y porque en segundo lugar la snes no almacena sprites de dos tamaños diferentes simultáneame como presuponiblemente si debe estar haciendo la arcade card de la turbo grafx.

Tampoco lo he encontrado, en los enlaces anteriores creo que hablan un poco de ello.

Llevas razón, en PC Engine hicieron esa técnica porque no tenían opción alguna a nivel de hardware, y entiendo que programar una rutina específica o truco al estilo MegaDrive (Batman & Robin, Dynamite Headdy), era inviable a nivel de rendimiento por las limitaciones del procesador principal.

Señor Ventura escribió:Los personajes en snes están diseñados para que casi en el peor caso posible no puedan haber parpadeos, pero podría alcanzarse el tamaño de la versión turbo grafx sin ningún problema a cambio de encontrarte en alguna ocasión algún parpadeo, o igualar el tamaño de los personajes de la versión neo geo con parpadeos mas o menos frecuentes.

En los últimos meses he reparado en ese detalle, las compañias por lo general eran 'conservadoras', y no temian meter tijera a cambio de que la acción fuese fluida en todo momento, o evitar parpadeos, sólo Konami con Axelay o en menor medida Capcom con Final Fight 2, 8 (dos jugadores en modo expert), se saltaron esa línea.. a nivel particular prefiero ver acción en la Super a pesar de pagar ese pequeño o a veces mediano precio, si Capcom hubiese sido un poco menos conservadora y 'vaga', por ejemplo los personajes de SSF II podrían haber sido algo más grandes, más similares al arcade, y al vez tener parte de las animaciones vanguardia/retaguardia, al menos eso pienso desde el desconocimiento, aunque cuando dos colosos como CPS-1 y Neo Geo se ven obligadas a reducir tamaños para poder moverse mejor/más (Cadillacs & Dinosaurs y Garou), hay que otorgarle su parte de razón a las compañias.

En este sentido, el límite de sprites por scanline es otro tema que me inquieta, pero documentación habéis dejado con anterioridad, y el tema es muy complejo para mí, en relación a que antes de abordar ciertos aspectos, tendría que aprender un montón de cosas básicas que desconozco.


Gracias de nuevo por haber respondido con tanta dedicación.

Me pregunto que finalidad tienen estos hilos realmente es decir, por que esa obsesión de si podía hacer o no hacer y por que motivo no se hizo.

@Unreal McCoy Creeme, no he podido responder con detalle xD

En otro momento me pondré a ello con detenimiento, mas que nada porque está entre mis planes planificar un proyecto sobre esto, y hasta aquí puedo escribir. De momento estoy liado con otras responsabilidades y no puedo ni empezar.

De lo que he dicho habría que matizar un par de cosas, pero si quieres leer algo mas, escribí un post hace tiempo precisamente sobre el art of fighting 2. Ten en cuenta que muchas cosas de las que digo ahí están mal si se interpretan literalmente, ya que casi cada dato que estoy poniendo ahí conlleva una explicación que no estoy dando.


hilo_batalla-campal-snes-vs-megadrive-patio-de-colegio-on_2186472_s10050#p1746742669

NewDump escribió:Me pregunto que finalidad tienen estos hilos realmente es decir, por que esa obsesión de si podía hacer o no hacer y por que motivo no se hizo.

No puedo darte una respuesta concreta porque en verdad no la conozco, es una mezcla extraña de sentimientos difícil de definir con palabras.. mi opinión es que gran cantidad de aficionados 'personalizamos' a las máquinas, las sentimos como algo vivo y que debe ser cuidado en lugar de verlas como meros objetos inertes, o como máquinas que sólo están para divertirnos, en consecuencia queremos que 'vivan' bien, que se haga 'justicia' con ellas, y ya nada más que entrar en un concepto tan abstracto y seguramente irreal como es la justicia, daría para escribir muchos libros.. Los recuerdos de la época, con ese resorte tan poderoso que es la nostalgia, hacen tambien que ,dentro de mi óptica, se mitifiquen las compañías y los propios juegos clásicos.

Tambien en mi caso particular, siento una profunda inclinación por comparar, por ese ''ver como'', a nivel de música y videojuegos clásicos aún más, no te imaginas cuantas veces le he dado vueltas a canciones que se hicieron tomando arreglos, samples o riffs de otras, o de cómo hubiera quedado Vigilante de Master con la técnica de ''sprites por software", como hubiera quedado Altered Beast sin ella, o soñar con un Violent Storm en Neo Geo, ¿es mucho más productivo pensar en hacer juegos originales?, si, es lo deseable, pero no me resulta tan atractivo de hablar, y tampoco EOL es un foro técnico de programación. Será cuestion de esforzarse y pensar en aquello de que los sentimientos antes de serlo son pensamientos, a lo mejor así consigo ser más coherente y productivo.

Señor Ventura escribió: Creeme, no he podido responder con detalle xD

En otro momento me pondré a ello con detenimiento, mas que nada porque está entre mis planes planificar un proyecto sobre esto, y hasta aquí puedo escribir. De momento estoy liado con otras responsabilidades y no puedo ni empezar. De lo que he dicho habría que matizar un par de cosas, pero si quieres leer algo mas, escribí un post hace tiempo precisamente sobre el art of fighting 2. Ten en cuenta que muchas cosas de las que digo ahí están mal si se interpretan literalmente, ya que casi cada dato que estoy poniendo ahí conlleva una explicación que no estoy dando.

hilo_batalla-campal-snes-vs-megadrive-patio-de-colegio-on_2186472_s10050#p1746742669

Lo suponía he visto multitud de post tuyos hablando del tema con compañeros como Sexy, Gynion, Kusfo, Titorino, entre otros, pero te has tomado un tiempo para responderme y lo valoro mucho. Ojalá tu proyecto pueda iniciarse pronto, pienso que será interesante porque expuesto en el estilo habitual, en formato coloquio, el resultado suele ser negatividad, piques y repetición, pero lo interesante es que esos conocimientos pudiesen utilizarse a modo de guía para programar en Snes, para uien quiera ponerse o para que pequeños grupos de proramación homebrew puedan tomar ideas o conceptos que aún no tenían pulidos.

Conozco el hilo de Batalla Campal, volveré a leerlo.

@Unreal McCoy se trata de empezar de cero con semejante tarea, pero vamos, porque me apetece. Es posible que me lo quede para mi también, ya vería xD

El hilo que mencionas no sirve casi nada como referencia, entre inexactitudes y piques no creo que quede casi nada en aquel hilo que merezca ser tenido en cuenta.

Sin tardar empezaré a tener tiempo libre, así que a menos que se me tuerza algo trataré de hablar del art of fighting 1 y 2 lo mas extendido posible, siempre desde la perspectiva de snes en lo técnico.

El principal motivo por el que los fondos en este juego se ven muy simples es que los fondos en modo 7 tienen muchas limitaciones en comparación con el resto de modos:

• Un fondo en modo 7 sólo puede tener como máximo 256 tiles, mientras que en el resto de modos los fondos pueden tener muchos más (creo que hasta 1024).
• Un fondo en modo 7 no soporta tiles de 4 ni de 16 colores, sólo de 256, por lo que cada tile consume mucha más VRAM.
• Un fondo en modo 7 no soporta flipping o espejos: en el resto de modos si un tile es como otro invertido en el eje horizontal o vertical no hace falta consumir VRAM para los dos tiles, sólo para uno de ellos.
• En el modo 7 sólo hay un fondo disponible, mientras que en el resto de modos suele haber más fondos disponibles.

El espacio que ocupan en el cartucho los fondos no es un problema tan grande como los mencionados, ya que en comparación con un fondo "normal" un fondo en modo 7 sin comprimir debería ocupar un poco menos del doble de ROM, y si se comprime seguro que la diferencia se reduce bastante.

Señor Ventura escribió:se trata de empezar de cero con semejante tarea, pero vamos, porque me apetece. Es posible que me lo quede para mi también, ya vería xD.

Opino que este tipo de trabajos deben salir de dentro, no tendrían ningún sentido si se hacen por obligación o sin verdaderas ganas.

Señor Ventura escribió:El hilo que mencionas no sirve casi nada como referencia, entre inexactitudes y piques no creo que quede casi nada en aquel hilo que merezca ser tenido en cuenta.

El problema de los hilos 'tecnicos' en EOL, como yo lo veo, es que la vehemencia y el enfoque empleados terminan siempre arruinándolos, es el motivo de que se acaben viendo como algo nefasto, insano y que al final, guarda poca o ninguna relación con esta afición.

Lo que voy a decir es políticamente incorrecto, pero pienso el problema viene de que una parte de compañeros interpretan los debates técnicos no como algo instructivo, informativo -valioso-, sino como una sacada de chorra de sus autores que hablan motivados en demostrar cuánto saben, dando lugar a un ''a ver si te callas que no me interesa lo que sepas'', En los foros en Inglés que he leido ocurre al contrario, son hilos constructivos en lugar de ser vistos como detestables, porque existe un ánimo de aprender, en vez de criticar. Entre este factor quizás subjetivo y los certeros piques nostálgicos, es imposible avanzar. Me recuerda al hecho de que en España cada vez parezca más vergonzoso hablar con palabras 'selectas' -mostrar riqueza léxica-, que en muchas ocasiones se interpretan como rimbombantes e innecesarias.. algo que por fortuna aún no ocurre en Latino América, exceptuando el uso continuo de palabras Anglosajonas y anglicismos.

Hasta que no cambiemos el enfoque, los hilos de debate técnico no tendrán verdadera cabida en EOL. -tambien es cierto que titular a un hilo ''batalla campal patio de colegio'', no ayudaba demasiado, como en un 'voy a poner la tirita antes de tener la herida, que ya sé de antemano como acabará', al final facilitas que pase lo que en los viajes en el tiempo se conceptua como paradoja, -ocurrió porque tenia que ocurrir, o porque viajé al pasado-. En fin, disculpas por la disertación, que ni sirve para algo ni era necesaria en este hilo, sólo que necesitaba sacarmela de dentro porque me duele que ocurra así.

Señor Ventura escribió:Sin tardar empezaré a tener tiempo libre, así que a menos que se me tuerza algo trataré de hablar del art of fighting 1 y 2 lo mas extendido posible, siempre desde la perspectiva de snes en lo técnico.

Creo que un número de usuarios te vamos a agradecer muchísimo ese esfuerzo espero y deseo que la documentación sea invertida en proyectos útiles.

GValiente escribió:El principal motivo por el que los fondos en este juego se ven muy simples es que los fondos en modo 7 tienen muchas limitaciones en comparación con el resto de modos:

• Un fondo en modo 7 sólo puede tener como máximo 256 tiles, mientras que en el resto de modos los fondos pueden tener muchos más (creo que hasta 1024).
• Un fondo en modo 7 no soporta tiles de 4 ni de 16 colores, sólo de 256, por lo que cada tile consume mucha más VRAM.
• Un fondo en modo 7 no soporta flipping o espejos: en el resto de modos si un tile es como otro invertido en el eje horizontal o vertical no hace falta consumir VRAM para los dos tiles, sólo para uno de ellos.
• En el modo 7 sólo hay un fondo disponible, mientras que en el resto de modos suele haber más fondos disponibles.

El espacio que ocupan en el cartucho los fondos no es un problema tan grande como los mencionados, ya que en comparación con un fondo "normal" un fondo en modo 7 sin comprimir debería ocupar un poco menos del doble de
ROM, y si se comprime seguro que la diferencia se reduce bastante.

Muchas gracias por participar y por dejarnos esta información, hace tres años leí sobre el Modo 7 en distintas comunidades en Inglés, pero no recuerdo prácticamente nada, ni poseo la base necesaria para comprender conceptos más complejos. En la creencia mía, el plano en Modo 7 es en parte similar a una de las capas de Snes, que sólo puede mostrar cuatro colores y suele utilizarse para nubes, fondos simples o parte del marcador, -no recuerdo si es la cuarta o la tercera capa-, por esto muchos juegos tienen el Hud monocromo, -gris o marrón camel-, es decir, con importantes limitaciones de color y resolución, aunque ni siquiera recuerdo si tenía ese concepto por haberlo hablado en ocasiones con un buen amigo bastante más conocedor que yo, o por haber malinterpretado lo leido en Inglés, ya que mi nivel es bajísimo.. es por ese motivo que responsabilicé al Modo 7 sustentando el zoom, de la poca calidad de los decorados, junto con la conversión de Samurai Shodown para Snes, donde por así decirlo se empleó la fórmula inversa en en AOF, -sin zoom, y con personajes pequeños- mostrando unos escenarios gloriosos.

Sobre esta capa y los HUD monocromo, Magno arrojó la siguiente información, disculpad que me desvíe, acabo de recordarlo,

GValiente escribió:Un fondo en modo 7 no soporta flipping o espejos: en el resto de modos si un tile es como otro invertido en el eje horizontal o vertical no hace falta consumir VRAM para los dos tiles, sólo para uno de ellos

Temo que en Unholly Night abusaron de esa posibilidad, lo que viendo el tamaño del cartucho y su aspecto global, no tiene demasiado sentido.

GValiente escribió:En el modo 7 sólo hay un fondo disponible, mientras que en el resto de modos suele haber más fondos disponibles.

Lo desconocía, pero por algún motivo veía inviable hacer scroll en plano en Modo 7 porque más allá de poder rotarlo o acercarlo, lo encontraba muy inamovible y limitado, es complicado de explicar.. y es una característica que he visto en Snes mal que me pese decirlo, algunos juegos son 'rigidos', se notan estáticos, mientras que en MegaDrive la acción tanto sonora como gráfica parecia mucho más fluida.. esto siempre lo he achacado a lo dificultoso de programar para ella, al menos en relación con otras plataformas basadas en un M680000.


Quisiera extenderme más pero ni mis conocimientos ni en este momento el tiempo acompañan, muchas gracias por las respuestas.

Unreal McCoy escribió:En la creencia mía, el plano en Modo 7 es en parte similar a una de las capas de Snes, que sólo puede mostrar cuatro colores y suele utilizarse para nubes, fondos simples o parte del marcador, -no recuerdo si es la cuarta o la tercera capa-, por esto muchos juegos tienen el Hud monocromo, -gris o marrón camel-, es decir, con importantes limitaciones de color y resolución

Eso aplica a algunos del resto de modos de vídeo, no al modo 7. En el modo de vídeo más utilizado (no recuerdo cuál), la SNES ofrece dos fondos con 16 colores por tile y otro con 4 colores por tile. Este último fondo es el que se suele usar para el marcador, de ahí vienen las limitaciones de color.

Unreal McCoy escribió:

GValiente escribió:Un fondo en modo 7 no soporta flipping o espejos: en el resto de modos si un tile es como otro invertido en el eje horizontal o vertical no hace falta consumir VRAM para los dos tiles, sólo para uno de ellos

Temo que en Unholly Night abusaron de esa posibilidad, lo que viendo el tamaño del cartucho y su aspecto global, no tiene demasiado sentido.

Si quieres que fondos de imágenes digitalizadas te quepan en la VRAM, junto a sprites, marcadores y el resto de elementos gráficos, no te queda otra que abusar de espejos.

Unreal McCoy escribió:

GValiente escribió:En el modo 7 sólo hay un fondo disponible, mientras que en el resto de modos suele haber más fondos disponibles.

Lo desconocía, pero por algún motivo veía inviable hacer scroll en plano en Modo 7 porque más allá de poder rotarlo o acercarlo, lo encontraba muy inamovible y limitado, es complicado de explicar.. y es una característica que he visto en Snes mal que me pese decirlo, algunos juegos son 'rigidos', se notan estáticos, mientras que en MegaDrive la acción tanto sonora como gráfica parecia mucho más fluida.. esto siempre lo he achacado a lo dificultoso de programar para ella, al menos en relación con otras plataformas basadas en un M680000.

El fondo del modo 7 ofrece las mismas o más posibilidades de movimiento que los fondos del resto de modos de vídeo, es la CPU la que no acompaña.

@GValiente, muchas gracias. Quería matizar que dije ''En la creencia mía, el plano en Modo 7 es en parte similar a una de las capas de Snes'', hablando como mi yo del pasado, porque tanto tú compañero, como Señor Ventura, me estáis informando y sacando del error.

GValiente escribió:Eso se aplica a algunos del resto de modos de vídeo, no al modo 7. En el modo de vídeo más utilizado (no recuerdo cuál), la SNES ofrece dos fondos con 16 colores por tile y otro con 4 colores por tile. Este último fondo es el que se suele usar para el marcador, de ahí vienen las limitaciones de color.

Sería el Modo 1, lo explica Magno en el mensaje del que colgué una imagen en mi post anterior, creo que el comenta lo mismo que me detallas. Por fortuna no siempre se utilizó de la misma forma, ejemplos son Secret of Mana o Sailor Moon, porque era un poco chocante ver, por ejemplo en SlamMasters, las caras del HUD coloridas en MegaDrive.. y monocromas en Snes, siendo Capcom muy habitual de esta práctica.

GValiente escribió:Si quieres que fondos de imágenes digitalizadas te quepan en la VRAM, junto a sprites, marcadores y el resto de elementos gráficos, no te queda otra que abusar de espejos.

Lo comprendo y encuentro lógico, sin embargo en Unholly Night abusaron del espejado sin -pienso- necesidad real, los escenarios no son digitalizados, tiene 32 Megas, un escaso número de luchadores y la calidad técnica general es mediocre a mi juicio, lejos de lo que cabría esperar de Snes en 2017 considerando el grupo de programación y que es un juego oficial.

GValiente escribió:El fondo del modo 7 ofrece las mismas o más posibilidades de movimiento que los fondos del resto de modos de vídeo, es la CPU la que no acompaña.

Sí, los 3,64 Mhz, por algún motivo achaqué más la responsabilidad a la técnica que al procesador. En recreativa, el Modo 7 -o una técnica muy similar- era bastante efectista -por ejemplo Assault de Namco o Typhoon-Ajax de Konami-, pero tambien notaba cierta limitación en ellos.

A pesar de sus carencias, he leido que el 5A22 tenía la virtud de ser muy exprimible 'picando código' como suele decirse.. de todas formas me es imposible negar que siempre he tenido la sensación de que Snes es una máquina con un procesador gráfico y sonoro muy buenos, con una cantidad generosa de Ram, pero que todas esas virtudes quedaban ahogadas o en un segundo plano por tener una CPU principal escasa.

Unreal McCoy escribió:Lo comprendo y encuentro lógico, sin embargo en Unholly Night abusaron del espejado sin -pienso- necesidad real, los escenarios no son digitalizados, tiene 32 Megas, un escaso número de luchadores y la calidad técnica general es mediocre a mi juicio, lejos de lo que cabría esperar de Snes en 2017 considerando el grupo de programación y que es un juego oficial.

¿Estás seguro de que no son digitalizados?
Tienen toda la pinta:
https://cdn.gamer-network.net/2016/usgamer/Unholy-Night-Shot-02.png
https://cdn.gamer-network.net/2016/usgamer/Unholy-Night-Shot-05.png
https://www.micromania.fr/dw/image/v2/BCRB_PRD/on/demandware.static/-/Sites-masterCatalog_Micromania/default/dw4b1fdb8c/images/high-res/unholy_night_4.jpg
https://www.destructoid.com/ul/404559-new-snes-fighting-game-set-to-launch-in-february-2017/cap15%20copy-noscale.jpg

GValiente escribió:¿Estás seguro de que no son digitalizados?
Tienen toda la pinta:
https://cdn.gamer-network.net/2016/usga ... hot-02.png
https://cdn.gamer-network.net/2016/usga ... hot-05.png
https://www.micromania.fr/dw/image/v2/B ... ight_4.jpg
https://www.destructoid.com/ul/404559-n ... oscale.jpg

llevas razón, no los recordaba bien la mayoría parecen digitalizaciones.

bueno, en mi cabeza tenía el recuerdo de que eran 'pseudo-digitalizaciones', como por ejemplo parecen serlo las imágenes del ending de Golden Axe de Master System,






es decir, que se asemejan a una digitalización al uso pero en realidad no lo son exáctamente, sino que toman modelos reales 'repintándolos' despues, o bien realizando un dibujo muy detallado en base a ese modelo, para así ahorrar en tamaño.

Con todo, lo peor de Unholly, bajo mi prisma, es el aspecto que muestran los personajes, la poca fluidez de movimientos, falta de scroles, una resolución que aparenta ser bajísima.. creo que se podría haber hecho mucho mejor y es una pena, porque el trabajo en global tenía mimbres para llegar a hacer un juego interesante, como un cruce entre Darkstalkers, Guilty G ear y Garou, para mí fué una oportunidad perdida, y más con la carestía de homebrew que hay en Super. Gracias de nuevo y perdón por desviar la temática del hilo.

@Unreal McCoy el motivo de que no puedas espejar tiles en modo 7, entre otras funciones, es porque usa un formato de imagen que no usa los atributos "indexados" que si usan los planos en el resto de modos gráficos (a grandes rasgos).

Lo de los 256 tiles para planos en modo 7 es la primera vez que lo leo. No veo motivos que hagan pensar que no puedas usar toda la vram que quieras para dibujar planos en el, con sus 256 colores, y todo.


Luego hay ciertas escenas que en teoría no pueden transladarse a super nintendo... pero si que se puede.



En snes está hecho así para evitar parpadeos... pero ya digo que no es necesario porque se puede hacer igual, o casi casi igual.







P.D: mira, modo 7 con interrupciones por línea. Con ellas puedes dividir un plano en varias secciones para hacer scroll:



...o efectos como este:

Señor Ventura escribió:Lo de los 256 tiles para planos en modo 7 es la primera vez que lo leo. No veo motivos que hagan pensar que no puedas usar toda la vram que quieras para dibujar planos en el, con sus 256 colores, y todo.

En los fondos "normales" la SNES utiliza una variable de 16 bits para cada celda del fondo, por lo que puede indexar por ejemplo la paleta de colores a utilizar (16 paletas = 4 bits), el espejo horizontal y vertical (2 bits) y quedan 10 bits para el índice de tile a mostrar, por lo que cada fondo puede indexar hasta 1024 tiles.

Sin embargo, el fondo del modo 7 utiliza una variable de sólo 8 bits para cada celda del fondo, por lo que no soporta paletas de colores ni espejos, y además sólo puede indexar hasta 256 tiles.

Señor Ventura escribió:el motivo de que no puedas espejar tiles en modo 7, entre otras funciones, es porque usa un formato de imagen que no usa los atributos "indexados" que si usan los planos en el resto de modos gráficos (a grandes rasgos).

Casi cristalino, a pesar de mi profanía. Supongo que no existe la posibilidad de utilizar un algoritmo de compresión o un 'conversor fly by fly', o que de serlo, a cambio el rendimiento caería en picado.

Señor Ventura escribió:Lo de los 256 tiles para planos en modo 7 es la primera vez que lo leo. No veo motivos que hagan pensar que no puedas usar toda la vram que quieras para dibujar planos en el, con sus 256 colores, y todo.

Me suena más lógico lo que comenta GValiente, pero porque concide más con mi prejuicio inicial cimentado en la más pura ignorancia, no porque realmente lo sea, que como comprendereis, me resulta un total enigma.

Señor Ventura escribió:Luego hay ciertas escenas que en teoría no pueden transladarse a super nintendo... pero si que se puede.En snes está hecho así para evitar parpadeos... pero ya digo que no es necesario porque se puede hacer igual, o casi casi igual

El fastidioso limite horizontal de sprites por scantine, supongo, no veo cómo saltarselo, y mira que os he leido veces.. quizás jugando con las capas y el DMA, o tal vez con los tiles de fondo, a lo Master System en Golden o Altered el estos intringulis son muy atractivos vistos desde fuera cuando son otros los que proraman, si tuviera que hacerlo yo, madre mía...

Señor Ventura escribió:P.D: mira, modo 7 con interrupciones por línea. Con ellas puedes dividir un plano en varias secciones para hacer scroll:

precioso, casi parece un juego de 32 Bits o de Neo Geo, Goemon lo tengo pendiente en Snes desde hace demasiado tiempo. ''Meteoro'' lo conozco, es tambien una pasada, a mi juicio es una especie de evolución del denostado Super Off Road The Baja, que siempre me pareció un juego muy incomprendido.. a su vez, NBA Give N' Go injustamente subvalorado -con tu permiso te tomo prestado el .gif-

GValiente escribió:En los fondos "normales" la SNES utiliza una variable de 16 bits para cada celda del fondo, por lo que puede indexar por ejemplo la paleta de colores a utilizar (16 paletas = 4 bits), el espejo horizontal y vertical (2 bits) y quedan 10 bits para el índice de tile a mostrar, por lo que cada fondo puede indexar hasta 1024 tiles.

Sin embargo, el fondo del modo 7 utiliza una variable de sólo 8 bits para cada celda del fondo, por lo que no soporta paletas de colores ni espejos, y además sólo puede indexar hasta 256 tiles.

Muchas gracias tambien a tí GValiente por la valiosa info, ojalá tuviera la base necesaria para poder comprenderlo todo mucho mejor, y al menos tener una opinión propia.

Si el AOF2 de SNES lo llega a programar Tiertex seguro que sale identico al de NEOGEO ,o meLjor

Emerald Golvellius escribió:Si el AOF2 de SNES lo llega a programar Tiertex seguro que sale identico al de NEOGEO ,o meLjor

Si, y si incluyes a Appaloosa y a THQ en el grupo, ya tendríamos la fiesta completa. ríase del AOF de PC Engine.

Me has hecho recordar a aquel dibujo publicado por en lector en la sección Que locura de H.C, donde salían dos bloques rectangulares hablando, ''Hombre, ya sabíamos que programar Virtua Fighter para 32X era difícil, ¡pero tanto como para que los luchadores salgamos así!''.. con Tiertex más que bloques rectangulares hubieramos tenido una pantalla de calculadora gráfica, -o cosas peores-..




El PC se desaprovechaba bastante en los 90, -punto de vista subjetivo-, pero gracias a dios juegos como Caveman Ninja no cayeron en manos de US Gold o Tiertex, seguro que no tendría mucho que ver con la excelente adaptación de Ocean. Sorry por el offtopic.

De todas maneras nunca ha salido un buen Port de Neo Geo en las 16 bits de Sega y Nintendo . Alguna cosa " aceptable " puede pero bueno nada . Por algo será y no creo que sea por las limitaciones técnicas . Bajo mi opinión hacían las cosas con bastante dejadez adrede como diciendo si quieres jugar en condiciones vas a la recreativa o te pillas una AES . Es que si comparas los ports con cualquier otro juego de otras compañías salta a la vista que la cosa podía haberse trabajado más dando un resultado mejor .
Un ejemplo claro aquí en Snes lo tenemos con el Fatal Fury Special de 32 megas que además no es un mal port pero si lo comparas con el de SSF2 también de 32 megas como que canta bastante la diferencia y dices creo que la cosa podría haber sido mejor .
En cambio vas a PCECD y son la Ostia . Por supuesto que gracias también los MB de RAM extra pero coño que tiene una CPU de 8 bits y claro luego te enteras que se encargó del Port la propia Sunsoft con lo que se hizo la cosa exprimiendo al sistema . Bueno y diría que el mejor Port de un juego de Neo Geo en relación a las capacidades técnicas de un sistema ha sido el Fatal Fury Special para la GG que es acojonante . Con lo que queda demostrado que si se quiere se puede .

@Hookun Esque en PCE al igual que en X68000 contaban con soporte de SNK,los tenian para lo que necesitaran,incluso para utilizar codigo original.

fijate en el FF SP de Mega CD,es increible...el juego va como le da la gana,te pueden hacer cualquier cosa,pero en PC Engine el comportamiento de la CPU es el de NEOGEO,eso es algo sorprendente.

para mi AOF2 de SNES no tiene salvacion ni tiene forma de hacerse,pero si creo que el primer AOF o el primer Fatal Fury podrian haber salido muy muy bien,AOF 2 es muy gordo,el desarrollo seria carisimo para lo que esa gente buscaba,les molaba excesivamente recortar...

pero viendo el primero de SNES me imagino que les diera por meter mas ganas y tiempo y si lo veo viable.

Unreal McCoy escribió:El fastidioso limite horizontal de sprites por scantine, supongo, no veo cómo saltarselo, y mira que os he leido veces.. quizás jugando con las capas y el DMA, o tal vez con los tiles de fondo, a lo Master System en Golden o Altered el estos intringulis son muy atractivos vistos desde fuera cuando son otros los que proraman, si tuviera que hacerlo yo, madre mía...

Realmente no te lo puedes saltar porque dibujar todo eso se pasa por mucho de su límite.

Sin embargo, puedes establecer varias posiciones de profundidad, y a cada cual le dices a la cpu con que tamaño de sprites debe dibujar las tiles de cada imagen.

Sprites grandes delante, sprites pequeños detrás... y el truco consiste en que todo sprite pequeño que quede completamente tapado, simplemente no se dibuja. De esa forma salvas mucha capacidad de dibujado por línea, y a partir de ahí el resto es calcular que tamaño debe tener cada imagen, y que perspectiva debe tener el carrusel de personajes.

El resultado intuyo que puede ser razonablemente parecido.

GValiente escribió:

Señor Ventura escribió:Lo de los 256 tiles para planos en modo 7 es la primera vez que lo leo. No veo motivos que hagan pensar que no puedas usar toda la vram que quieras para dibujar planos en el, con sus 256 colores, y todo.

En los fondos "normales" la SNES utiliza una variable de 16 bits para cada celda del fondo, por lo que puede indexar por ejemplo la paleta de colores a utilizar (16 paletas = 4 bits), el espejo horizontal y vertical (2 bits) y quedan 10 bits para el índice de tile a mostrar, por lo que cada fondo puede indexar hasta 1024 tiles.

Sin embargo, el fondo del modo 7 utiliza una variable de sólo 8 bits para cada celda del fondo, por lo que no soporta paletas de colores ni espejos, y además sólo puede indexar hasta 256 tiles.

¿Lo de usar atributos de 8 bits podría tener algo que ver con el modo extendido del modo 7?.

En un principio, diría que hacer una interrupción cada 32 líneas para actualizar esa tabla de forma que haga referencia a nuevas tiles (que ya estarían precargadas en la vram previamente), sería una solución factible ya que en un entorno tan controlado como el zoom de un plano que no involucra los tres ejes para moverlo, lo único que tienes que prever es que en la posición de zoom out no deben haber mas de 256 tiles por cada 32 líneas... o hacer un zoom aún mas lejano dibujando 256 tiles cada 16 líneas...u 8...

Cuanto mas lejano sea el zoom, mas interrupciones y mas actualizaciones de esa tabla de atributos.

En un principio lo veo factible, y hay espacio en la VRAM para tener precargado un escenario completo. Todo depende de la cpu que necesite la lógica de la acción en pantalla, mas las pertinentes interrupciones, mas el DMA necesario para los sprites y tablas, etc.

El mayor reto es encontrar el equilibrio entre tiempo de DMA y tiempo de CPU, y en base a eso elegir el tamaño de personajes, grado de zoom, etc.

Señor Ventura escribió:¿Lo de usar atributos de 8 bits podría tener algo que ver con el modo extendido del modo 7?.

Supongo que esa limitación se debe a que mientras que los fondos "normales" tienen un tamaño máximo de 512x512px, el fondo del modo 7 tiene un tamaño máximo de 1024x1024px.

Un fondo de de ese tamaño con 16bits por celda se come la mitad de la VRAM, y en lo que sobra aún tienes que almacenar los tiles tanto del fondo como de los sprites.

Supongo que lo hicieron para ahorrar VRAM entre otras cosas.

Señor Ventura escribió:En un principio, diría que hacer una interrupción cada 32 líneas para actualizar esa tabla de forma que haga referencia a nuevas tiles (que ya estarían precargadas en la vram previamente), sería una solución factible ya que en un entorno tan controlado como el zoom de un plano que no involucra los tres ejes para moverlo, lo único que tienes que prever es que en la posición de zoom out no deben haber mas de 256 tiles por cada 32 líneas... o hacer un zoom aún mas lejano dibujando 256 tiles cada 16 líneas...u 8...
Cuanto mas lejano sea el zoom, mas interrupciones y mas actualizaciones de esa tabla de atributos.

En un principio lo veo factible, y hay espacio en la VRAM para tener precargado un escenario completo. Todo depende de la cpu que necesite la lógica de la acción en pantalla, mas las pertinentes interrupciones, mas el DMA necesario para los sprites y tablas, etc.

El mayor reto es encontrar el equilibrio entre tiempo de DMA y tiempo de CPU, y en base a eso elegir el tamaño de personajes, grado de zoom, etc.

Algo parecido es lo que haría yo para aumentar el número de tiles máximo en un fondo de tipo modo 7 en la GBA, que es lo que más conozco.

La VRAM de la GBA está dividida en bancos, y en el registro del fondo se indica el banco de VRAM a mostrar. Para aumentar el número de tiles máximo se puede cambiar en cada línea horizontal de la pantalla el banco de VRAM a mostrar, con lo que tendrías para elegir en cada línea horizontal uno de los 4 bancos disponibles.

Lo mismo se puede hacer en la SNES cambiando el valor de este registro en cada línea horizontal de la pantalla.

Aunque en la GBA hay CPU de sobra para hacer eso, como dices en la SNES siempre hay que tener en cuenta la CPU disponible para ello, ya que sólo el escalado de sprites que hacen en el Art of Fighting 2 debe consumir bastante.

@GValiente al menos tendremos que agradecer que la tabla de transformaciones del modo 7 se almacene en la wram.

En un principio el rendimiento me da igual, solo busco que la snes pueda dibujar un art of fighting 1 y 2 lo mas fiel posible al juego original. Una vez conseguido eso ya te puedes plantear de todo… funcionar a 30fps, meter un pentium III en el cartucho…


El caso es que hay un juego en snes que simula dos planos en modo 7 simultáneos, ¡al estilo de los que una GBA puede hacer!, precisamente haciendo una interrupción en cada scanline. Los scanlines pares representan los tiles de un “grupo”, con su hdma para aplicar su transformación hacia un lado, y los scanlines impares representan los tiles de otro grupo, también con su hdma para aplicar la transformación hacia el contrario.

Vamos, que si es por cpu, hay esperanza de que el zoom para un AoF pueda permitir conservar una buena cantidad de rendimiento.


¿Puedes notarlo?. Ese efecto entrelazado siempre queda un poco guarrete, pero en una tele crt tiene que quedar muy disimulado, y a cambio ganas que parezcan dos planos en modo 7 simultáneos (sin que además parezca que la cpu sufra con tanta interrupción).





Otra cosa es interrumpir verticalmente (una o varias veces, dentro de cada scanline), pero con un chip de apoyo que aporte potencia, podrías simular el número de planos en modo 7 que te de la gana, sin recurrir a entrelazados, porque todo es a base de interrumpir las veces que sean necesarias cada scanline… el reto en realidad está en decirle a la máquina que prioridad existe para que unas interrupciones declaren tiles que tu sabes que pertenecen al plano de mas prioridad, pero que para la máquina todo es un solo plano

Es la máxima del principio “cuanto mas trabaje el programador, menos trabaja la cpu”.



Pero volviendo al art of fighting 2… tu que tienes pinta de saber latín sobre esto… ¿ves solucionable poner en pantalla a ryo y robert lanzándose dos haoh sho kooken?, ¿o dos jacks con mas tamaño de los que tiene el actual port cayendo al suelo al mismo tiempo, amenazando el límite de sprites por scanline?.





Yo tiraría p’alante, y que el juego flickee todo lo que le de la gana, pero como reto es interesante ver de que formas puedes solucionar esa sobrecarga… tal vez no dibujando los sprites de menor prioridad, pero son demasiado grandes…

Señor Ventura escribió:¿Puedes notarlo?. Ese efecto entrelazado siempre queda un poco guarrete, pero en una tele crt tiene que quedar muy disimulado, y a cambio ganas que parezcan dos planos en modo 7 simultáneos (sin que además parezca que la cpu sufra con tanta interrupción).

¿Qué juego es? Por echarle un ojo con algún emulador

Viendo el GIF me da la sensación que lo único que cambia en cada línea horizontal de la pantalla es el registro del blending, pero sin emulador a mano no puedo confirmar.

Señor Ventura escribió:Otra cosa es interrumpir verticalmente (una o varias veces, dentro de cada scanline), pero con un chip de apoyo que aporte potencia, podrías simular el número de planos en modo 7 que te de la gana, sin recurrir a entrelazados, porque todo es a base de interrumpir las veces que sean necesarias cada scanline… el reto en realidad está en decirle a la máquina que prioridad existe para que unas interrupciones declaren tiles que tu sabes que pertenecen al plano de mas prioridad, pero que para la máquina todo es un solo plano

Si metes chips de apoyo es mucho más fácil que el chip pinte el fondo él solito, dejando a la SNES en paz .

Señor Ventura escribió:Pero volviendo al art of fighting 2… tu que tienes pinta de saber latín sobre esto… ¿ves solucionable poner en pantalla a ryo y robert lanzándose dos haoh sho kooken?, ¿o dos jacks con mas tamaño de los que tiene el actual port cayendo al suelo al mismo tiempo, amenazando el límite de sprites por scanline?.

Yo tiraría p’alante, y que el juego flickee todo lo que le de la gana, pero como reto es interesante ver de que formas puedes solucionar esa sobrecarga… tal vez no dibujando los sprites de menor prioridad, pero son demasiado grandes…

El tema del límite de sprites en cada línea horizontal no hay forma de saltárselo sin parpadeos.

En mi opinión en la NES ya dolían los ojos cuando los sprites parpadeaban con lo pequeños que eran, así que imagínate cómo quedaría tener parpadeos en sprites gigantes como los del Art of Fighting.

EDIT

He estado investigando el Treasure Conflix con el Mesen-S y en la escena del GIF no muestra dos grupos de tiles de dos fondos diferentes, sino que simula mostrar dos fondos de otra forma.

Éste es el fondo que se muestra sin efectos.

Y éstos son los tiles almacenados en VRAM. Como se puede ver, no hay tiles para dos fondos.

La simulación de los fondos la hace cambiando en cada línea horizontal de la pantalla el registro del blending y los registros del tamaño de la ventana.

La verdad es que el Mesen-S viene genial para investigar cómo se hacían algunos efectos en la SNES.

Unreal McCoy escribió:Casi cristalino, a pesar de mi profanía. Supongo que no existe la posibilidad de utilizar un algoritmo de compresión o un 'conversor fly by fly', o que de serlo, a cambio el rendimiento caería en picado.

No necesariamente. Para definir el color hay que tirar de cpu en ciertas circunstancias, pero eso no significa que necesites hacerlo de una forma tan intesiva de forma obligada.

Todo ese rollo del direct color en ciertos modos gráficos es algo que nunca me he molestado en mirar demasiado. Pensaba que era una virtud, pero parece mas una necesidad por lo que comenta GValiente... el caso es que si haces una interrupción cada vez que el line buffer pinta un pixel para definir el siguiente color directamente de la paleta madre, realmente podrías dibujar un plano en modo 7 a 32768 colores... pero si no he entendido mal, ¿necesitas que el DMA transfiera 5 bits por cada pixel que dibujas de este modo? (ya no solo necesitas mucha cpu para interrumpir tantas veces, sino que el DMA necesita transferir mucho, dejando aún menos tiempo para la cpu). En teoría, con un chip de apoyo puedes plantar planos en modo 7 a 32768 colores sin pestañear (al menos en una consola PAL)... y eso también mola.

Luego ya está lo del límite de 256 tiles para un plano en modo 7, pero realmente basta con que hagas una interrupción para definir otro grupo de 256 nuevos tiles cuando los primeros 256 tiles sean dibujados, para así disponer para ese plano de tantos tiles como quepan en la VRAM, y por lo que parece no debería ser demasiado costoso para la cpu, por lo que ese problema no parece otra cosa que un engorro para el programador, porque es una limitación que tiene solución.

GValiente escribió:¿Qué juego es? Por echarle un ojo con algún emulador

Viendo el GIF me da la sensación que lo único que cambia en cada línea horizontal de la pantalla es el registro del blending, pero sin emulador a mano no puedo confirmar.

Pues se trata del treasure conflix.

Si que parece que solo esté cambiando el valor de cada scanline sobre un mismo grupo de tiles, así que solo estaría el hdma involucrado.

¿Con cuanto DMA habría que contar cada vez que saltas de una tabla de atributos a otra para hacer referencia a nuevos tiles?, ¿2KB enteritos?.

GValiente escribió:Si metes chips de apoyo es mucho más fácil que el chip pinte el fondo él solito, dejando a la SNES en paz .

El DMA es el que supone aquí una brecha insalvable... pero últimamente estoy leyendo bastante de las capacidades del SA-1 para transferir tiles prácticamente sin restricciones (lo cual dejaría una puerta abierta para que el DMA gaste todo el tiempo que necesite en definir colores y nuevos grupos de tiles). ¿Esto es realmente así?, porque de algún modo esto se está prestando a esa interpretación, y realmente pienso que no puede ser cierto.




Editado: Justo he posteado cuando has añadido esa nueva información... mirando mas de cerca el propio gif si que parecía que realmente cada scanline hacía referencia a los mismos tiles, y no otra cosa.

Señor Ventura escribió:¿Con cuanto DMA habría que contar cada vez que saltas de una tabla de atributos a otra para hacer referencia a nuevos tiles?, ¿2KB enteritos?

Como un registro son 2 bytes y la resolución vertical habitual de la SNES es 224px, harían falta unos 448 bytes para escribir un registro con HDMA.

Señor Ventura escribió:El DMA es el que supone aquí una brecha insalvable... pero últimamente estoy leyendo bastante de las capacidades del SA-1 para transferir tiles prácticamente sin restricciones (lo cual dejaría una puerta abierta para que el DMA gaste todo el tiempo que necesite en definir colores y nuevos grupos de tiles). ¿Esto es realmente así?

Seguramente haría falta un chip de apoyo mucho más potente que el SA-1 para mostrar fondos él solo.

EDIT

Por cierto, creo que no se pueden mostrar dos grupos de tiles en modo 7 en la SNES, ya que el registro que comenté no se puede escribir con HDMA.
Otra ventaja de la GBA

Señor Ventura escribió:No necesariamente. Para definir el color hay que tirar de cpu en ciertas circunstancias, pero eso no significa que necesites hacerlo de una forma tan intesiva de forma obligada.

Todo ese rollo del direct color en ciertos modos gráficos es algo que nunca me he molestado en mirar demasiado. Pensaba que era una virtud, pero parece mas una necesidad por lo que comenta GValiente... el caso es que si haces una interrupción cada vez que el line buffer pinta un pixel para definir el siguiente color directamente de la paleta madre, realmente podrías dibujar un plano en modo 7 a 32768 colores... pero si no he entendido mal, ¿necesitas que el DMA transfiera 5 bits por cada pixel que dibujas de este modo? (ya no solo necesitas mucha cpu para interrumpir tantas veces, sino que el DMA necesita transferir mucho, dejando aún menos tiempo para la cpu). En teoría, con un chip de apoyo puedes plantar planos en modo 7 a 32768 colores sin pestañear (al menos en una consola PAL)... y eso también mola.

Luego ya está lo del límite de 256 tiles para un plano en modo 7, pero realmente basta con que hagas una interrupción para definir otro grupo de 256 nuevos tiles cuando los primeros 256 tiles sean dibujados, para así disponer para ese plano de tantos tiles como quepan en la VRAM, y por lo que parece no debería ser demasiado costoso para la cpu, por lo que ese problema no parece otra cosa que un engorro para el programador, porque es una limitación que tiene solución.

Muchas gracias tio, iba a desertar del hilo porque hablais a un nivel que no puedo seguir, en el sentido de que no puedes enfrentarte a una ecuación de segundo grado si antes no aprendes a multiplicar y dividir. Estuve buscando una guía de programación de Snes ''for really greatest dummies'', pero de momento no doy con ella, aunque sí vi alguna interesantilla para tratar de iniciarme.


https://en.wikibooks.org/wiki/Super_NES_Programming
https://www.chibiakumas.com/6502/snes.php
https://georgjz.github.io/snesaa01/
https://medium.com/code-university/i-do ... 2e119e4f91


En realidad me interesa aprender más sobre la Master, pero Snes es a su vez mi debilidad. Si lo deseáis y os es posible, podriamos dedicar este hilo a comentar cosillas y organizarlo poco a poco a modo de documentación en Castellano, si bien lo ideal es abrir uno nuevo. Muchas gracias a ambos por toda la info que aportais, - @Señor_Ventura y @GValiente-.

GValiente escribió:Como un registro son 2 bytes y la resolución vertical habitual de la SNES es 224px, harían falta unos 448 bytes para escribir un registro con HDMA.

Pero esta tabla de atributos no lo haría, ¿no?. Lo que haces con hdma es acceder a la tabla de transformación que guardas en la wram, pero la indexación de las tiles la transfieres usando DMA como siempre... ¿no se distinguen?.

Jamás he visto siquiera que aspecto tiene la tabla de transformación, ni las tablas de ningún plano.

Con todo, por cada línea el hdma puede transferir 2 Bytes, así que te siguen sobrando 2 Bytes que se pueden acumular para otros menesteres.

Lo que había pensado es almacenar 750 tiles en la VRAM para los escenarios, y cada un cierto número de scanlines (cuando el line buffer ya haya dibujado los correspondientes tiles, paras máquinas, y acto seguido actualizas mediante DMA la tabla de atributos de otros 256 tiles que ya tienes preinstalados en la VRAM, ya que el line buffer ha dibujado físicamente los primeros 256 tiles y por lo tanto deja de importar si los desligas de su tabla de atributos a partir de ahora para relacionarla con los 256 siguientes, y no haría falta esperar a que las nuevas tiles sean transmitidas porque ya están preinstaladas en memoria.

Ese proceso de actualización de esa tabla habría que realizarla solo 3 veces dentro de cada frame, y salvo que sea una tabla muy grande, tanto por DMA como por CPU no debería ser un problema... ¿no?...

GValiente escribió:Seguramente haría falta un chip de apoyo mucho más potente que el SA-1 para mostrar fondos él solo.

Si, interrumpir cada pixel son palabras mayores... aunque también sería innecesario. Tal vez cada 128 pixels del line buffer podrías seguir obteniendo un plano en modo 7 a 32.768 colores.

GValiente escribió:EDIT

Por cierto, creo que no se pueden mostrar dos grupos de tiles en modo 7 en la SNES, ya que el registro que comenté no se puede escribir con HDMA.
Otra ventaja de la GBA

Claro, no pueden ser dos simultáneos, por eso hay que parar varias veces para hacer un "swap" al vuelo... esto dando por hecho que sea posible, aunque en realidad la duda es con que rendimiento, no si es o no es posible (creo yo).

Unreal McCoy escribió:Muchas gracias tio, iba a desertar del hilo porque hablais a un nivel que no puedo seguir, en el sentido de que no puedes enfrentarte a una ecuación de segundo grado si antes no aprendes a multiplicar y dividir. Estuve buscando una guía de programación de Snes ''for really greatest dummies'', pero de momento no doy con ella, aunque sí vi alguna interesantilla para tratar de iniciarme.

Yo estoy igual que tu. Para cuatro nociones básicas que chapurreo no creo que se pueda considerar que estoy en algún nivel.

Señor Ventura escribió:

GValiente escribió:Como un registro son 2 bytes y la resolución vertical habitual de la SNES es 224px, harían falta unos 448 bytes para escribir un registro con HDMA.

Pero esta tabla de atributos no lo haría, ¿no?. Lo que haces con hdma es acceder a la tabla de transformación que guardas en la wram, pero la indexación de las tiles la transfieres usando DMA como siempre... ¿no se distinguen?.

Jamás he visto siquiera que aspecto tiene la tabla de transformación, ni las tablas de ningún plano.

Con todo, por cada línea el hdma puede transferir 2 Bytes, así que te siguen sobrando 2 Bytes que se pueden acumular para otros menesteres.

Lo que había pensado es almacenar 750 tiles en la VRAM para los escenarios, y cada un cierto número de scanlines (cuando el line buffer ya haya dibujado los correspondientes tiles, paras máquinas, y acto seguido actualizas mediante DMA la tabla de atributos de otros 256 tiles que ya tienes preinstalados en la VRAM, ya que el line buffer ha dibujado físicamente los primeros 256 tiles y por lo tanto deja de importar si los desligas de su tabla de atributos a partir de ahora para relacionarla con los 256 siguientes, y no haría falta esperar a que las nuevas tiles sean transmitidas porque ya están preinstaladas en memoria.

Ese proceso de actualización de esa tabla habría que realizarla solo 3 veces dentro de cada frame, y salvo que sea una tabla muy grande, tanto por DMA como por CPU no debería ser un problema... ¿no?...

Creo que estamos hablando de dos cosas distintas

Tú (creo que) propones escribir nuevos tiles en la VRAM mientras se pinta la pantalla.
Aunque hubiera CPU suficiente para copiar los tiles suficientes a la VRAM en cada refresco de pantalla (que lo dudo mucho), creo que la SNES no permite actualizar la VRAM mientras se está refrescando la pantalla.
Y si eso también fuera posible (que también lo dudo), sincronizar la copia de tiles con el refresco de la pantalla sería muy difícil por no decir imposible.

Lo que yo proponía es almacenar los dos grupos de tiles en la VRAM y actualizar el registro que indica dónde se ubican los tiles a mostrar en cada línea horizontal de la pantalla con HDMA.
Eso en la GBA se puede hacer sin problemas, pero creo que la SNES tampoco lo permite.

GValiente escribió:Tú (creo que) propones escribir nuevos tiles en la VRAM mientras se pinta la pantalla.
Aunque hubiera CPU suficiente para copiar los tiles suficientes a la VRAM en cada refresco de pantalla (que lo dudo mucho), creo que la SNES no permite actualizar la VRAM mientras se está refrescando la pantalla.

La cuestión es que no sería necesario actualizar la VRAM porque esos 750 tiles ya estarían instalados en esa memoria de antemano.

Si es cierto que si intentas cambiar el estado de la memoria durante la pantalla activa se te puede llenar de basura por culpa de que se te corrompen los gráficos, pero también he leído que eso sucede si no se hace de forma controlada, ya que hay que tener en cuenta donde se encuentra el haz de electrones durante cada proceso de dibujado del scanline... esto dicho así de forma no muy exacta.

Vamos, que según parece si es posible, pero solo si lo planificas bien.

GValiente escribió:Y si eso también fuera posible (que también lo dudo), sincronizar la copia de tiles con el refresco de la pantalla sería muy difícil por no decir imposible.

Lo que planteo es tener 768 tiles en VRAM, y cada cierto número de scanlines hacer una interrupción para definir una tabla con otros 256 nuevos tiles para poder seguir dibujando con ellos en las siguientes líneas.

¿Podemos saber cuantos tiles diferentes están empleando actualmente los planos del art of fighting 1 y 2 de snes?, el único debugger que tengo no sirve para eso.

GValiente escribió:Lo que yo proponía es almacenar los dos grupos de tiles en la VRAM y actualizar el registro que indica dónde se ubican los tiles a mostrar en cada línea horizontal de la pantalla con HDMA.
Eso en la GBA se puede hacer sin problemas, pero creo que la SNES tampoco lo permite.

El problema de usar el hdma para realizar esa tarea es que ya estás usando el hdma en cada línea para acceder a la tabla de transformación del modo 7.

Mas bien lo que propongo es parar todo, y usar el DMA para actualizar el mencionado registro que relaciona los tiles que van a conformar el plano. No costaría mucho tiempo hacer eso, de hecho puedes hacerlo para modificar la cram y la OAM (que también se encuentran en la VRAM), así que en un principio lo lógico es pensar que con este registro no debería ser diferente.

Ahora creo que entiendo mejor lo que propones.

El tema es que en la SNES no se puede parar todo mientras se pinta la pantalla, si fuerzas la detención de la PPU se muestra todo negro. Como además la mayoría de registros no permiten se modificados mientras se pinta la pantalla, sólo te queda poder actualizar los pocos que permiten ser actualizados en H-Blank con interrupciones (lento) o HDMA (rápido).

El periodo de H-Blank es muy corto, no permite cambiar casi nada, con HDMA sólo permite cambiar en cada línea horizontal el valor de los registros del modo 7 y de unos pocos más, como hace el Treasure Conflix.

Señor Ventura escribió:Lo que planteo es tener 768 tiles en VRAM, y cada cierto número de scanlines hacer una interrupción para definir una tabla con otros 256 nuevos tiles para poder seguir dibujando con ellos en las siguientes líneas.

Los tiles a mostrar en pantalla se configuran con el registro que comenté que no se puede cambiar en H-Blank.

Señor Ventura escribió:¿Podemos saber cuantos tiles diferentes están empleando actualmente los planos del art of fighting 1 y 2 de snes?, el único debugger que tengo no sirve para eso.

Es muy difícil que un emulador te diga cuántos tiles se están usando en cada escena, como mucho te podría decir cuántos tiles se muestran en pantalla en cada fotograma, y que yo sepa no lo hace ninguno.

GValiente escribió:El problema de usar el hdma para realizar esa tarea es que ya estás usando el hdma en cada línea para acceder a la tabla de transformación del modo 7.

Como decía juegos como el Treasure Conflix (o el F-Zero sin ir más lejos) escriben los registros del modo 7 y algunos más con HDMA a la vez sin problema.

Señor Ventura escribió:Yo estoy igual que tu. Para cuatro nociones básicas que chapurreo no creo que se pueda considerar que estoy en algún nivel.

Te agradezco el comparativo, pero no cuela

Pienso que es muy interesante lo que debatís aunque me he quedado varios post más arriba. Sin ánimo de interumpiros, deseaba consultar una curiosidad sobre un pasaje de Final Fight 2 durante la tercera fase, que pienso puede ir de la mano de los dos Jacks tendidos en AOF 2.
Casi al principio de la pantalla hay una zona con seis minas agrupadas en dos filas de tres, al situarnos en el centro de ellas y llegar tres enemigos, el juego por sistema se ralentiza de forma notable, parece ser una ralentización programada o precalculada, en mi ignorancia.



Tengo dos teorías sobre el motivo, y una de ellas gracias a lo que habéis expuesto varias veces en distintos hilos.

- Las seis minas están realizadas de tal forma que cuentan como 'objetos completos' o bloques de sprites, y al ser Capcom proclive a desperdiciar tamaño de estos al dibujarlos*, para la Super se estarían dando hasta diez ''personajes'' en pantalla -once en una partida a dobles-.

- La ralentización está programada para evitar la posible colisión simultánea de varios enemigos a la vez en llamas, para que no se produzca un excesivo parpadeo.

*no recuerdo la terminología concreta que explicó Señor Ventura.

Es una duda que tengo desde hace años, pero siempre acaba olvidándoseme. Gracias por todo.

GValiente escribió:Ahora creo que entiendo mejor lo que propones.

El tema es que en la SNES no se puede parar todo mientras se pinta la pantalla, si fuerzas la detención de la PPU se muestra todo negro. Como además la mayoría de registros no permiten se modificados mientras se pinta la pantalla, sólo te queda poder actualizar los pocos que permiten ser actualizados en H-Blank con interrupciones (lento) o HDMA (rápido).

El periodo de H-Blank es muy corto, no permite cambiar casi nada, con HDMA sólo permite cambiar en cada línea horizontal el valor de los registros del modo 7 y de unos pocos más, como hace el Treasure Conflix.

En realidad se trata de parar el programa, no parar literalmente todo (es una de las desventajas de no dibujar mediante frame buffer). Imagino que en lo que la cpu deja de ejecutar el juego para actualizar los registros del plano del modo 7, el haz de electrones de la pantalla siga dibujando, y al no obtener ninguna "orden" del line buffer, pinte en "nulo".

La cuestión aquí es que el DMA tardará un tiempo en actualizar la tabla de atributos del plano, y en lo que eso sucede habrá un número calculable de pixels negros. No podrán ser muchos porque el DMA es bastante rápido, y el mencionado registro no puede ser tan grande (si son 8 bits por cada tile de los 256 referenciados, son 256 Bytes a transferir), por lo que es cuestión de iniciar las transferencias en un punto concreto del dibujado en el que dichas zonas "en negro" puedan disimularse como parte del dibujo del plano.

Es mas trabajo para el programador, pero bien planificado podría quedar bien. Solo restas un poquito de DMA, y un poquito de CPU.


De hecho se puede calcular cuantos píxeles negros llegaría a dibujar el line buffer mientras el DMA actualiza ese registro. Todo puede cuadrarse muy bien (siempre y cuando incorpores esas zonas en negro como parte del diseño del dibujo del plano).


Se mas o menos que aspecto tiene la OAM, pero no se que aspecto tiene la cram, la tabla de transformación del modo 7, ni los registros de las tiles de los planos en sus diferentes modos (de hecho creo que luego hay una tabla de carácteres, que tampoco controlo).


La OAM consta de dos registros, uno de 512 Bytes, y otro de 32 Bytes.
El primer registro define:
-Byte 0 para la coordenada X
-Byte 1 para la coordenada Y
-Byte 2 para el número de tile (que no se que hace)
-Byte 3 que se subdivide en 1 bit para "flipear" un sprite en su coordenada Y, 1 bit para "flipear" un sprite en su coordenada X, 2 bits para su prioridad, 4 bits para el número de paletas, y 1 bit para el número de tile (que tampoco se que hace)

El segundo registro define:
-1 bit para su tamaño (luego, solo hay dos tamaños posibles).
-1 bit para su coordenada X

Eso son 2 bits, así que en un Byte se "configuran" 4 sprites.

La coordenada Y tiene un valor de 8 bits, por lo que tiene un valor de 0 a 255. Esto implica que con el segundo registro puedes establecer su tamaño, su altura en 256 posiciones, y su posición horizontal haciendo referencia al bit "número de tile" del Byte 3.


Hay cosas que no las tengo tan claras... pero vamos, que como ya digo, del resto de tablas y registros del sistema, cero patatero.

GValiente escribió:Los tiles a mostrar en pantalla se configuran con el registro que comenté que no se puede cambiar en H-Blank.

Si, ya contaba con eso, por eso decía que no me pafrecía usable el hdma para esa tarea porque interpreto que la tabla de transformación del modo 7, y el registro de los tiles del plano en modo 7, son dos cosas diferentes.

Como ya digo, si no conozco que aspecto tienen no puedo saber si son la misma cosa, o no, pero como la tabla de transformación se almacena en la WRAM, por narices debo interpretar que los registros de los tiles tiene que ir en la VRAM, y por lo tanto tienen que ser dos cosas diferentes.

GValiente escribió:Como decía juegos como el Treasure Conflix (o el F-Zero sin ir más lejos) escriben los registros del modo 7 y algunos más con HDMA a la vez sin problema.

Claro, con hdma puedo modificar al vuelo los registros de la tabla almacenada en la WRAM, pero la que a mi me interesa en la que creo que debe estar almacenada en la VRAM... la de los tiles del plano, la que me podría permitir poder dibujar en un plano en modo 7 mas de 256 tiles si todo este invento pudiese salir bien...

Unreal McCoy escribió:Te agradezco el comparativo, pero no cuela

Pienso que es muy interesante lo que debatís aunque me he quedado varios post más arriba. Sin ánimo de interumpiros, deseaba consultar una curiosidad sobre un pasaje de Final Fight 2 durante la tercera fase, que pienso puede ir de la mano de los dos Jacks tendidos en AOF 2.
Casi al principio de la pantalla hay una zona con seis minas agrupadas en dos filas de tres, al situarnos en el centro de ellas y llegar tres enemigos, el juego por sistema se ralentiza de forma notable, parece ser una ralentización programada o precalculada, en mi ignorancia.



Tengo dos teorías sobre el motivo, y una de ellas gracias a lo que habéis expuesto varias veces en distintos hilos.

- Las seis minas están realizadas de tal forma que cuentan como 'objetos completos' o bloques de sprites, y al ser Capcom proclive a desperdiciar tamaño de estos al dibujarlos*, para la Super se estarían dando hasta diez ''personajes'' en pantalla -once en una partida a dobles-.

- La ralentización está programada para evitar la posible colisión simultánea de varios enemigos a la vez en llamas, para que no se produzca un excesivo parpadeo.

*no recuerdo la terminología concreta que explicó Señor Ventura.

Es una duda que tengo desde hace años, pero siempre acaba olvidándoseme. Gracias por todo.

He visto esa escena en youtube, y se ralentiza un pelín cuando una mina le explota a dos o mas enemigos simultáneamente. Es un problema de rendimiento, y es que no todos los juegos están optimizados igual (capcom era de las mas descuidadas en esto), pero la cuestión es que no hay flickering.

Luego una mina no podría contar como un objeto al mismo nivel que un enemigo al que se le aplica una rutina en su comportamiento mas compleja que "detectar una colisión sin hacer nada"... ¿y por qué se ralentiza entonces?, pues ni idea, podría deberse a que el cambio de estado de la misma no sucede una sola vez, sino tantas veces como enemigos la toquen, y la cpu ya vaya justa de procesamiento dentro de ese frame porque... pues porque capcom...

Lo que si hacían mucho es no usar bien los tiles para dibujar objetos, utilizando mas de los que son necesarios, cosa que impacta directamente en el número de tiles de sprites que pueden dibujarse por línea. en este sentido se puede ver claramente que no optimizaban nada.

Señor Ventura escribió:En realidad se trata de parar el programa, no parar literalmente todo (es una de las desventajas de no dibujar mediante frame buffer). Imagino que en lo que la cpu deja de ejecutar el juego para actualizar los registros del plano del modo 7, el haz de electrones de la pantalla siga dibujando, y al no obtener ninguna "orden" del line buffer, pinte en "nulo".

Imaginas mal, que no se puede parar nada

Señor Ventura escribió:Claro, con hdma puedo modificar al vuelo los registros de la tabla almacenada en la WRAM, pero la que a mi me interesa en la que creo que debe estar almacenada en la VRAM... la de los tiles del plano, la que me podría permitir poder dibujar en un plano en modo 7 mas de 256 tiles si todo este invento pudiese salir bien.

¿Qué tabla se almacena en VRAM? ¿Te refieres al tilemap? Esa tabla como dije sólo puede indexar hasta 256 tiles, y no indican qué tiles mostrar, sólo indican un offset al valor indicado por el dichoso registro que sólo se puede escribir en V-Blank. Por tanto, aunque se pudiera modificar esa tabla mientras se pinta la pantalla (que tampoco se puede), no serviría para nada.

GValiente escribió:Imaginas mal, que no se puede parar nada

Estoy intentando encontrarle una salida a esto, pero debo admitir que está complicado, y no consigo encontrar ninguna pista entre todas las toneladas de documentación que tengo apiladas.

Por otra parte, no parece haber nadie mas empeñado en conseguir poner mas de 256 tiles en un plano en modo 7, y desde luego que hay mucha gente que sabe muchísimo sobre este hardware, así que, igual es por algo y todo ...

Para colmo de males, tanto en AoF1 como en AoF2 no existe ningún margen de mejora:










Todavía me queda, calculo que entre un año y un año y medio para terminar mi actual proyecto antes de decidir volcarme en nada mas, pero esto es un jarro de agua fría, desde luego.

GValiente escribió:¿Qué tabla se almacena en VRAM? ¿Te refieres al tilemap? Esa tabla como dije sólo puede indexar hasta 256 tiles, y no indican qué tiles mostrar, sólo indican un offset al valor indicado por el dichoso registro que sólo se puede escribir en V-Blank. Por tanto, aunque se pudiera modificar esa tabla mientras se pinta la pantalla (que tampoco se puede), no serviría para nada.

Un buen punto de partida, cuando llegue el momento de ponerme a ello, es comprobar que resultado da hacer eso.

Sigo teniendo la impresión de que aquí hay algo que se escapa. Es de suponer entonces que si cambiar la indexación de las tiles hacia otras 256 tiles no va a conseguir que se empiecen a dibujar estas a partir del cambio, es porque lo que se tiene en cuenta es la posición en memoria de las 256 tiles originales...

Sin ver mas allá, me hace pensar que por ahí van los tiros... y en un principio cambiar el estado de la VRAM durante el H-blank (tanto por HDMA, como por DMA), lo que resulta son gráficos corruptos, así que parece ser un callejón sin salida.

Sin embargo, también hay formas de evitar cargarte los gráficos.


Hay que creer que es posible, que ya cuando pruebe todas las opciones ya habrá tiempo de convencerse de lo contrario

Señor Ventura escribió:Sigo teniendo la impresión de que aquí hay algo que se escapa. Es de suponer entonces que si cambiar la indexación de las tiles hacia otras 256 tiles no va a conseguir que se empiecen a dibujar estas a partir del cambio, es porque lo que se tiene en cuenta es la posición en memoria de las 256 tiles originales...

Para que quede claro: el tile a mostrar en cada celda del mapa viene dado por el valor de BG12NBA + el valor de la celda del tilemap.

Como el rango del valor de cada celda del tilemap en modo 7 va de 0 a 255, da igual los cambios que se pudieran hacer en el tilemap, nunca van a permitir mostrar más de 256 tiles a la vez en pantalla.

El que decide poder mostrar los primeros 256 tiles, los del medio o los últimos de la VRAM es el valor de BG12NBA.

Como no se puede escribir fuera de V-Blank, no hay mucho que se pueda hacer sin detener la PPU mostrando bandas negras o algo peor en pantalla.

Señor Ventura escribió:He visto esa escena en youtube, y se ralentiza un pelín cuando una mina le explota a dos o mas enemigos simultáneamente. Es un problema de rendimiento, y es que no todos los juegos están optimizados igual (capcom era de las mas descuidadas en esto), pero la cuestión es que no hay flickering.

Luego una mina no podría contar como un objeto al mismo nivel que un enemigo al que se le aplica una rutina en su comportamiento mas compleja que "detectar una colisión sin hacer nada"... ¿y por qué se ralentiza entonces?, pues ni idea, podría deberse a que el cambio de estado de la misma no sucede una sola vez, sino tantas veces como enemigos la toquen, y la cpu ya vaya justa de procesamiento dentro de ese frame porque... pues porque capcom...

Lo que si hacían mucho es no usar bien los tiles para dibujar objetos, utilizando mas de los que son necesarios, cosa que impacta directamente en el número de tiles de sprites que pueden dibujarse por línea. en este sentido se puede ver claramente que no optimizaban nada.

Gracias, es una respuesta interesante, y casi era la tercera opción que pensé aunque no sabia como darle forma a la hora de expresarme. Tal como te he comprendido sería como un cálculo de variables estilo gato de Schrödinger, es decir, que las minas funcionan bajo una especie de predicción de aleatoriedad en tiempo real, están vivas, son matemáticamente dinámicas, causando ese 'encendido' 'apagado' un fuerte impacto en la CPU. Sin tu explicación previa no lo hubiera comprendido igual. Disculpas de nuevo por la intromisión en el debate, que insisto, encuentro -y de facto es-, didáctico y ameno.

GValiente escribió:Para que quede claro: el tile a mostrar en cada celda del mapa viene dado por el valor de BG12NBA + el valor de la celda del tilemap.

Como el rango del valor de cada celda del tilemap en modo 7 va de 0 a 255, da igual los cambios que se pudieran hacer en el tilemap, nunca van a permitir mostrar más de 256 tiles a la vez en pantalla.

El que decide poder mostrar los primeros 256 tiles, los del medio o los últimos de la VRAM es el valor de BG12NBA.

Como no se puede escribir fuera de V-Blank, no hay mucho que se pueda hacer sin detener la PPU mostrando bandas negras o algo peor en pantalla.

La duda que me asalta es sobre el motivo por el cual el tilemap tiene un tamaño de 256x8 Bytes en modo 7, y en el resto de modos de 1024x16 Bytes ¿por cada plano?. Y sobre todo, ¿que configura cada bit en los registros de 8 y 16 Bytes?.


Sobre la incierta posibilidad de conseguir un plano de mas de 256 tiles en un plano en modo 7, si no observo mal el tilemap se declara antes de comenzar la pantalla activa de forma fija y no se vuelve a consultar, por lo que cambiarlo no sirve de nada ya que la forma en que empieza a construirse la imagen a partir de ese grupo de 256 tiles ya no depende de ese registro para todo lo que queda de frame.

Pero sin embargo sucede que durante todas las líneas siguientes de la pantalla el line buffer va a dibujar cada tile en su orden correcto... ¿sin consultar nada?... un line buffer, por definición, a cada nuevo scanline a dibujar debe recibir la orden de un patrón, o como mínimo consultar alguna referencia, ¿o es que tiene en cuenta el resto de las 223 líneas mientras que está dibujando solo una de ellas?.

En el supuesto de que esto fuese así, entonces el line buffer en lo que tiene que estar fijando por narices es en la posición de memoria de cada uno de los 256 tiles del tilemap.

Y aquí es donde espero para actuar. ¿Y si dibujo tiles durante los 32 primeros scanlines, y acto seguido cambio la posición en memoria de esos 256 tiles y los cambio por otros 256 tiles?. En ese momento es donde se produciría lo que dices tu de que el haz de electrones empezará a dibujar pixels "nulos", cosa que imagino que sucederá hasta que un tile vuelva a estar en su sitio en memoria, solo que no será el de antes, sino uno totalmente nuevo (256 tiles totalmente nuevos, que al estar ya en vram no tengo que esperar a que sean transferidos).


Al final me da igual si esto es conseguible mediante un cambio en las referencias del registro, o mediante un cambio de cada tile en memoria. Si esto es posible a cambio de un montón de pixeles negros, ya solo restaría que el artista dibuje un plano con secciones en negro que disimulen las partes en las que el haz de electrones está dibujando basura por haberle hecho la trece catorce.

La parte positiva es que se puede calcular cuantos piéxeles chungos te va a dibujar, porque puedes calcular cuanto vas a tardar en hacerlo todo.




No hace falta que pierdas mucho el tiempo en leerlo. En otro momento intentaré explicar de forma gráfica en que consisitiría el proceso (si es que funciona).




De postre, pongo una captura del hyperzone en el que la baldosa naranja es protagonista:
-En el tilemap está dibujada como una baldosa brillante (blanca) durante el frame capturado (indicado mediante un círculo rosa).
-Por lo tanto el patrón original no queda dibujado como baldosa naranja (indicando mediante un cículo rojo), sino como baldosa blanca (indicado mediante círculos verdes).
-En la pantalla de juego podemos observar que hay baldosas naranjas y blancas simultáneamente.

¿Que ha pasado? (yo tengo una teoría, que de hecho tiene que funcionar, pero me parece tan innecesario gastar esfuerzo en esto que no deja de alucinarme).

Unreal McCoy escribió:Gracias, es una respuesta interesante, y casi era la tercera opción que pensé aunque no sabia como darle forma a la hora de expresarme. Tal como te he comprendido sería como un cálculo de variables estilo gato de Schrödinger, es decir, que las minas funcionan bajo una especie de predicción de aleatoriedad en tiempo real, están vivas, son matemáticamente dinámicas, causando ese 'encendido' 'apagado' un fuerte impacto en la CPU. Sin tu explicación previa no lo hubiera comprendido igual. Disculpas de nuevo por la intromisión en el debate, que insisto, encuentro -y de facto es-, didáctico y ameno.

En realidad esto funciona de una forma mas simple.

Una caja de colisiones hace una comprobación a cada frame por si algo lo está tocando. Si lo que lo está tocando tiene programada alguna forma de respuesta, reaccionará según el programa lo tenga prefijado, y si no, lo atravesará como si fuese un fantasma.

Es decir, solo dos cajas de colisiones pueden colisionar y ocasionar algún tipo de respuesta (desaparece el sprite, se sustituye por otro con la animación de una explosión, y el personaje humano inicia las físicas de ser desplazado hacia atrás mientras sustituye su sprite por otro que dibuja unas llamas).

Unreal McCoy escribió:

Señor Ventura escribió:Yo estoy igual que tu. Para cuatro nociones básicas que chapurreo no creo que se pueda considerar que estoy en algún nivel.

Te agradezco el comparativo, pero no cuela

Pienso que es muy interesante lo que debatís aunque me he quedado varios post más arriba. Sin ánimo de interumpiros, deseaba consultar una curiosidad sobre un pasaje de Final Fight 2 durante la tercera fase, que pienso puede ir de la mano de los dos Jacks tendidos en AOF 2.
Casi al principio de la pantalla hay una zona con seis minas agrupadas en dos filas de tres, al situarnos en el centro de ellas y llegar tres enemigos, el juego por sistema se ralentiza de forma notable, parece ser una ralentización programada o precalculada, en mi ignorancia.



Tengo dos teorías sobre el motivo, y una de ellas gracias a lo que habéis expuesto varias veces en distintos hilos.

- Las seis minas están realizadas de tal forma que cuentan como 'objetos completos' o bloques de sprites, y al ser Capcom proclive a desperdiciar tamaño de estos al dibujarlos*, para la Super se estarían dando hasta diez ''personajes'' en pantalla -once en una partida a dobles-.

- La ralentización está programada para evitar la posible colisión simultánea de varios enemigos a la vez en llamas, para que no se produzca un excesivo parpadeo.

*no recuerdo la terminología concreta que explicó Señor Ventura.

Es una duda que tengo desde hace años, pero siempre acaba olvidándoseme. Gracias por todo.

Si las minas tienen bloque de colision, ahí tienes la respuesta.

Cada bloque de colisión hay que calcularlo constantemente, y eso es lo que provoca las ralentizaciones.

Diskover escribió:Si las minas tienen bloque de colision, ahí tienes la respuesta.

Cada bloque de colisión hay que calcularlo constantemente, y eso es lo que provoca las ralentizaciones.

Aparentemente con una comprobación cada frame es suficiente, y si fuese la comprobación lo que causase la ralentización en un principio imagino que las ralentizaciones serían mas insistentes, ¿no?. Solo lo he visto una vez, pero parece que se ralentiza solo cuando la mina explota, y cuando le explota a mas de un enemigo a la vez.

No quisiera imaginarme que todos los sprites de cada personaje estén buscando una colisión para reaccionar ante ella, porque es innecesario, pero solo tenemos que recordar el pifostio que liaron en konami con el gradius III, en el que literalmente tenías decenas y decenas y decenas de cajas de impacto para tareas que con solo un puñado podías hacer la misma tarea... normal que el juego se quedara tan pegado contínuamente (y aún así, parcheado a 3,58mhz tiene un rendimiento mas que decente, así que no me quiero ni imaginar que tendrán liada en el final fight 2 para que una mina y dos enemigos se carguen el rendimiento así ^^u).

Habría que ver si cuando quede una sola mina también sucede lo mismo, ya sería el colmo

Señor Ventura escribió:En realidad esto funciona de una forma mas simple.

Una caja de colisiones hace una comprobación a cada frame por si algo lo está tocando. Si lo que lo está tocando tiene programada alguna forma de respuesta, reaccionará según el programa lo tenga prefijado, y si no, lo atravesará como si fuese un fantasma.
Es decir, solo dos cajas de colisiones pueden colisionar y ocasionar algún tipo de respuesta (desaparece el sprite, se sustituye por otro con la animación de una explosión, y el personaje humano inicia las físicas de ser desplazado hacia atrás mientras sustituye su sprite por otro que dibuja unas llamas).

Diskover escribió:Si las minas tienen bloque de colision, ahí tienes la respuesta.
Cada bloque de colisión hay que calcularlo constantemente, y eso es lo que provoca las ralentizaciones.

Muchísimas gracias Compañeros, ahora me queda más claro. En verdad, hace unos seis meses, un buen amigo bastante mas conocedor que yo, me hablaba sobre las cajas de impacto, merced de la partida a SOR4 que pocos días antes habíamos jugado en su casa, pero no me las planteé aplicadas a las minas, aún es un concepto muy nuevo para mí.

Señor Ventura escribió:Aparentemente con una comprobación cada frame es suficiente, y si fuese la comprobación lo que causase la ralentización en un principio imagino que las ralentizaciones serían mas insistentes, ¿no?. Solo lo he visto una vez, pero parece que se ralentiza solo cuando la mina explota, y cuando le explota a mas de un enemigo a la vez.

No, ahí se encuentra la chicha, si probáis a colocaros con rapidez en el centro de las seis minas, veréis que las ralentizaciones comienzan justo cuando van llegando los enemigos, alcanzando su punto álgido justo cuando ellos se encuentran a punto de tocarlas.. o bien no llegar a hacerlo, o sí pero no en un orden-tiempo establecido, lo que refuerza vuestra explicación de tener que hacer un cálculo o precalculo constante y en tiempo real, ya que puede pasar cualquier cosa en cada partida.

Señor Ventura escribió:Habría que ver si cuando quede una sola mina también sucede lo mismo, ya sería el colmo

Más adelante, en la misma fase de Holanda, en el camino se dan minas sueltas o en grupos de dos, y sí, se sigue ralentizando un poco

Sin embargo Rolent lanza hasta quince bombas a la vez y no existen tantas ralentizaciones, imagino que porque la posible colisión sólo afecta al jugador, en lugar de darse cuatro variables sólo se dá una. -nunca he jugado a dobles a ver si reviso alguna partida en YouTube-.

Señor Ventura escribió:No quisiera imaginarme que todos los sprites de cada personaje estén buscando una colisión para reaccionar ante ella, porque es innecesario, pero solo tenemos que recordar el pifostio que liaron en konami con el gradius III, en el que literalmente tenías decenas y decenas y decenas de cajas de impacto para tareas que con solo un puñado podías hacer la misma tarea... normal que el juego se quedara tan pegado contínuamente (y aún así, parcheado a 3,58mhz tiene un rendimiento mas que decente, así que no me quiero ni imaginar que tendrán liada en el final fight 2 para que una mina y dos enemigos se carguen el rendimiento así ^^u).

Konami seguramente optimiza mejor que Capcom, al menos siempre he visto a Konami más volcada y comprometida en la Super que la compañia de la Cápsula, que parecía ir un poco a desgana, o en cierto modo con esa inercia de 'ley del minimo esfuerzo'. En Final Fight 2 sin ir más lejos se nota esa flojedad en el apartado musical, que me parecen excelentes -salvo alguna un tanto pachanguera o eurovisiva-, mejores incluso que las del FF 3, sin embargo se cargan la tensión y la emoción cuando los jefes no tienen su propio tema, e incluso se tiran al precipicio poniéndole a Retu, el boss final, la música de la primera fase, algo para mí a todas luces absurdo que denota una falta de interés o, que no tuvieron tiempo de completar el juego dentro de un plazo predeterminado por Nintendo.

Supongo que el complejo cálculo aleatorio de colisiones, es el responsable que que la segunda parte de Parodius en Super no sea para dos jugadores a pesar de incorporar el SA1, y es que siendo una virguería, pasaba un poco lo que con otras conversiones, era un juego difícil de digerir para un sistema doméstico de 16 Bits cuando pretendes portarlo con todas sus consecuencias.

La pregunta de las minas, y tambien el haber comentado antes sobre aleatoriedad, se cimentaba sobre dos detalles de FF2 que me resultan curiosos, precisamente por ser aleatorios dentro de un género que no suele serlo en 16 Bits.

- Mary y Eliza, al ser derrotadas tienen distintas voces -hasta cinco- y estas suenan en muy distinto orden según cada partida, es de hecho el único personaje que tiene esta facultad, y diría en ignorancia que tambien es el único juego de toda la historia que plantea esto dentro de los 16-32 Bits.

- Los enemigos no se mueven, ni aparecen, ni se comportan del todo igual siempre, al menos en cuatro compases del juego pueden aparecer de distintas maneras, y de nuevo Eliza y Mary son las más aleatorias con sus acrobacias.

- En la versión de FF2 para Nintendo Super System, la disposicion de enemigos y ciertos detalles son muy diferentes a la versión normal, como si se hubiesen reprogramado rutinas, órdenes y preferencias, además los enemigos restan una cantidad de energía enorme en cada olpe, entiendo que para hacerlo más rentable, cuando en el juego casero los enemigos quitan siempre más o menos lo mismo aunque se modifique el nivel de dificultad.

Es un juego curioso, y ciertos comportamientos a nivel de I.A, -por denominarlo así -, no los había visto en ningún juego.. ni siquiera en SOR 4 por citar un Beat 'Em up reciente.

Sobre HyperZone y los planos en Modo 7 que estais debatiendo, quisiera leerlos con tiempo y mientras ir adquiriendo la base mínima necesaria para comprenderos, porque desgraciadamente en este momento es ininteligible para mí, pero de corazón os agradezco mucho este debate y lo planteado en el.

Señor Ventura escribió:Aparentemente con una comprobación cada frame es suficiente, y si fuese la comprobación lo que causase la ralentización en un principio imagino que las ralentizaciones serían mas insistentes, ¿no?. Solo lo he visto una vez, pero parece que se ralentiza solo cuando la mina explota, y cuando le explota a mas de un enemigo a la vez.

No he jugado al juego, pero por lo que me cuentas, las minas colisionan con el player y no con los enemigos, pero si explotan, hacen daño al player y a los enemigos, y entonces surge una ralentización ¿no?

Si eso es así, efectivamente, cuando explota esta comprobando al player y a todos los enemigos (resto de minas incluidas) y de ahi la ralentización.

Unreal McCoy escribió:Muchísimas gracias Compañeros, ahora me queda más claro. En verdad, hace unos seis meses, un buen amigo bastante mas conocedor que yo, me hablaba sobre las cajas de impacto, merced de la partida a SOR4 que pocos días antes habíamos jugado en su casa, pero no me las planteé aplicadas a las minas, aún es un concepto muy nuevo para mí.

Cual quier cosa del juego que tenga que interaccionar con el player o con cualquier otra cosa para disparar un efecto o consecuencia, necesita caja de colision, y las cajas de colision estan todo el rato calculando distancia entre objetivo y si esta tocando o no la caja.

Cuantas mas cajas, mas calculos. Cuantos más calculos, mas estres para la CPU, y si te pasas surgen las ralentizaciones.

En Twiter existe un usuario llamado Upsilandre que se dedica a mostrar cajas de colisiones en juegos de NES. Esta muy bien para darse cuenta de que va la cosa.

Diskover escribió:En Twiter existe un usuario llamado Upsilandre que se dedica a mostrar cajas de colisiones en juegos de NES. Esta muy bien para darse cuenta de que va la cosa.

Le estoy echando un ojo y parece interesante.