[SUPER NINTENDO] Hilo oficial.

Responder
1…66, 67, 68, 69, 70
Si realmente es una pena que el autor del KoF no esté avanzando en una des sus publicaciones en X dijo que todos sus proyectos estaban parados por que tenía mucho trabajo así que hay que esperar en cuanto al KI si va a 60FPS y tiene dos modo de velocidad para que el juego valla más rápido en la pantalla de VS aprietas los botones en la cruz presiona (adelanté LRYX) a la misma ves irá más rápido el juego y la más rápida es presiona en la cruz del mando (atrás LRYX) esta es más rápida aún yo este juego lo conozco muy bien
naxeras escribió:@cirote3 Si, al final el secreto de KI al parecer es que es un juego de 30fps y de ahí la ausencia de bandas que caracterizan tanto este genero en SNES

Lo que da la impresión tras tu análisis @M68K es que si parece es que al ser un juego de 30fps se podria haber achuchado un poco más y haber puesto los personajes mas grandes pero supongo que es dificil estar seguros.

Ojo que el Killer Instinct de la SNES va a 60FPS, no a 30.
Los personajes, el scroll del fondo, etc. se mueven a 60FPS. La única limitación es que los dos personajes no pueden cambiar de animación en el mismo frame, aunque sí puedan cambiar de posición. Si el juego funcionara a 30FPS se vería mucho peor, sería un poco infumable XD
cirote3 escribió:
naxeras escribió:@cirote3 Si, al final el secreto de KI al parecer es que es un juego de 30fps y de ahí la ausencia de bandas que caracterizan tanto este genero en SNES

Lo que da la impresión tras tu análisis @M68K es que si parece es que al ser un juego de 30fps se podria haber achuchado un poco más y haber puesto los personajes mas grandes pero supongo que es dificil estar seguros.



Ojo que el Killer Instinct de la SNES va a 60FPS, no a 30.
Los personajes, el scroll del fondo, etc. se mueven a 60FPS. La única limitación es que los dos personajes no pueden cambiar de animación en el mismo frame, aunque sí puedan cambiar de posición. Si el juego funcionara a 30FPS se vería mucho peor, sería un poco infumable XD


Es que en 2D como se puede hacer un hibrido pues ya uno no sabe cuando se considera ir a 30 fps o no, pero vamos queria decir lo del personaje, no se si muchos juegos de lucha hacen lo del KI o no.

Un Saludo.
@naxeras ¡Gracias! Si hay demasiado texto técnico o tecnicismos avisa e intentaré explicarlo de mejor manera, a veces escribiendo rápido la cabeza por su lado y tiro adelante sin saber si ha quedado más o menos claro.

Lo que comentas del KoF, más allá de si es PAL o NTSC, se ve una cosa importante con la muestra de desarrollo que apenas se nombra, esta es la última versión que mostró cuando añadió sonido de movimientos (no hablo de sonido de fondo si no de inputs que generan sonido como los "Hadouken).

https://x.com/faeldaniel/status/2048742 ... 10282?s=20

Muchas de las animaciones no tienen ese margen de "seguridad" durante VBlank que otros juegos tienen
Imagen
Imagina ahora tener que transferir tiles de la bola que suele llevar teniendo ocupado el VBlank como lo tiene y en cuanto a movimientos sólo hemos visto el "idle" (estado de reposo) cuando se desplaza o salta. Tampoco podemos ver el espacio que queda en cada banco para sprites sin la ROM pero dudo que haya demasiado si además como se ve, los tiles para sprites también se usan para parte de los marcadores y barras de turbo. Quizás más adelante opte por usar BG3 (el tercer plano del Mode 1) para el HUD como se suele hacer (¡¡y faltan las sombras!!).

Aunque incluso usando sprites más pequeños al que hemos visto arriba, cuando un personaje efectúa un sonido se corrompen los gráficos:
Imagen

Se puede observar que faltan muchos tiles de fondo y sus respectivas animaciones si las quiere añadir. En las colisiones que se dan las barras de vida están (de momento) de adorno por que no se mueven, lo mismo pasa con la barra de "power" y tampoco vemos en las colisiones cosas que faltan como el marcador animado de combos o los efectos de golpes que también añaden animación y están formados por sprites animados que hay que tener en cuenta.
Imagen

Después hay que mirar si los tiles que usa están o no comprimidos, ya que a pesar de que estas consolas de 16 bits son buenas descomprimiendo, liberarles de esa carga de tarea es una innegable ayuda.

Son cosas con las que tendrá que lidiar y que no podemos obviar. Quizás lo que chirría es que dejase de hacer actualizaciones en el momento que incluyó el sonido y venían los problemas... Pero estas cosas se hacen a base de puntos de motivación. A lo mejor lo deja unos meses, luego retoma, luego lo deja otro tiempo etc, es bastante común pero es importante que se hagan para animar la scene.

Eso me recuerda a que le achacan a Pyron y otros tantos que no terminan sus demos, pero si somos realistas, apenas un 30% de todos los trabajos que se ven en cualquier sistema siguen adelante, con lo que si hay muchas demos, significa que habrá más posibilidades que algunas salgan adelante que cuando apenas hay movimiento de nada.

@cirote3

acabo de ver lo que me has pasado XD
Imagen

A veces es sufrido el hilo, sí XD
@M68K

De nuevo una explicación magistral, muchas gracias y nada muy claro todo lo que explicas.

En cuanto lo de los problemas cuando suena, efectivamente, el autor en los comentarios del twitt comenta que necesita un frame entero para descomprimir los samples y de ahi el bug, al parecer es por el driver de sonido que está utilizamdo y que el autor del driver está intentando solucionar, tal vez esa sea la razón de la pausa o no...

Yo también creo que va muy muy justo de vblank no se si ya esta animando un personaje y luego el otro como hace KI, pero si no es así por ahí podría tirar también o meterle algo de bandas para ganar tiempo, veremos si lo termina...

Lo que está claro es que no esta tan sobrado como se ha comentado en este hilo...

Un Saludo.
Nueva herramienta de desarrollo para nes y snes https://x.com/new8bitheroes/status/2085 ... 32595?s=48


github proyecto "snes_quake"
Interesantes este hack de Mario
https://x.com/anonimzwx/status/2086849011844038699?s=12
Le están mejorando la calidad de video al Dragon’s Lair msu1 en snes
https://x.com/lint_/status/2050529917801058758?s=12
https://x.com/Lint_/status/204954276149 ... deo/1?s=48
Hola, alguien que tenga algún mando clónico de aliexpress me pueda confirmar si es compatible la carcasa con el original? tengo un original que se le rompió por completo la carcasa hace años y me gastaría restaurar si existe esa posibilidad.
Los juegos de neo geo tal cual son bastante apretados para cualquier 16 bits, el chaval se ha puesto un par de meses a trastear y ya sacamos conclusiones porque hay límites... pues claro, ¿y que esperábamos?.

No puedo hablar de otras máquinas en el hilo de snes, pero contratiempos hay siempre, y soluciones también. Centrarse en sprites de estos tamaños y animaciones implica dejar bastante de lado la animación de los escenarios en estos hardwares domésticos... aunque snes podría tirar de hdma para animar planos completamente libre de encorsetar el dma para ello.

Ya digo, la combinación ganadora para estos resultados son sprites de 32x32, y 8x8 para perfilar, en lugar de un porrón de sprites de 16x16 que encima desperdician tiles.

Un chang son unos 4600 Bytes por frame, y entre cuadro de animación y cuadro de animación pueden pasar unos 3 frames, luego, cada frame necesita transferir 1500 Bytes antes de tener listo el cuadro de animación completo, asi que cada frame el dma puede estar aniquilando la mitad del v-blank por defecto con dos changs.

Creo que el programador alterna los frames para cada uno, primero se centra en uno, y en el siguiente se centra en el otro. Me pregunto si no es mejor hacer transferencias predictivas.
Señor Ventura escribió:entre cuadro de animación y cuadro de animación pueden pasar unos 3 frames, luego, cada frame necesita transferir 1500 Bytes antes de tener listo el cuadro de animación completo

Supongo que como no lees los mensajes de los demás no leíste lo que ya se explicó en este hilo, pero bueno, volvemos a intentarlo XD

En cualquier juego de lucha el tiempo que pasa entre que por ejemplo pulsas el botón de andar y el personaje se pone a andar es mínimo, un frame o como mucho dos a veces, como pasa en el Killer Instinct. Lo mismo pasa con cualquier botón de ataque, si el personaje se agacha o salta, etc. Meter tres frames de lag en cualquiera de esas acciones es infumable, te cargas el juego.

Incluso si el juego llevara un personaje secreto no controlable por el jugador para esconder el lag con él y hacerlo gigante, no se podría actualizar cada tres frames porque en los juegos de lucha las animaciones son cancelables: en cualquier frame un personaje puede recibir un golpe y hay que mostrar en ese momento la pose de daño, no tres fotogramas después.

Incluso si todo lo anterior no importara o no fuera cierto, actualizar los personajes durante varios frames implica tener dos copias de cada personaje en VRAM, la que se muestra en pantalla y la que se está escribiendo. Como solo hay 16KB de VRAM para sprites, cada personaje tendría que tener menos de 4KB, ya que también hay que meter las bolas de fuego, los flashes de los impactos, etc. Si cada personaje tiene que tener menos de 4KB, actualizarlo durante varios frames sería estúpido, ya que con ese tamaño debería ser posible actualizarlo en un solo frame.

Si has llegado hasta aquí y no me crees porque crees que cuando respondo a tus mensajes te estoy vetando, te estoy faltando al respeto, estoy convirtiendo este hilo en un estercolero y estoy buscando bronca continuamente, te animo a que busques un juego de lucha que actualice animaciones cada tres frames y hables de él en este hilo, con pruebas y tal. Puede que tardes un poco en encontrarlo XD
cirote3 escribió:
Señor Ventura escribió:entre cuadro de animación y cuadro de animación pueden pasar unos 3 frames, luego, cada frame necesita transferir 1500 Bytes antes de tener listo el cuadro de animación completo

Supongo que como no lees los mensajes de los demás no leíste lo que ya se explicó en este hilo, pero bueno, volvemos a intentarlo XD

En cualquier juego de lucha el tiempo que pasa entre que por ejemplo pulsas el botón de andar y el personaje se pone a andar es mínimo, un frame o como mucho dos a veces, como pasa en el Killer Instinct. Lo mismo pasa con cualquier botón de ataque, si el personaje se agacha o salta, etc. Meter tres frames de lag en cualquiera de esas acciones es infumable, te cargas el juego.

Incluso si el juego llevara un personaje secreto no controlable por el jugador para esconder el lag con él y hacerlo gigante, no se podría actualizar cada tres frames porque en los juegos de lucha las animaciones son cancelables: en cualquier frame un personaje puede recibir un golpe y hay que mostrar en ese momento la pose de daño, no tres fotogramas después.

Incluso si todo lo anterior no importara o no fuera cierto, actualizar los personajes durante varios frames implica tener dos copias de cada personaje en VRAM, la que se muestra en pantalla y la que se está escribiendo. Como solo hay 16KB de VRAM para sprites, cada personaje tendría que tener menos de 4KB, ya que también hay que meter las bolas de fuego, los flashes de los impactos, etc. Si cada personaje tiene que tener menos de 4KB, actualizarlo durante varios frames sería estúpido, ya que con ese tamaño debería ser posible actualizarlo en un solo frame.

Si has llegado hasta aquí y no me crees porque crees que cuando respondo a tus mensajes te estoy vetando, te estoy faltando al respeto, estoy convirtiendo este hilo en un estercolero y estoy buscando bronca continuamente, te animo a que busques un juego de lucha que actualice animaciones cada tres frames y hables de él en este hilo, con pruebas y tal. Puede que tardes un poco en encontrarlo XD


No lo va a encontrar, si algo define un juego de lucha es que la respuesta del juego tiene que ser inmediata o practicamente inmediata, si no te estas cargando el juego directamente y se vuelve injugable.
Vamos incluso en otro tipo de juegos como los de carreas, un shump o un beatemup el tiempo de respuesta es importantisimo.

En cuanto a neogeo precisamente es dónde no esta apretado porque si mal no me equivoco no tiene que ir copiando los frames de animacion a ninguna memoria intermedia, lo lee directamente del cartucho lo que le permite animar y de hecho anima los luchadores gigantes cada frame sobrando ancho de banda para meter tropeciantas animaciones automaticas en los fondos a cascoporro que ni siquiera usan la CPU y que las otras consolas de 16bits no tienen, pero vamos no es que sea experto en el sistema aún asi es algo que siempre he leido y una de las muchas cosas que diferencia la NeoGeo de las otras 16bits.

¿En otro orden de cosas, como se anima un fondo por HDMA? entiendo que esta limitado porque serian como efectos sobre el plano existente.

Un Saludo.
naxeras escribió:En cuanto a neogeo precisamente es dónde no esta apretado porque si mal no me equivoco no tiene que ir copiando los frames de animacion a ninguna memoria intermedia, lo lee directamente del cartucho lo que le permite animar y de hecho anima los luchadores gigantes cada frame sobrando ancho de banda para meter tropeciantas animaciones automaticas en los fondos a cascoporro que ni siquiera usan la CPU y que las otras consolas de 16bits no tienen, pero vamos no es que sea experto en el sistema aún asi es algo que siempre he leido y una de las muchas cosas que diferencia la NeoGeo de las otras 16bits.

En la Neo Geo no hay que copiar los tiles a la VRAM pero hay que construir la lista de sprites a mostrar, por lo que animar los fondos no sale gratis del todo, algo de CPU sí que chupa. Lo digo porque en este hilo sobre todo se suele confundir lo "más barato" con lo "gratis", y gratis no hay casi nada en esta vida XD

naxeras escribió:¿En otro orden de cosas, como se anima un fondo por HDMA? entiendo que esta limitado porque serian como efectos sobre el plano existente.

Como la SNES no permite escribir en VRAM mientras se pinta la pantalla, una forma de aumentar el tiempo de escritura aparte de usar bandas negras es escribir en VRAM cuando se salta de una scanline a la siguiente. El problema que tiene la SNES con eso es que tampoco se puede tocar la VRAM en una scanline en la que haya sprites sin meter fallos gráficos, por lo que en la práctica no se puede usar en los juegos de lucha ya que cuando un personaje salta y el otro no, se cubre todas las scanlines de la pantalla con sprites. Además, hacer eso chupa un montón de CPU porque el HDMA no permite elegir las scanlines en las que se activa, habría que hacerlo con interrupciones normales y corrientes. Es otra idea feliz que nunca va a funcionar en la práctica XD

Aquí hablan del tema gente que pilota: https://forums.nesdev.org/viewtopic.php?t=19896
Dividir las transferencias de un cuadro de animación entre frames tiene una inconsistencia.

Pulsar el botón en algún punto para iniciar un movimiento a los dos o tres frames, después de uno o dos de precarga de una animacion anterior, como mínimo habría estado malgastando vblank durante algún frame.
@luffyelx yo lo intenté hace bastantes años y no te lo aconsejo, es tirar el dinero. Mejor buscar uno de Super Famicom baratuco.
Ventura suelta una de las suyas, el resto pasa a contestarle en lugar de ignorarle y ya tenemos de nuevo el bucle.

Qué pereza de hilo.


Tiene pinta de que necesitará esperar al SFX4 [carcajad]
El super fx3 es un super fx2 mejorado, fue muy mala idea atribuirse ellos mismos el derecho de que eso sea un super fx3.

Yo llamaría fx3 a todo lo que venga, total, ¿que mas da?.
SuperPadLand escribió:


Tiene pinta de que necesitará esperar al SFX4 [carcajad]


Yo no le veo sentido a esto, es como el Doom que hay de megadrive para el everdrive que va fino fino pero al final lo que hace la consola es un pass through que el chip le dibuja en la VRAM. Claro si nos ponemos quisquillos lo mismo pasa con el SFX original, la consola procesa el sonido y poco más y si encima usaramos MCU ademas del SFX pues ya ni eso. Luego puedes "enmascararlo" por ejemplo ejecutas el UI en un plano y ya está haciendo algo la consola en si, pero claro aqui toco hueso y da miedo comentarlo.

Es como el supergameboy, la consola no está moviendo el juego de gameboy lo hace el chip del cartucho. (Que basicamente es una GB). Por mucho que tengas un plano que dibuja un borde o incluso que el juego en concreto del SGB use en parte el chip de sonido de la SNES.

No se, tengo el corazon dividido con los chips de mejora sobre todo cuando son muy burros.

Un Saludo.
Bimmy Lee escribió:Ventura suelta una de las suyas, el resto pasa a contestarle en lugar de ignorarle y ya tenemos de nuevo el bucle.

Qué pereza de hilo.

Si se leyeran las respuestas anteriores no habría que repetirlas y nos ahorraríamos todos el día de la marmota XD


naxeras escribió:
SuperPadLand escribió:


Tiene pinta de que necesitará esperar al SFX4 [carcajad]


Yo no le veo sentido a esto, es como el Doom que hay de megadrive para el everdrive que va fino fino pero al final lo que hace la consola es un pass through que el chip le dibuja en la VRAM. Claro si nos ponemos quisquillos lo mismo pasa con el SFX original, la consola procesa el sonido y poco más y si encima usaramos MCU ademas del SFX pues ya ni eso. Luego puedes "enmascararlo" por ejemplo ejecutas el UI en un plano y ya está haciendo algo la consola en si, pero claro aqui toco hueso y da miedo comentarlo.

Es como el supergameboy, la consola no está moviendo el juego de gameboy lo hace el chip del cartucho. (Que basicamente es una GB). Por mucho que tengas un plano que dibuja un borde o incluso que el juego en concreto del SGB use en parte el chip de sonido de la SNES.

No se, tengo el corazon dividido con los chips de mejora sobre todo cuando son muy burros.

Un Saludo.

Para mí hay una línea muy clara entre los coprocesadores que salieron durante la vida comercial del sistema y los que salieron después: para mí los segundos no son retro y los juegos que se hacen para ellos tampoco, por lo que me interesan mucho menos que los que se limitan a usar el hardware de la época.
Yo todo lo de la época lo apruebo, lo que viene después depende de si usa o no el hardware, si es un mero streaming como el Doom de NES que calza una raspberry no lo considero retro ni un hito. Si sigue una filosofía que busca asemajarse a un "what if" en la época y veo que se lo curran en ese aspecto si me vale, por ejemplo el chip ese del Former Dawn que se basa en que pasaría si NES hubiese tenido un addon CD en el 93-94, pero buscan que las PPU hagan todo o casi todo.
@yuragalo si solo quiero la carcasa.
@luffyelx ni encaja bien ni hace buen juego del todo (y lo poco que lo hace queda muy holgado); no tiene la disposición exacta, por eso te lo digo. Ya lo intenté en el pasado por lo mismo, para usar la carcasa con las tripas originales, es tirar el dinero.

Al final acabé comprando hace un par de años un mando de Super Famicom baratuco en un lote y es lo mejor que pude hacer.
3473 respuestas
Responder
1…66, 67, 68, 69, 70
Volver a Consolas clásicas