[SUPER NINTENDO] Hilo oficial.

ayer 18:07

Enlace permanente

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.

ayer 18:09

Enlace permanente

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

ayer 18:11

Enlace permanente

@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...

* ayer 18:17

Enlace permanente

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.

ayer 18:59

Enlace permanente

@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

Al final te va a reportar como ha hecho conmigo.

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

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.

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

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.

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.

ayer 19:45

Enlace permanente

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.

* ayer 19:56

Enlace permanente

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.

* hoy 01:25

Enlace permanente

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.

* hoy 06:36

Enlace permanente

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.

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

hoy 09:56

Enlace permanente

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.

* hoy 11:39

Enlace permanente

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.

hoy 11:55

Enlace permanente

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.