[SUPER NINTENDO] Hilo oficial.

SuperPadLand escribió:Que me corrija Cirote si me equivoco, pero incluso creo que el A Link to te Past en la intro muestra la triforce en "3D" y no es algo que renderice la PPU sino algo pre-calculado y almacenado en la ROM, pero claro es solo esa intro:

Creo que es generado en tiempo real: como los tres triángulos son iguales, se puede renderizar uno y reutilizar los tiles para los otros dos.

@cirote3 pues les quedó bastante guay y más para ser juego de primera o segunda hornada.

blade133bo escribió:@naxeras No te lo tomes como ataque, es una respuesta sesgada que se usa para denostar el uso de una característica de la consola.
Y que ya se a visto que no es que potencie en exceso a la snes. Pero se usa como arma arrojadiza.

Sigo sin saber de que me estás hablando en serio, si yo no he hablado de PSX para nada...

@cirote3

Al final te va a reportar como ha hecho conmigo.

@SuperPadLand

En las consolas de hoy en día si se usa mucho precalculado como el GI por ejemplo y ocupa un montón de espacio pero no importa tanto.

Si quieres PS2 pues casi todas las destrucciones que se suelen ver son precaulculadas por eso siempre los puentes y edificios se destruyen igual, y hoy en día también se hace.

Pero las consolas retro es donde me parecia raro porque cuando alguien me habla de precalcular pues sigo pensando en valores de color, tablas de coseno seno y cosas así no de los fotogramas de animación de un scaling o una rotación...

Señor Ventura escribió:no siempre suceden reaccionando de forma concreta a otras interacciones, sino de forma preestablecida pese a ser cálculos en tiempo real.

Los cálculos no preestablecidos no son los contemplados para precalcular.

No es cuestión de tamaño, sino de trabajo... y luego de tamaño. Hay cosas que se pueden hacer, no es un todo o nada, y puedes guardar mucho en el resto de los 12MB que la snes puede direccionar.

El juego también está lleno de efectos que son fáciles de precalcular, y por lo tanto es una buena solución para llenar el juego con una mayor variedad de ellos.

Para el resto, puedes uar las multiplicaciones del ppu1 a cambio de sacrificar precisión, e imagino que tamaño o alcance de la animación, por lo que sacrifias suavidad si una animación necesita ser demasiado larga... a menos que la hagas lenta (que no acción ralentizada).

Todo lo que dependa de variables no preestablecidas, mejor intentarlas calcular en tiempo real. Hay algunas que la propia snes si podría realizar con mayor o menor fortuna sin precalcular montones de probabilidades.

SuperPadLand escribió:@cirote3 pues les quedó bastante guay y más para ser juego de primera o segunda hornada.

Pues sí, creo que el renderer 3D no lo usan en el resto del juego, se sacaron la chorra solo para la intro

naxeras escribió:Al final te va a reportar como ha hecho conmigo.

Intento tener todo el cuidado del mundo, a ver si me libro esta vez

naxeras escribió:Pero las consolas retro es donde me parecia raro porque cuando alguien me habla de precalcular pues sigo pensando en valores de color, tablas de coseno seno y cosas así no de los fotogramas de animación de un scaling o una rotación...

Eso es, lo típico que se precalculaba en la época eran tablas de senos, de arcotangentes y de divisiones (eso es lo que hago yo en mi juego). Almacenar rotaciones y escalados sale MUY caro.

Señor Ventura escribió:Hay cosas que se pueden hacer, no es un todo o nada, y puedes guardar mucho en el resto de los 12MB que la snes puede direccionar.

Si le dices a Nintendo en el 95 que quieres hacer un juego de 12MB te mandan a la calle con despido disciplinario

Señor Ventura escribió:El juego también está lleno de efectos que son fáciles de precalcular, y por lo tanto es una buena solución para llenar el juego con una mayor variedad de ellos.

No porque enseguida te quedas sin ROM. Cada efecto cuenta y mucho, cuando precalculas lo que más pierdes es la variedad.

Señor Ventura escribió:Para el resto, puedes uar las multiplicaciones del ppu1 a cambio de sacrificar precisión

¿En qué ayudan esas multiplicaciones a los jefes y a las nubes que he enlazado antes? Te agarras a un clavo ardiendo, el juego se hizo por y para el Super FX2: de hecho por lo menos parte de la lógica del juego la maneja también el coprocesador.

12 megas en SNES ni en los sueños más húmedos. La 64 en su primera hornada tiró de 8 y 16 mayormente. Incluso en todo su ciclo vital los de 32 o más megas son excepciones.

SuperPadLand escribió:12 megas en SNES ni en los sueños más húmedos. La 64 en su primera hornada tiró de 8 y 16 mayormente. Incluso en todo su ciclo vital los de 32 o más megas son excepciones.

Además hay que tener en cuenta que las ROMs de la N64 eran más lentas, la latencia era mayor. Por eso lo habitual es copiar el código a la RAM antes de ejecutarlo, mientras que en la SNES (y en la GBA) lo habitual es ejecutarlo directamente desde la ROM.

Juego original. El enemigo parece tener solo tres tipos diferentes de animación:
https://youtu.be/zCLT5TchiPY?t=238

Demo probando uno de los cálculos en tiempo real solo con el 65816:
https://youtu.be/KoeJ3HwWEMg?t=4

Lo mismo, pero con el SA-1:
https://youtu.be/zm1gfPaNvbU?t=4



Esto dice el autor sobre sus pruebas:

The SA-1 variant was a request done for Soul. This non-SA-1 variant was done as a challenge to myself.

This was made by adapting the code for this boss from Yoshi's Island to Super Mario World, changing/adding anything that was different from how the 2 games handled things, and translating the SuperFX ASM to SNES ASM. Despite re-using most of the YI code for this, porting this to SMW was still very difficult.

The only reason this needed the SuperFX at all was both because rendering this beast takes a lot of CPU time and that it uses 16x16 bit multiplication (the SNES can only do 16x8 on its own). This is why the SA-1 was suitable for this. You might think YI was plotting pixels with the SuperFX to pull this and similar effects off, but it was actually using HDMA to plot scanlines of a triangle tilemap on screen.

I only ported the layer 2 version of this boss. The layer 3 variant that spawns from a box wasn't implemented.

The flicking course clear text is caused by a hardware quirk of the SNES. The HDMA for rendering Salvo messes with the layer 3 position writes during the status bar IRQ. The only way to avoid this would be to prevent Salvo from rendering in the status bar area or by disabling the IRQ.

I tried my best to optimize this as much as possible. And I still couldn't avoid slowdown. Maybe if I render Salvo at 30 FPS it would be enough?

Unlike the SA-1 version, this lacks horizontal distortions. That was mainly because that code absolutely needed 16x16 bit multiplication. Most of the other instances of 16x16 multiplications could be dealt with by sacrificing precision, but doing that for the horizontal distortions would have made this even slower than it already is.




edit:

Si no entiendo mal, parece omitir las multiplicaciones del ppu1, o las considera insuficientes. Lo suyo es que sea lo primero, porque mas insuficiente aún sería no usarlas, digo yo...

Las otras dos animaciones que no prueba implican una modificación horizontal del efecto, creo que solo por falta de precisión, aunque también por rendimiento.

En otras palabras, sin super fx tendríamos que irnos a un super mario world 2 a 30fps para probar suerte. Creo que por aquí está la salida para todos esos efectos que no son "fijos" como para que baste con precalcular.

Señor Ventura escribió:Si no entiendo mal, parece omitir las multiplicaciones del ppu1, o las considera insuficientes. Lo suyo es que sea lo primero, porque mas insuficiente aún sería no usarlas, digo yo...

Lo explica el autor en el texto que has enlazado: las multiplicaciones con la PPU son las de 16x8. Dice que el SuperFX es necesario por las multiplicaciones de 16x16, y que ha podido hacer el port al SA-1 sin pérdida de rendimiento gracias a que al SA-1 también le añadieron multiplicaciones de 16x16. Las multiplicaciones de la PPU implican pérdida de precisión en unos casos y de rendimiento en otros:

The only reason this needed the SuperFX at all was both because rendering this beast takes a lot of CPU time and that it uses 16x16 bit multiplication (the SNES can only do 16x8 on its own). This is why the SA-1 was suitable for this.

...

Unlike the SA-1 version, this lacks horizontal distortions. That was mainly because that code absolutely needed 16x16 bit multiplication. Most of the other instances of 16x16 multiplications could be dealt with by sacrificing precision, but doing that for the horizontal distortions would have made this even slower than it already is.

El port del jefe sin SA-1 no solo va a pedales, sino que también pierde efectos y precisión para que no vaya aún peor. La SNES sin coprocesadores no es suficiente, ni se acerca.

Señor Ventura escribió:sin super fx tendríamos que irnos a un super mario world 2 a 30fps para probar suerte. Creo que por aquí está la salida para todos esos efectos que no son "fijos" como para que baste con precalcular.

Un Super Mario 2D a 30FPS hace llorar al niño Jesús, no me jodas

Para que carajos queréis un Mario 2 sin fx ?
No vale el que está?
Gracias a ese chip pudimos y tenemos esa maravillla técnica,aunque yo me quedo con el uno ,es muy goloso visualmente.

titorino escribió:Para que carajos queréis un Mario 2 sin fx ?
No vale el que está?
Gracias a ese chip pudimos y tenemos esa maravillla técnica,aunque yo me quedo con el uno ,es muy goloso visualmente.

Básicamente por la cuestión de que puedes dibujar cosas muy complejas mediante hdma + plano definiendo cálculos predefinidos para hacer animaciones a 60fps sin que te cueste ancho de banda para transferir un solo tile (tiempo de DMA).

Luego ya está "proceduralizar" ciertas animaciones con interacciones complejas, pero ya es otro terreno. El asunto es que la forma ordianaria de animar objetos gigantes es mediante la transferencia masiva de tiles, lo cual deja seca la cpu... o hacerlo mediante el método que emplea super mario world 2, y mantienes la cpu libre todo el tiempo.

Señor Ventura escribió:hacerlo mediante el método que emplea super mario world 2, y mantienes la cpu libre todo el tiempo.

Usar HDMA (el método que usa el SMW2) bloquea la CPU, no la deja el libre todo el tiempo. Una de las optimizaciones con las que perdí más tiempo en mi juego fue reducir la cantidad de datos a transmitir con HDMA para bloquear la CPU lo menos posible.

Estaba buscando información sobre el KoF de la super y en Reddit y me ha aparecido esto en referencia.

Parece que es un castillo de naipes que se sostiene justo justo.

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

El título impacta:
"¿Es realmente posible una versión fiel de KOF para SNES? Un análisis técnico profundo del cuello de botella de VBlank entre PAL y NTSC."

parece que nadie ha contestado aún y eso suele ser bastante raro cuando ahí si encuentran un fallo tienes a 20 personas saltándote al cuello.

Lag_Sinatra escribió:Estaba buscando información sobre el KoF de la super y en Reddit y me ha aparecido esto en referencia.

Parece que es un castillo de naipes que se sostiene justo justo.

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

El título impacta:
"¿Es realmente posible una versión fiel de KOF para SNES? Un análisis técnico profundo del cuello de botella de VBlank entre PAL y NTSC."

parece que nadie ha contestado aún y eso suele ser bastante raro cuando ahí si encuentran un fallo tienes a 20 personas saltándote al cuello.

y que gana ese muchacho intentando mentir? no gana absoiutamente nada a cambio ,lo mismo no contesta porque para que?

aparte que veremos en que queda eso porque sacar un kof tu solo tiene que ser una odisea .
ya hay un comentario y opino excactamente igual en lo que dice de primeras .
la demo se ve algo solido ,dejemos que el chaval siga con su trabajo ,esta claro que no lo va a terminar,
¿quie podria salir algo decente ? ni lo dudo ,mira lo que saco takara con el garou special con tan poquisimos megas .
esoi que pones es una de las versiones y oipniones de cuando sacan algo,una veces negativas ,pesimistas ,incluso realistas( porque sacar un juego con la calidad de neogeo lo veo muy coimplicado)
y otras veces hay optimismo y un poco de romanticismo vale ,,viendo los resultados me quedo con la opinion favorable.
ya se vera ,dejemos que el rio siga su cauce y ya veremos .

titorino escribió:

Lag_Sinatra escribió:Estaba buscando información sobre el KoF de la super y en Reddit y me ha aparecido esto en referencia.

Parece que es un castillo de naipes que se sostiene justo justo.

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

El título impacta:
"¿Es realmente posible una versión fiel de KOF para SNES? Un análisis técnico profundo del cuello de botella de VBlank entre PAL y NTSC."

parece que nadie ha contestado aún y eso suele ser bastante raro cuando ahí si encuentran un fallo tienes a 20 personas saltándote al cuello.

y que gana ese muchacho intentando mentir? no gana absoiutamente nada a cambio ,lo mismo no contesta porque para que?

aparte que veremos en que queda eso porque sacar un kof tu solo tiene que ser una odisea .
ya hay un comentario y opino excactamente igual en lo que dice de primeras .
la demo se ve algo solido ,dejemos que el chaval siga con su trabajo ,esta claro que no lo va a terminar,
¿quie podria salir algo decente ? ni lo dudo ,mira lo que saco takara con el garou special con tan poquisimos megas .
esoi que pones es una de las versiones y oipniones de cuando sacan algo,una veces negativas ,pesimistas ,incluso realistas( porque sacar un juego con la calidad de neogeo lo veo muy coimplicado)
y otras veces hay optimismo y un poco de romanticismo vale ,,viendo los resultados me quedo con la opinion favorable.
ya se vera ,dejemos que el rio siga su cauce y ya veremos .

A ver el garou special es juegardo pero precisamente es un juego que muestra los puntos débiles del sistema que sin embargo no muestra esa demo...

Mi opinión es que la super ahi va al maximo y no da de si para IA, cajas de impacto ni animar los fondos, se puede ver en el debugger por eso la demo la ha hecho en PAL y no NTSC (hasta los primeros gifs los pies eran un fondo si os fijais) .

Pero aun con esas podria sacar algo parecido a lo que se ve en la demo, primero poniendo bandas gruesas como en el garou y segundo recortando tamaño de sprites porque si Kyo y demas los pones asi de tochos y ya estas al limite como se ve en el debugger pues no vas a poder poner enemigos mucho mas grandes que destaquen (no se si se me entiende).

Ojalá avance y veamos de lo que es capaz y no se de por vencido si tiene que recortar el ambicioso apartado grafico que ha mostrado ahí y oye ojalá me equivoque y me tape la boca.

Buen artículo para intentar convencernos de que es todo una ilusión xD





Tremendas barras negras, ahí están, pero entonces llega el otro mantra: Snes no puede mejorar.


Lo que rodea a snes siempre es cine. Siempre. Esperemos que no consiga terminar ese juego, por el bien de todos xD

Señor Ventura escribió:hacerlo mediante el método que emplea super mario world 2, y mantienes la cpu libre todo el tiempo.

Traducción: Como no empleas transferencias enormes de tiles porque todo lo haces durante el hdma, dejas el tiempo de v-blank sin ocupar tiempo de DMA y mantienes la cpu libre todo el tiempo.

El SFA2 en SNES tiene bandas negras como se ven en la propia foto (y bien gruesas por cierto) por lo que dan la razón al artículo que sin bandas lo esta dando todo en PAL.

En cuanto a magia negra, yo por mi encantado que el tio se curre el juego con esos sprites, sin bandas, con los fondos animados etc etc, pero el problema es el debugger, que eso esta en PAL y está dándolo todo, sin animar fondos, ni barras de vida, ni colisiones, ni efectos de impacto, ni proyectiles...

naxeras escribió:

titorino escribió:

Lag_Sinatra escribió:Estaba buscando información sobre el KoF de la super y en Reddit y me ha aparecido esto en referencia.

Parece que es un castillo de naipes que se sostiene justo justo.

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

El título impacta:
"¿Es realmente posible una versión fiel de KOF para SNES? Un análisis técnico profundo del cuello de botella de VBlank entre PAL y NTSC."

parece que nadie ha contestado aún y eso suele ser bastante raro cuando ahí si encuentran un fallo tienes a 20 personas saltándote al cuello.

y que gana ese muchacho intentando mentir? no gana absoiutamente nada a cambio ,lo mismo no contesta porque para que?

aparte que veremos en que queda eso porque sacar un kof tu solo tiene que ser una odisea .
ya hay un comentario y opino excactamente igual en lo que dice de primeras .
la demo se ve algo solido ,dejemos que el chaval siga con su trabajo ,esta claro que no lo va a terminar,
¿quie podria salir algo decente ? ni lo dudo ,mira lo que saco takara con el garou special con tan poquisimos megas .
esoi que pones es una de las versiones y oipniones de cuando sacan algo,una veces negativas ,pesimistas ,incluso realistas( porque sacar un juego con la calidad de neogeo lo veo muy coimplicado)
y otras veces hay optimismo y un poco de romanticismo vale ,,viendo los resultados me quedo con la opinion favorable.
ya se vera ,dejemos que el rio siga su cauce y ya veremos .

A ver el garou special es juegardo pero precisamente es un juego que muestra los puntos débiles del sistema que sin embargo no muestra esa demo...

.

depende como quireas verlo ,yo veo una buena conversion ,con muy buenos fondos y muy cercano al original en lo jugable contando las enormes diferencias en todo con neogeo .
deblidades ?pues claro que la snes las tiene como todas .
pero si nos centramos en las debilidades no vemos lo bueno.
un juego con sus respectivos recortes deberia der mas que posible ,a ver si ahora vamos a pedirle a snes que haga un juego de neogeo 1:1 que es lo que parece .

Ese artículo es falsario a mas no poder, omite lo esencial para que quien no esté al loro crea lo que desea creer. Es tremendo como sale una triste demo para snes procedente de neo geo, y surgen hasta artículos y recaditos en un plan que da muy mucho entre vergüenza ajena, y asco.

De entrada, la animación de kyo e iori en posición de "stand", ocupa la mayoría de las veces 49 sprites de 16x16, que es incluso un poquito menos del ancho de banda de la snes NTSC. Con lo cual, cabe perfectamente en una snes ntsc, y eso sin contar con que está usando mas sprites de los que necesita.

En otros cuadros de animación la cosa ya llega a 7KB, lo cual sobrepasa un 14% el ancho de banda.


Peeeeeero, no estamos hablando de actualizar los tiles a cada frame, sino cada 4 a 6 frames aproximadamente. Desde que el programa requiere un cambio de tiles para enseñar un nuevo cuadro de animación, hasta que sucede, se acumulan entre 25 y 37KB de ancho de banda. Vaya, parece que si que da.

¿Por qué la imagen muestra las líneas lilas llegando al tope?, porque el autor de la demo parece estar empeñado en transferir todo en un solo frame, y luego esperar hasta la siguiente orden de transferencia para el siguiente cuadro de animación. Por eso parpadea ese medidor.

¿Y por qué quiere usa una snes PAL?, pues imagino que precisamente por ese mismo motivo, porque quiere transferir todo durante el primer frame, y la snes PAL ofrece mas ancho de banda (14,22KB).



...lo cual nos lleva a la siguiente cuestión, ¿por qué se habla tanto de ir al límite si una snes pal tiene un ancho de banda sobradísimo para todo?, pues ahí ya me desconcierta todo el mundo. Un máximo de 7KB es menos que 14,22KB, aunque la respuesta correcta es "entre 56 y 85KB por cuadro de animación".



Bueno, sin tanto lío, que una snes ntsc puede hacer esto solo forzando la desactivación de muy pocos scanlines:




¿Como puñetas no va a poder con una demo con kyo e iori, y sobrarle tiempo para que la cpu calcule la jugabilidad?.

Señor Ventura escribió:En otros cuadros de animación la cosa ya llega a 7KB, lo cual sobrepasa un 14% el ancho de banda.

Peeeeeero, no estamos hablando de actualizar los tiles a cada frame, sino cada 4 a 6 frames aproximadamente. Desde que el programa requiere un cambio de tiles para enseñar un nuevo cuadro de animación, hasta que sucede, se acumulan entre 25 y 37KB de ancho de banda. Vaya, parece que si que da.

¿Cómo cojones vas a hacer un juego de lucha con 6 frames de lag cuando alguien recibe un impacto?

Los juegos de lucha de la SNES suelen almacenar en VRAM solo los tiles actuales de cada personaje, aparte de los flashes de los golpes y las bolas de fuego y tal. El SFA2 y el KI lo hacen así por ejemplo. Los tiles de cada personaje necesitan ser actualizados en un solo fotograma para no hacer un juego de lucha a 10FPS. Si un cuadro de animación de un personaje toma 7KB, no se puede usar en una SNES NTSC sin bandas negras.

cirote3 escribió:¿Cómo cojones vas a hacer un juego de lucha con 6 frames de lag cuando alguien recibe un impacto?

Si ya se lo he dicho cuando hablabamos de KI que no puedes esperar a animar, que en un juego de lucha el tiempo de reacción es sagrado lo que hace es no contestar y listo.

Por cierto la Demo esa de Earthquake dicho por el propio creador de la demo no hay cuadros de animación ni siquiera para animar el andar (no es casualidad que se deslizan), como se puede ver en la VRAM y por el debugger, y esto teniendo toda la CPU libre, imaginaos los efectos de los golpes, las cajas de impacto, la IA, la barra de vida o animar los fondos.

Esos Earthquake esta bien para prueba de stress pero no son luchadores funcionales y aun así tal y como está deberia comerse alguna linea para deshogar un poco y que no haya algun glitch que se ve.

titorino escribió:depende como quireas verlo ,yo veo una buena conversion ,con muy buenos fondos y muy cercano al original en lo jugable contando las enormes diferencias en todo con neogeo .
deblidades ?pues claro que la snes las tiene como todas .
pero si nos centramos en las debilidades no vemos lo bueno.
un juego con sus respectivos recortes deberia der mas que posible ,a ver si ahora vamos a pedirle a snes que haga un juego de neogeo 1:1 que es lo que parece .

Si hablas de FF Special me parece una pedazo de conversión y un juegazo de lucha en SNES, no creo que nadie lo discuta hoy día.

Ya lo he dicho en otro post, para mi SNES tiene los mejores juegos de lucha de la generación (evidentemente descarto Neo-Geo, no tiene cabida en esta discusión), y para mi algunos superan al Arcade en diversión como Power Instinct o Fighters History que seamos sinceros son a veces muy injustos en Arcade. Tengo que hacer un post en este hilo con los análisis de los juegos de lucha que me he viciado durante años en este sistema y sigo jugando hoy en día.

Yo lo que discuto es que esos juegos podrian haber salido sin bandas porque patata o porque se puede meter 6 frames de lag a un juego de lucha o porque de repente se pueden meter personajes gigantes en el sistema sin esfuerzo y tan tranquilos, menospreciando el excelente trabajo y empeño que se hizo en la época y que hoy se sigue haciendo.

Un Saludo.

Hola, tengo un par de super nintendos pal españa, los mandos inalambricos de 8 bitdo funcionarian? Que tal la calidad de los botones, hay input lag?

Gracias.

Sonic4_saturn escribió:Hola, tengo un par de super nintendos pal españa, los mandos inalambricos de 8 bitdo funcionarian? Que tal la calidad de los botones, hay input lag?

Gracias.

Yo son los que normalmente uso, totalmente recomendados y al ser 2,4 GHZ el input lag es practicamente imperceptible.

Un Saludo.

naxeras escribió:

cirote3 escribió:¿Cómo cojones vas a hacer un juego de lucha con 6 frames de lag cuando alguien recibe un impacto?

Si ya se lo he dicho cuando hablabamos de KI que no puedes esperar a animar, que en un juego de lucha el tiempo de reacción es sagrado lo que hace es no contestar y listo.

Por cierto la Demo esa de Earthquake dicho por el propio creador de la demo y por el debugger de SNES no hay cuadros de animación ni siquiera para animar el andar, como se puede ver en la VRAM, imaginaos para los golpes, los efectos de los golpes, las cajas de impacto, la barra de vida y animar los fondos.

Creo que tanto la demo del Earthquake como el Killer Instinct usan el único "truco" viable en una SNES: animar solo un personaje por frame (aunque se muevan los dos a la vez). Con eso evitas tener que transmitir los tiles de los dos personajes en un fotograma. Pero si los tiles de un personaje ocupan 7KB, aunque se use el "truco" no se puede mostrar en una SNES NTSC sin meter bandas negras.

cirote3 escribió:Creo que tanto la demo del Earthquake como el Killer Instinct usan el único "truco" viable en una SNES: animar solo un personaje por frame (aunque se muevan los dos a la vez). Con eso evitas tener que transmitir los tiles de los dos personajes en un fotograma. Pero si los tiles de un personaje ocupan 7KB, aunque se use el "truco" no se puede mostrar en una SNES NTSC sin meter bandas negras.

Así es, el truco ya está aplicado, es lo que lo hace posible y el lag visual de un frame pues oye es factible cuando la logica del juego puede ir en el frame que toca y se anima un frame después.

Pero es que en la demo de los earthquake ya va tan al maximo que no puedes ni animar los pies al andar (mira el vídeo de pyron de lo queda libre) mucho menos hacer golpes, efectos, ni puedes meter logica de juego ni nada, simplemente es un stress test para mover un personaje no funcional que ya está recortado del Arcade.

La demo de los earthquake está hecha en puro ensablador sacando el jugo de la consola por si alguien tiene dudas de la optimización.

A ver siendo justos hay vram libre suficiente para meter los efectos de los golpes y tal vez proyectiles, que se pueden precargar y solo usas el DMA para animar los personajes, pero en el caso de los earthquake sigue siendo imposible de animar los golpes y movimientos.

Yo mi impresión viendo el debugger en los earthquake si quieres personajes tochos y no quieres bandas negras, tienen que ser personajes menos ambiciosos y mas genericos en cuanto animaciones para precargar lo maximo posible, vamos que cambien pocos tiles de un cuadro de animación a otro y asi no saturar tanto, también es posible que esté siendo poco ambicioso con la parte de CPU que se consume con la logica del juego y haya que recortar aún más.

naxeras escribió:Yo mi impresión viendo el debugger en los earthquake si quieres personajes tochos y no quieres bandas negras, tienen que ser personajes menos ambiciosos y mas genericos en cuanto animaciones para precargar lo maximo posible, vamos que cambien pocos tiles de un cuadro de animación a otro y asi no saturar tanto, también es posible que esté siendo poco ambicioso con la parte de CPU que se consume con la logica del juego y haya que recortar aún más.

Reutilizar tiles de frame anterior solo es posible hasta que el personaje recibe un golpe. Cuando recibe el golpe, toca reemplazar todos tiles por los del fotograma de recibir daño que toquen. Por eso en la práctica no es posible, hay que cargar todos los tiles de una.

naxeras escribió:

Sonic4_saturn escribió:Hola, tengo un par de super nintendos pal españa, los mandos inalambricos de 8 bitdo funcionarian? Que tal la calidad de los botones, hay input lag?

Gracias.

Yo son los que normalmente uso, totalmente recomendados y al ser 2,4 GHZ el input lag es practicamente imperceptible.

Un Saludo.

He visto en aliexpress unos con la carcasa verde transparente por unos 26 euros, son originales los que venden alli?

Sonic4_saturn escribió:He visto en aliexpress unos con la carcasa verde transparente por unos 26 euros, son originales los que venden alli?

Si, yo mismo tengo uno negro transparente y va muy bien.

cirote3 escribió:Reutilizar tiles de frame anterior solo es posible hasta que el personaje recibe un golpe. Cuando recibe el golpe, toca reemplazar todos tiles por los del fotograma de recibir daño que toquen. Por eso en la práctica no es posible, hay que cargar todos los tiles de una.

Depende del arte y los tiles reutilizables por ejemplo los pies, pegas y solo hace algo ahi con la boca, nuse ser inventivo con los personajes no veo otra, sabemos que no puede ni animar 2 earthquakes andando... al final si no quieres bandas tienes que hacer los personajes pequeños como en Killer Instinct (el de verdad, no el humo del e3...)

Un Saludo.

Pues he seguido el hilo de reddit que comenté sobre lo del King of fighters. Hay muchas cosas que no entendía en cuanto a datos que se dan por aquí y lo que se dice ahí, pero (con perdón) ¡Coño! El OP ha puesto unas últimas imágenes con explicaciones y hasta yo me he enterado de que va el tema, o por lo menos la idea principal y ha explicado el por qué de las cosas y coincide con las imagenes que pone del emulador.

Hilo: https://www.reddit.com/r/snes/comments/ ... _possible/

Ahora sé que todo esto depende del tiempo límite (y al parecer corto) que hay para meter sprites en la memoria de vídeo, que hay que adaptarse a lo que la propia consola puede o no realizar y que con consolas PAL estas demostraciones son más fáciles de hacer por ese aumento de tiempo extra entre frames (corregidme @naxeras y/o @cirote3 si he captado bien la idea de lo que explican ahí con este último párrafo que acabo de escribir)

Luego la imagen, me deja mucho más claro cómo y cuando se realizan los cambios de posiciones de los luchadores, y parece, como explican, que todos los desarrolladores solían llegar a la misma conclusión:



Y añado los otros dos ejemplos que no son tan descriptivos de que ocurre lo mismo en World Heroes y en Killer Instinct:
https://imgur.com/YsxVlAh
https://imgur.com/N2kcJqr

Lo que empezó como polémica, veo que se ha convertido en una lectura que ayuda a entender el funcionamiento de esta consola.

Lag_Sinatra escribió:Ahora sé que todo esto depende del tiempo límite (y al parecer corto) que hay para meter sprites en la memoria de vídeo, que hay que adaptarse a lo que la propia consola puede o no realizar y que con consolas PAL estas demostraciones son más fáciles de hacer por ese aumento de tiempo extra entre frames

Así es, en las consolas PAL hay mucho más tiempo para escribir en la VRAM, por lo que por ejemplo es más fácil mostrar personajes grandes en los juegos de lucha. De hecho creo que hay juegos como el Worms y el Tintin que en su día no se vendieron en USA por no ser capaces de hacer el port de PAL a NTSC. Creo que lo mismo pasó con el Elite de la NES, por poner otro ejemplo.

Lag_Sinatra escribió:Lo que empezó como polémica, veo que se ha convertido en una lectura que ayuda a entender el funcionamiento de esta consola.

Las "polémicas" las crean los fanboys cuando a alguien le da por decir algo malo de su consola, aunque sea cierto.

DBSZ escribió:

Doble fondo en modo 7 ext con la niebla del arcade para maquillar la distancia entre montañas y la zona baja del puente, y tienes una escena muy parecida al arcade.

Contras:
-La niebla junto al puente hace zoom junto con el puente. Mas feo.

Pros:
-La parte superior del cielo usando modo 7 encaja perfecto dentro del límite de 256 tiles. Sobrado. El sol es un sprite con la prioridad cambiada.
-Montañas en cualquier modo que soporte 256 colores.
-Puente y niebla encajan dentro del límite de 256 tiles. Sobrado.

Mejoras:
-Tras el primer scanline de las montañas se emplea hdma para transferir decenas de nuevas tiles para darle al puente mas detalles y variedad que en el arcade.
-Obviamente usas el mismo truco con los sprites que en los art of fighting de snes para habilitar el escalado de los personajes.
-Emplear colores mas vivos para alinearse con el mismo tono que el arcade. Profundidad de color algo inferior, pero en el mismo rango.



Choca considerarlo porque no se era tan ambicioso con la snes, no porque la máquina no pueda hacerlo.

Señor Ventura escribió:

DBSZ escribió:

Doble fondo en modo 7 ext con la niebla del arcade para maquillar la distancia entre montañas y la zona baja del puente, y tienes una escena muy parecida al arcade.

Contras:
-La niebla junto al puente hace zoom junto con el puente. Mas feo.

Pros:
-La parte superior del cielo usando modo 7 encaja perfecto dentro del límite de 256 tiles. Sobrado. El sol es un sprite con la prioridad cambiada.

Las nubes no se pueden mostrar en modo 7 porque el marcador superior no se puede mostrar con sprites, ya que los luchadores se muestran debajo del marcador cuando saltan. Si muestras los luchadores y el marcador con sprites, llenas todo de parpadeos.

No paras de decir cosas que no son posibles. Rare hizo un port cojonudo del KI. Si tú no eres capaz de hacer un hola mundo, mucho menos vas a ser capaz de mejorar lo que hizo Rare. Por favor, para de decir chorradas.

-No hay máquina doméstica de 16 bits que actualice los tiles de dos personajes gigantes tamaño earthquake a la vez.
-La demo del KOF no contiene colisiones, ni animaciones a raíz de estas. Son cuadros de animación cada 4 a 6 frames, en ese supuesto lo que he dicho es correcto. No rebate ningún argumento usar mensajes para corregir lo que no se ha dicho por omisión.
-No hablar de los marcadores del killer instinct no invalida mi argumento.
-Killer instinct tiene mucho margen de mejora.

Hilo de super nintendo.

Se sigue hablando de los earthquake cuando no pueden ni andar, es que directamente es una prueba de estres no algo funcional.

Los juegos de lucha se actualizan un frame un luchador, otro frame el otro luchador, eso es en todas las maquinas y asi está hecho en la demo de earthquake actualizar cada 6 frames es inviable y produce input lag inadmisible en un juego de lucha, lo mismo hacerlo a 30fps, no hay que yo sepa ni un solo juego de lucha a 30fps en las 16bits ni ninguno que acutalice cada 6 frames.

Efectivamente hablar de efectos imposibles porque hay barras de vida que causen parpadeos demuestra lo equivocado que puede estar una persona que no tiene en cuenta todas las cosas.

Creo que el post de reddit esta todo explicado muy bien porque la demo del KOF está totalmente al límite en SNES, porque de hecho sólo funciona en PAL y en NTSC es imposible y solo reduciendo y adaptando el tamaño de los personajes y poniendo el cinemascope que tiene la practica totalidad de juegos de lucha del sistema y sólo KI no lo tiene a costa de personajes relaticamente mas pequeños.

En conclusión... ¿Se puede un KOF en SNES? tal y como se ve en esa demo no, pero adaptando los personajes y con bandas se puede hacer algo muy digno pero no inventemos cosas que el sistema no puede hacer.

@Señor Ventura el día que implementes la mitad de lo que has soltado en este hilo vas a petar la scene de la SNES

naxeras escribió:Los juegos de lucha se actualizan un frame un luchador, otro frame el otro luchador

No todos lo hacen porque mete bastante lag, en un juego de lucha cuanto antes se vea la animación asociada al botón que has pulsado mejor. Por ejemplo el SFA2 anima a los dos luchadores a la vez en el mismo frame, y creo que el SF2 y derivados hacen lo mismo.

naxeras escribió:En conclusión... ¿Se puede un KOF en SNES? tal y como se ve en esa demo no, pero adaptando los personajes y con bandas se puede hacer algo muy digno pero no inventemos cosas que el sistema no puede hacer.

Para la GBA salieron un par de KOF con tamaño de sprites ideal para la SNES:



GBA vs Neo Geo:

cirote3 escribió:@Señor Ventura el día que implementes la mitad de lo que has soltado en este hilo vas a petar la scene de la SNES

naxeras escribió:Los juegos de lucha se actualizan un frame un luchador, otro frame el otro luchador

No todos lo hacen porque mete bastante lag, en un juego de lucha cuanto antes se vea la animación asociada al botón que has pulsado mejor. Por ejemplo el SFA2 anima a los dos luchadores a la vez en el mismo frame, y creo que el SF2 y derivados hacen lo mismo.

naxeras escribió:En conclusión... ¿Se puede un KOF en SNES? tal y como se ve en esa demo no, pero adaptando los personajes y con bandas se puede hacer algo muy digno pero no inventemos cosas que el sistema no puede hacer.

Para la GBA salieron un par de KOF con tamaño de sprites ideal para la SNES:

GBA vs Neo Geo:

Pero la resolución de GBA es menor que la de SNES.

Señor Ventura escribió:-No hablar de los marcadores del killer instinct no invalida mi argumento.

Solución 1:
Los marcadores del arcade original son semitransparentes, por lo que en lugar de realizarlos con las transparencias nativas, puede dibujarse la mitad izquierda durante los frames impares, y la mitad derecha durante los frames pares. De esta forma liberas el límite de dibujado de sprites por scanline cuando los personajes salten hasta ese área, y mantienes toda la parte superior usando el modo 7 para las nubes con un fondo naranja.

https://youtu.be/VWClU1hk7iA?t=1381


El resto tal cual está explicado encaja sin problemas en las funciones de la máquina.

Modo 7 en la parte de arriba, modo 1 hasta el puente junto la niebla, que deberá ser opaca. Los postes del puente quedan dentro del área del modo 1 y deberán ser sprites que al igual que los personajes deberán hacer ese pseudo escalado. Después modo 7 hasta que termine de dibujarse el puente, y cuando la pantalla hace "zoom out" vuelve a interrumpirse el modo gráfico y vuelve al modo 1 continuando con el dibujo de las montañas.

Es laborioso, pero solo hay que hacerlo una vez.





Solución 2:
Las nubes del cielo son en modo 7 hasta que comienza el marcador, que puede plantearse como barras de vida sobre un fondo naranja, o como barras de vida sobre un fondo naranja y un plano con el gráfico de las nubes simulando avanzar verticalmente a partir de ahí.

Papitxulo escribió:

cirote3 escribió:

naxeras escribió:En conclusión... ¿Se puede un KOF en SNES? tal y como se ve en esa demo no, pero adaptando los personajes y con bandas se puede hacer algo muy digno pero no inventemos cosas que el sistema no puede hacer.

Para la GBA salieron un par de KOF con tamaño de sprites ideal para la SNES:

GBA vs Neo Geo:

Pero la resolución de GBA es menor que la de SNES.

La horizontal es muy parecida, 240px vs 256px de la SNES. El tamaño de los protas del KOF de la GBA es parecido al del SFA2 de la SNES, por ejemplo:

Señor Ventura escribió:

Señor Ventura escribió:-No hablar de los marcadores del killer instinct no invalida mi argumento.

Solución 1:
Los marcadores del arcade original son semitransparentes, por lo que en lugar de realizarlos con las transparencias nativas, puede dibujarse la mitad izquierda durante los frames impares, y la mitad derecha durante los frames pares.

• Aunque hagas eso puede que sigas teniendo parpadeos de sprites por culpa de sol.
• Además, tener elementos tan grandes parpadeando todo el rato cansa la vista, quedaría bastante feo.
• Encima te obliga a meter el marcador y el sol en la VRAM para sprites, quitando espacio para los flashes de impacto y las bolas de fuego y tal. Eso obligaría a tener que escribir algunos de esos elementos en VRAM en caliente, dejando aún menos tiempo para los personajes y obligando a hacerlos más pequeños o a meter bandas negras etc, etc.
• Y se me olvidaba que meter las nubes en modo 7 chuparía mucha más VRAM que las nubes que hizo Rare, por lo que las montañas y el puente y tal tendrían que perder detalle.

Terrible idea, me quedo con lo que hizo Rare.

Señor Ventura escribió:Modo 7 en la parte de arriba, modo 1 hasta el puente junto la niebla, que deberá ser opaca. Los postes del puente quedan dentro del área del modo 1 y deberán ser sprites que al igual que los personajes deberán hacer ese pseudo escalado. Después modo 7 hasta que termine de dibujarse el puente, y cuando la pantalla hace "zoom out" vuelve a interrumpirse el modo gráfico y vuelve al modo 1 continuando con el dibujo de las montañas

¿Detrás del puente sólo estaría el color blanco de la niebla, sin que se vean las montañas? Quedaría feo de cojones, me vuelvo a quedar con lo que hizo Rare

Señor Ventura escribió:Solución 2:
Las nubes del cielo son en modo 7 hasta que comienza el marcador, que puede plantearse como barras de vida sobre un fondo naranja, o como barras de vida sobre un fondo naranja y un plano con el gráfico de las nubes simulando avanzar verticalmente a partir de ahí.

Lo de tapar el fondo cuando salen las barras de vida lo suelen hacer los juegos de lucha de la PC Engine, y para mí queda bastante feo. Tener que hacer lo mismo por emperrarse en meter unas nubes en modo 7 me parece otra mala idea. Una vez más, me quedo con lo que hizo Rare

cirote3 escribió:

Papitxulo escribió:

cirote3 escribió:Para la GBA salieron un par de KOF con tamaño de sprites ideal para la SNES:

GBA vs Neo Geo:

Pero la resolución de GBA es menor que la de SNES.

La horizontal es muy parecida, 240px vs 256px de la SNES. El tamaño de los protas del KOF de la GBA es parecido al del SFA2 de la SNES, por ejemplo:

¿Los del Garou Densetsu Special, por ejemplo, no serían ligeramente más grandes?

Papitxulo escribió:

cirote3 escribió:

Papitxulo escribió:Pero la resolución de GBA es menor que la de SNES.

La horizontal es muy parecida, 240px vs 256px de la SNES. El tamaño de los protas del KOF de la GBA es parecido al del SFA2 de la SNES, por ejemplo:

¿Los del Garou Densetsu Special, por ejemplo, no serían ligeramente más grandes?

Creo que no:

joder tener los marcadores parpadeando todo el rato un trozo uno y luego el otro... menudo mareo y que desagradable la verdad, son las tipicas cosas que suenan bien pero luego en la practica...

A mi me parece que el KI es un gran port hecho por un estudio top en su época que hicieron un gran trabajo, que mania con desmerecer a los programadores de la época y más con teorias en vez de pruebas.

cirote3 escribió:No todos lo hacen porque mete bastante lag, en un juego de lucha cuanto antes se vea la animación asociada al botón que has pulsado mejor. Por ejemplo el SFA2 anima a los dos luchadores a la vez en el mismo frame, y creo que el SF2 y derivados hacen lo mismo.

Pues había leído que en todos los juegos era así que nunca se actualizaban los 2 muñecos a la vez porque consumia mucho, que hasta en Neo-Geo se hacía así y lo dí por válido la verdad (hay mucho bulo en este mundillo o malentendidos).

cirote3 escribió:

Papitxulo escribió:

cirote3 escribió:La horizontal es muy parecida, 240px vs 256px de la SNES. El tamaño de los protas del KOF de la GBA es parecido al del SFA2 de la SNES, por ejemplo:

¿Los del Garou Densetsu Special, por ejemplo, no serían ligeramente más grandes?

Creo que no:

Esto es un golpe de realidad para mucha gente que no se da cuenta la reducción de sprites que se está poniendo sobre la mesa, aunque es verdad que luego en el CRT al estirar la imagen a lo ancho se ven un poco más grandes y menos definidos los sprites.

También al poner bandas que enm FF Special son bastante gruesas visualmente al estar mas cerca los sprites de la barra de vida parecen más grandes de lo que son.

Yo creo que las espectativas en este sistema en cuanto a juegos VS no son realistas, sólo hay que mirar el catalogo de juegos versus, ver el tamaño de los luchadores, la necesidad de bandas muchas veces bien gruesas, faltando al respeto a estos maginificos ports diciendo que se pueden meter sprites tamaño arcade y encima sin aportar ni una sola prueba apoyandose en absolutamente nada mas que los desarrolladores de los mejores estudios del momento eran unos paquetes... no se yo...

Si que os digo que si me sacan un buen juego de peleas con tamaño de sprites tochos sin bandas y me dicen que sólo rula en PAL que tiene 120% más tiempo para animar sprites pues oye mi superfamicom lloraria un poco pero mi mister se podria contenta .

naxeras escribió:joder tener los marcadores parpadeando todo el rato un trozo uno y luego el otro... menudo mareo y que desagradable la verdad, son las tipicas cosas que suenan bien pero luego en la practica...

naxeras escribió:A mi me parece que el KI es un gran port hecho por un estudio top en su época que hicieron un gran trabajo, que mania con desmerecer a los programadores de la época y más con teorias en vez de pruebas.

Opino lo mismo, hicieron un port cojonudo. Lo malo es que a mí los KI no me gustan mucho. Ojalá les hubieran dejado a Rare hacer un port de alguno de lucha de Capcom o SNK

naxeras escribió:

cirote3 escribió:No todos lo hacen porque mete bastante lag, en un juego de lucha cuanto antes se vea la animación asociada al botón que has pulsado mejor. Por ejemplo el SFA2 anima a los dos luchadores a la vez en el mismo frame, y creo que el SF2 y derivados hacen lo mismo.

Pues había leído que en todos los juegos era así que nunca se actualizaban los 2 muñecos a la vez porque consumia mucho, que hasta en Neo-Geo se hacía así y lo dí por válido la verdad (hay mucho bulo en este mundillo o malentendidos).

En Neo Geo no cuesta casi nada animar los dos personajes a la vez. Dudo mucho que haya algún juego de lucha arcade que no lo haga.

El port del Killer Instinct, los Donkey Kong Country... Rare hizo magia con SNES. Y con N64 ídem de ídem.

El matrimonio Nintendo-Rare es una de las historias de amor más fascinantes que la humanidad ha conocido. Lástima que se rompiera de tanto usarlo.

Bimmy Lee escribió:El port del Killer Instinct, los Donkey Kong Country... Rare hizo magia con SNES. Y con N64 ídem de ídem.

El matrimonio Nintendo-Rare es una de las historias de amor más fascinantes que la humanidad ha conocido. Lástima que se rompiera de tanto usarlo.

Yo todavía no entiendo cómo Nintendo no la compró, tal vez directamente no hacía falta era mejor usar y tirar como hizo con otras compañias como Argonaut.

¿Nintendo ha comprado alguna vez un estudio occidental?

naxeras escribió:

Bimmy Lee escribió:El port del Killer Instinct, los Donkey Kong Country... Rare hizo magia con SNES. Y con N64 ídem de ídem.

El matrimonio Nintendo-Rare es una de las historias de amor más fascinantes que la humanidad ha conocido. Lástima que se rompiera de tanto usarlo.

Yo todavía no entiendo cómo Nintendo no la compró, tal vez directamente no hacía falta era mejor usar y tirar como hizo con otras compañias como Argonaut.

¿Nintendo ha comprado alguna vez un estudio occidental?

Algunos, Retro Studios y Next Level Games son los más famosos.

El port del killer instinct es muy mejorable.

Si, snes tiene muchísimo margen de mejora en muchísimos juegos comerciales. No es un caso único de imposibilidad de mejora.

Marcadores usando parpadeos alternos es una buena solución, y permite no impedir un buen efecto gráfico. Si pausas el juego no tiene por qué congelarse la imagen, los marcadores pueden seguir su rutina con el juego pausado.

Señor Ventura escribió:El port del killer instinct es muy mejorable.

Si, snes tiene muchísimo margen de mejora en muchísimos juegos comerciales. No es un caso único de imposibilidad de mejora.

Si por mejoras te refieres a meter parpadeos en los marcadores y 6 frames de lag, mejor que los juegos se queden como están

cirote3 escribió:Si por mejoras te refieres a meter parpadeos en los marcadores y 6 frames de lag, mejor que los juegos se queden como están

Es que vamos si no se usan parpadeos en los marcadores en ningun juego comercial es por algo, lo de los 6 frames de lag otra cosa que jamás se usó es para mear y no echar gota.

Yo creo que lo de animar un personaje y luego el otro si deberia ser aceptable, tengo que mirar que juegos lo hacen, a ver si saco un rato.