[SUPER NINTENDO] Hilo oficial.

Yo las explicaciones y las pruebas con el Mesen de @M68K las vi en el móvil sin ningún problema, no entiendo cómo alguien puede usar eso de excusa.

Si no hay paciencia o ganas de leer bien los mensajes que escriben los demás en un hilo, creo que es de mala educación escribir en él, es una falta de respeto para el resto de los que participan. Además, leer lo que escriben los demás te evita hacer el ridículo como ha pasado en este hilo

Es muy simple: el que quiere entender entiende y el que quiere darse a entender se da a entender. Tanto disclaimer y tanta gaita, por favor xD

https://x.com/SokZaJelo/status/2083512804884050278

A ver que sale de ahí

Ese evento cada vez se pone más interesante otro juego que es bastante impresionante ver en movimiento en la snes es el Alisha’s adventure https://www.youtube.com/watch?v=7aiomIl4Zuo

7Force escribió:Es muy simple: el que quiere entender entiende y el que quiere darse a entender se da a entender. Tanto disclaimer y tanta gaita, por favor xD

https://x.com/SokZaJelo/status/2083512804884050278

A ver que sale de ahí

¿Dónde se pueden ver los candidatos?

SuperPadLand escribió:

7Force escribió:Es muy simple: el que quiere entender entiende y el que quiere darse a entender se da a entender. Tanto disclaimer y tanta gaita, por favor xD

https://x.com/SokZaJelo/status/2083512804884050278

A ver que sale de ahí

¿Dónde se pueden ver los candidatos?

La jam acaba de empezar, termina el 31 de octubre. Supongo que en noviembre saldrán los candidatos.

naxeras escribió:

bluedark escribió:@ipod5g O un hack de algún RPG para llevar FF VII a SNES con el estilo de las capturas (o la captura) que había por ahí del juego en dicha consola.
Los chinos hicieron uno para NES, ¿por qué no para la 16 bits?

Puedes poner alguna captura?

La única que se relaciona con el juego, al menos que yo sepa, es esta:

naxeras escribió:

EPSYLON EAGLE escribió:Que quede claro: un buen juego de yo contra el barrio no necesita necesariamente una oleada interminable de enemigos para resultar divertido. Uno de mis favoritos de todos los tiempos, está en la Super e muestra como mucho dos o tres enemigos en pantalla a la vez y, aun así, ofrece muchísima diversión.

Que juego es ese que tiene pintaca.

Y ya que estamos estoy dando ultimamente duro a los beatemup,

¿Hay algun listado de los que hay en SNES? desde luego hay un montón que no conozco.

Me cito. ¿Existe algún listado de beatemups en SNES? estoy dando ultimamente muy duro al género y me gustaria ir dandole.

Otra pregunta aparte, ¿el SuperFX 3 ya esta soportado en algun cartucho?, me gustaria comprar un cartucho nuevo ya que el mio se lo he regalado a un amigo y quiero uno ya que estamos que soporte este chip que parece que se le esta dando bastante soporte.

Un Saludo.

@naxeras Este canal tiene múltiples catálogos de varias consolas subdivididos por género.

Creo que muestran 10 segundos por juego y añaden nombre, localización y fecha. No añaden homebrew a las listas con lo que según el sistema te puedes perder alguna cosa.

@naxeras hasta donde sé solo el emulador Mesen CE soporta el SFX3.

yuragalo escribió:@naxeras hasta donde sé solo el emulador Mesen CE soporta el SFX3.

Entonces esperaré a comprar un cartucho que lo soporte.

M68K escribió:https://youtu.be/haCLpbYBasU?si=HzJT1wsASakvfyOY

Muchas gracias es justo lo que necesitaba.

Star Fox corriendo a 30 FPS aunque creo que no es compatible con el hardware original
https://www.reddit.com/r/emulation/comm ... _a_smooth/

bluedark escribió:La única que se relaciona con el juego, al menos que yo sepa, es esta:

Gráficamente parece una mezcla entre Final Fantasy VI y Chrono Trigger. Habría estado curioso, la verdad.

Hablan de que cancelaron el FFVII 2D porque al salir la gen poligonal se dieron cuenta que había que saltar a ello, pero la verdad no veo porque no lanzar el FFVII de SNES en 1996 y el que fue el FFVII de PS1 llamarlo FFVIII y lanzarlo en el 97 igual.

SuperPadLand escribió:Hablan de que cancelaron el FFVII 2D porque al salir la gen poligonal se dieron cuenta que había que saltar a ello, pero la verdad no veo porque no lanzar el FFVII de SNES en 1996 y el que fue el FFVII de PS1 llamarlo FFVIII y lanzarlo en el 97 igual.

Supongo que porque aún estaba muy verde cuando decidieron cancelarlo.

SuperPadLand escribió:Hablan de que cancelaron el FFVII 2D porque al salir la gen poligonal se dieron cuenta que había que saltar a ello, pero la verdad no veo porque no lanzar el FFVII de SNES en 1996 y el que fue el FFVII de PS1 llamarlo FFVIII y lanzarlo en el 97 igual.

La historia con el FF 7 es bastante compleja y muy interesante.
Buscándote la imagen encontré un documental en YouTube más o menos reciente bastante interesante, aunque ya se ha escrito y dicho mucho sobre el tema, pero a mí siempre me fascina todo lo relacionado con este juego y lo que supuso en su día.

https://m.youtube.com/watch?v=XEwPSBXpK3I

txefoedu escribió:He jugado un poco al Final Fight 2 con parche y sin parche en la Superstation (FPGA) y mi he animado a grabarlo con la capturadora USB cutre de AliExpress.
Si bien 3 enemigos es poco comparado con los grandes Arcades de Capcom a mí me ha parecido suficientemente bueno/divertido para SNES/SFC. Ahí ya en algún caso puntual pega parpadeo... Así que con 5 enemigos pues ocurre mucho más frecuentemente. Del minuto 2:30 al 3:10 se ve bonito. He metido un segundo jugador "dummy" para hacer más bulto (podía haber elegido otro Haggar que el hack lo permite).

El problema del final fight 2 es el uso tan exageradamente indiscriminado que hace de los sprites, algo que ya venía haciendo capcom con las CPS, y que con snes ni se planteaban cambiar esa forma de trabajar.

Una cantidad importante de sprites desperdician el 50% del espacio, y hasta se puede apreciar como usan sprites de 16x16 para pintar un único pixel. No ajustar el dibujo dentro de cada sprite malgasta el límite de pintado por scanline sin dibujar nada en el. Las consecuencias son una mayor propensión a los parpadeos. Por diseño, ese brazo izquierdo de haggar también putea bastante, todo sea dicho.

Si ajustas mejor el dibujo puede que no te alcance para poner algún personaje mas en pantalla de forma estable, pero desde luego que algo si reducirás el flickering.





Como esta demo del cadillacs & dinosaurs, que pinta exactamente los mismos sprites que el arcade, y que cuando coinciden todos en la misma horizontal se llega a apreciar un leve parpadeo... con solo 5 personajes, si, pero se puede mejorar la estabilidad solo observando como los sprites desaprovechan tanto espacio.

Snes escribió:Ese evento cada vez se pone más interesante otro juego que es bastante impresionante ver en movimiento en la snes es el Alisha’s adventure https://www.youtube.com/watch?v=7aiomIl4Zuo

Ya hace tiempo que es conocido este juego, veo que ya lo ha terminado. Se me hace muy nervioso, pero creo que la intención es demostrar como aguanta el rendimiento a esas tasas.

Mucho sprite en pantalla, y una cantidad decente de rotación de sprites, enemigos multi articulados... técnicamente no es poca cosa lo que se ve ahí.

Snes escribió:Star Fox corriendo a 30 FPS aunque creo que no es compatible con el hardware original
https://www.reddit.com/r/emulation/comm ... _a_smooth/

Parece ser que no se puede replicar en hardware real porque han overclockeado el super fx por software mas de lo que aguanta el chip físicamente, pero que si lo han hecho de forma que el DMA soporta las transferencias para mantener los 30fps incluso sin tirar de 2BPP, así que en realidad otro chip mas rápido que el super fx podría hacer el trabajo ofrenciendo el resultado en una snes real, tal vez por fpga.

Señor Ventura escribió:El problema del final fight 2 es el uso tan exageradamente indiscriminado que hace de los sprites, algo que ya venía haciendo capcom con las CPS, y que con snes ni se planteaban cambiar esa forma de trabajar.

Una cantidad importante de sprites desperdician el 50% del espacio, y hasta se puede apreciar como usan sprites de 16x16 para pintar un único pixel. No ajustar el dibujo dentro de cada sprite malgasta el límite de pintado por scanline sin dibujar nada en el. Las consecuencias son una mayor propensión a los parpadeos. Por diseño, ese brazo izquierdo de haggar también putea bastante, todo sea dicho.

Si ajustas mejor el dibujo puede que no te alcance para poner algún personaje mas en pantalla de forma estable, pero desde luego que algo si reducirás el flickering.

Ese problema del Final Fight 2 es por culpa de la SNES, no por culpa de Capcom. La SNES solo puede mostrar dos tamaños de sprites en pantalla a la vez, y Capcom decidió usar sprites de 16x16 y de 32x32 pixels para reducir el número de sprites en pantalla (menor uso de CPU, menor uso de ROM y menor riesgo a quedarte sin sprites). En la Mega Drive y en la GBA no estás limitado a usar solo dos tamaños de sprites en pantalla, por lo que esos desperdicios se podían haber evitado con sprites de 8x8 pixels. Con la SNES no es posible.

Llevo un par de días jugando al Turtles in Time, tanto al arcade original como a la versión de SNES. Y aunque ya es sabido por muchos, hay que decirlo más (porque no se dice lo suficiente): el pedazo de conversión que se marcó aquí Konami es para aplaudirle hasta con los huevos de lunes a domingo.

Qué barbaridad, qué abuso.

Hablando de cadillacs & dinosaurs, alguien se ha currado las melodías usando el spc700 de la snes. Me pregunto si será cierto, se parecen mucho...


SNES:
https://www.youtube.com/watch?v=Wha8toKChao
CPS1:
https://www.youtube.com/watch?v=PXwB8GRRLeI

SNES:
https://www.youtube.com/watch?v=7_Cq-xh6GKs
CPS1:
https://www.youtube.com/watch?v=kLFtZi0F6NU

SNES:
https://www.youtube.com/watch?v=ZVBu3vd2lL0
CPS1:
https://www.youtube.com/watch?v=W97iaDtzHpA

M68K escribió:Creo que en ninguno de los puntos en los que he mencionado nada he faltado al respeto.

Claro que si. No solo con insultos se falta al respeto, también puede expresarse mediante la desconsideración manifiesta a una opinión, o a quien la expresa. Tu sabes bien lo que has dicho, a partir de ahí solo queda hablar de persona a persona, si te parece bien, y si no, pues lo dejamos estar. Me gusta aprender de quienes verdaderamente saben.

Sobre el tmnt, mi opinión gira mayormente en torno a la afirmación de un concepto que no es correcto de base. Usar un mismo tipo de enemigo no habilita por si solo usar un solo patrón de gráficos, porque cada uno de ellos puede encontrarse en un frame de animación diferente, y necesitar cada uno su espacio adicional en vram como cuando se trata de enemigos diferentes, a pesar de que son el mismo enemigo. Esta era mi idea a expresar.

cirote3 escribió:Yo las explicaciones y las pruebas con el Mesen de @M68K las vi en el móvil sin ningún problema, no entiendo cómo alguien puede usar eso de excusa.

Si no hay paciencia o ganas de leer bien los mensajes que escriben los demás en un hilo, creo que es de mala educación escribir en él, es una falta de respeto para el resto de los que participan. Además, leer lo que escriben los demás te evita hacer el ridículo como ha pasado en este hilo

Tu las viste sin ningún problema, yo no, por motivos de fuerza mayor. Imponer tu rasero es una falacia de generalización apresurada, y calificarlo de excusa para justificar esta clase de comportamientos, no solo te definen a ti solito, sino que carece de razón. Mi opinión sobre ti es igualmente escasa, y no me dedico a calificarte para intentar calentar el ambiente por ello. Haz tu lo mismo.

Que tu creas que puedes vetarme participar con estas formas, no necesariamente significa que estés actuando bien. Faltar el respeto a los demás es convertir cualquier hilo en un estercolero manipulando el sentido de mis mensajes para buscar bronca continuamente, eso si que es faltarle el respeto al resto del foro, y no expresar opiniones vagas, o equivocadas, como dices tu.

cirote3 escribió:Ese problema del Final Fight 2 es por culpa de la SNES, no por culpa de Capcom. La SNES solo puede mostrar dos tamaños de sprites en pantalla a la vez, y Capcom decidió usar sprites de 16x16 y de 32x32 pixels para reducir el número de sprites en pantalla (menor uso de CPU, menor uso de ROM y menor riesgo a quedarte sin sprites). En la Mega Drive y en la GBA no estás limitado a usar solo dos tamaños de sprites en pantalla, por lo que esos desperdicios se podían haber evitado con sprites de 8x8 pixels. Con la SNES no es posible.

Por supuesto que es culpa de capcom, y no de la snes.

Se pueden aprovechar mejor los sprites en el final fight 2, o redibujar apurando para evitar salirse de esos márgenes para no necesitar tantos, y favorecer que exista algún parpadeo menos de vez en cuando. El resto de consolas sobran, no voy a aceptar batallitas ni discusiones de patio de colegio, así que déjalo aquí.

Está son algunas pruebas que el autor del Final Fight Arcade Stage 1 a estado mostrando https://x.com/valdirsalgueiro/status/20 ... 25619?s=12

Haya paz hermanos que somos pocos sneseros en este foro como para perder a alguien en el hilo, abracemonos y recemos porque nuestros meías, el SNESCD, baje pronto de los cielos y nos eleve a todos al paraíso.

SuperPadLand escribió:Haya paz hermanos que somos pocos sneseros en este foro como para perder a alguien en el hilo, abracemonos y recemos porque nuestros meías, el SNESCD, baje pronto de los cielos y nos eleve a todos al paraíso.

Hay paz entre todos menos uno. Si para que haya paz entre todos hay que darle la razón como a los locos para que no crea que le están faltando al respeto, apaga y vámonos

naxeras escribió:El concepto de la tabla OAM lo he leido muchas veces pero no lo entiendo muy bien, yo pensaba que en las consolas en general podias dibujar el mismo sprite de VRAM las veces que quieras siempre que no sobrepase el numero de sprites en linea o el total en pantalla pero ya veo que hay otra limitacion ahí ¿Aplica a todas las consolas?

La OAM de la SNES y la GBA contiene los atributos de los sprites a mostrar en pantalla, lo dice el nombre (object attribute memory). La limitación de dos tamaños de sprite en pantalla viene porque Nintendo se emperró en usar el menor número de bytes posible por sprite, unos 4 y pico. Con la GBA se dejaron de gilipolleces y pasaron a 6 bytes por sprite, permitiendo entre otras cosas que cada sprite tuviera el tamaño que le saliera de la polla

Cuando se habla de multiplexar sprites para aumentar el número de sprites en pantalla, lo que se hace es reescribir la OAM en medio de un scanline para que cuando se pinte el siguiente, los sprites sean nuevos. Hablo de la OAM de la GBA, la SNES no lo permite.

Dejo info de las dos OAM:
https://snes.nesdev.org/wiki/OAM_layout
https://gbadev.net/gbadoc/sprites.html

naxeras escribió:Y con esto me queda claro que NES también tiene OAM jajaja

Todas las consolas que muestran sprites tienen que almacenar sus atributos en algún sitio. Bueno, puede que cosas como la Atari 2600 no, pero tú me entiendes

En la Mega Drive por ejemplo a la OAM la llaman SAT (Sprite Attribute Table). No tiene memoria dedicada para atributos de sprites, si no que se almacena en VRAM (compartiendo espacio con tiles) y se usan 8 bytes por sprite creo. En la Neo Geo creo que a la lista de atributos de sprites la llaman directamente VRAM, etc. Cada fabricante suele usar su propia nomenclatura para esas cosas.

El que esté libre de pecado que tire el primer pad!

M68K escribió:Lo que sí es más vistoso es que los emuladores estos en SNES son más elegantes mostrándote la tabla OAM con los tiles de cada entrada de base mientras que en Exodus (emulador/debugger de MD) te pone una lista más sosa que el pan que comen los brasileños en una fabela:

Es una lástima que el core de Mega Drive para el Mesen se quedara a medias, porque es de largo el mejor emulador para verle las tripas a los juegos

Creo que sea el video que trata el tema con más profundidad.

Enormes ejemplos y enormes explicaciones.

Bravo, chavales, así da gusto entrar en los hilos

@cirote3 @M68K

Muchas gracias por el curro así da gusto ahora lo he entendido mucho mejor todo.

Por eso en NEO la VRAM es la tabla de atributos porque no se usa la VRAM para almacenar sprites se ven directamente del cartucho y ahora entiendo porque decian que sobra porque tiene más VRAM que sprites puede pintar la GPU de la NEO.

Entiendo que si la tabla se guarda en la VRAM se guardara en algun sitio especifico y ocupara maximo cierta cantidad en MD y SNES, vamos que imagino que siempre se usara a tope en los juegos, no habra diferencia en esto de la SAT a la OAM.

Y gracias ahora entiendo mejor lo de multiplexar, lo que no entiendo es por que SNES no puede escribir en la OAM para multiplexar, ¿En SNES la OAM se escribe sola y en MD tienes que gestionarla tu? no lo entiendo.

No se por que se tomaron ciertas decisiones en SNES con cambiar 4 cosas hubiera fundido aún más a MD en el plano técnico, imagino que simplemente Nintendo no lo necesitaba y no se equivocaron porque lo petó pero tambien me da pena en pensar ports de Arcade que ya tiene SNES hubieran sido mucho mas pefectos.

@EPSYLON EAGLE

Si, me he visto el video muchas veces pero al estar en brasileño y el traductor al menos a mi me va tan tan mal no me entero de tanto como me gustaría.

Un Saludo.

naxeras escribió:Entiendo que si la tabla se guarda en la VRAM se guardara en algun sitio especifico y ocupara maximo cierta cantidad en MD y SNES, vamos que imagino que siempre se usara a tope en los juegos, no habra diferencia en esto de la SAT a la OAM.

La SNES tiene memoria dedicada para la OAM pero la MD no, en la MD la SAT tiene que compartir memoria con los tiles y los tilemaps.

naxeras escribió:Y gracias ahora entiendo mejor lo de multiplexar, lo que no entiendo es por que SNES no puede escribir en la OAM para multiplexar, ¿En SNES la OAM se escribe sola y en MD tienes que gestionarla tu? no lo entiendo.

Aquí explica el autor del BSNES por qué no se puede multiplexar sprites en la SNES. Como en la MD se puede escribir en la VRAM mientras el VDP pinta la pantalla, parece que no hay problema en multiplexar sprites siempre y cuando no escribas en donde el VDP está leyendo en el momento de la escritura. Con la GBA pasa lo mismo con la OAM.

naxeras escribió:No se por que se tomaron ciertas decisiones en SNES con cambiar 4 cosas hubiera fundido aún más a MD en el plano técnico, imagino que simplemente Nintendo no lo necesitaba y no se equivocaron porque lo petó pero tambien me da pena en pensar ports de Arcade que ya tiene SNES hubieran sido mucho mas pefectos.

La verdad es que con el tema de los sprites la cagaron. Entiendo que copiar el setup de la GBA era demasiado caro, pero copiar el de la MD debería haber sido posible y habría sido mejor para mí: prefiero tener menos sprites pero de más tamaños y en caso de que me hagan falta más de 80, multiplexarlos.

naxeras escribió: @EPSYLON EAGLE

Si, me he visto el video muchas veces pero al estar en brasileño y el traductor al menos a mi me va tan tan mal no me entero de tanto como me gustaría.

Como yo tampoco me iba a comer un tocho de hora y media en portugués, lo he metido en una página de generar resúmenes y viene a contar lo que estamos hablando aquí más o menos

Ese video está muy bien se explica muchas cosas por otro lado, no creo que el Señor Ventura quiera dar información imprecisa yo lo e visto en foro especializado debatiendo, dando sus ideas como NesDev y aprendiendo ,ustedes tu vieron un debate hace tiempo ha cerca de Killer Instinct msu1 y él dijo algo al respecto de que la snes podía manejar los Sprite de Arcade en ese juego y puso foto si mal no recuerdo pero esa información el la sacó de el foro del parche msu1 y lo dijo el autor de parche y también dijo que la snes podía tener la mejor versión de SSF2T en consolas domesticas,toda esa información es del creador del parche gizaha yo por mi parte soy más práctico lo que hay es lo que es la snes es una muy buena consola y me encanta lo que puede dar de sí que tiene sus debilidades seguro pero eso no quita que se puedan ver cosas muy interesantes en el futuro ,yo con lo que ya existe más que servido.

Cirote3 escribió:Si no eres moderador, ¿quién eres tú para decirme lo que puedo escribir y lo que no? ¿Quién es el que está "imponiendo su rasero", "calificando los mensajes de los demás", "faltando al respeto" y "vetando participar"?

Ok, te respondo a propia petición tuya, luego no te quejes de la clase de respuesta que es.


¿Quien califica los mensajes de los demás?, tu lo hiciste. Una queja por tu actitud no es reproducir los motivos de mi queja... y parece mentira tener que explicar esto.
hilo_super-nintendo-hilo-oficial_1413431_s3400#p1756903119

En un mismo post eres capaz de decir que si no soy moderador no soy nadie para decir que cosas no se deben poner aunque sean ataques hacia mi, pero al mismo tiempo exigir cuando debo participar en el hilo, y en que condiciones de redacción debo hacerlo, porque si no es una falta de respeto.
hilo_super-nintendo-hilo-oficial_1413431_s3400#p1756912695


Lo dicho, o no os dais cuenta de lo que haceis, o teneis tan normalizado el doble rasero que ni lo veis. Espero que sirva para la reflexión, y se considere dejarme en paz. Día de la marmota.

Snes escribió:Ese video está muy bien se explica muchas cosas por otro lado, no creo que el Señor Ventura quiera dar información imprecisa yo lo e visto en foro especializado debatiendo, dando sus ideas como NesDev y aprendiendo ,ustedes tu vieron un debate hace tiempo ha cerca de Killer Instinct msu1 y él dijo algo al respecto de que la snes podía manejar los Sprite de Arcade en ese juego y puso foto si mal no recuerdo pero esa información el la sacó de el foro del parche msu1 y lo dijo el autor de parche y también dijo que la snes podía tener la mejor versión de SSF2T en consolas domesticas,toda esa información es del creador del parche gizaha yo por mi parte soy más práctico lo que hay es lo que es la snes es una muy buena consola y me encanta lo que puede dar de sí que tiene sus debilidades seguro pero eso no quita que se puedan ver cosas muy interesantes en el futuro ,yo con lo que ya existe más que servido.

Hola ventura, como estás xD

Lo que dije fue exactamente la información que puso el autor de aquel hack, de hecho indiqué que es justo la información que dio el mismo, pero no todos los programadores están mereciendo respeto dependiendo de para que plataforma trabajen.

No tengo motivos para poner en duda que este ripeo pertenece al killer instinct arcade sin analizarlo, porque no tengo por qué pensar que miente, y si lo ha hecho, pues sobra decir que no es culpa mia, ni me convierte a mi en un mentiroso:






@M68K Llevar la contraria no es una falta de respeto, ni muchísimo menos, de hecho es una oportunidad para dejar claras posturas que se pudieran venir malinterpretando. En mi opinión, el enemigo con cuchillo que indicas en tu captura no debería sostenerlo en horizontal para ahorrar un sprite de 16x16.

Lo único que digo es que la configuración adecuada para el final fight 2 pide a gritos sprites de 32x32 y 8x8, no 32x32 y 16x16. Había margen para optimizar el uso de los sprites, y que con el hack de de 5 enemigos en pantalla se habría notado algún parpadeo menos. Tal vez. Jugar con carlos y maki a ese hack reduce mucho los parpadeos, es haggar quien rompe el juego en mayor medida por el sobre uso de sprites.

La configuración de sprites de snes es la que es, y para ciertos géneros exige no dejar pasar cualquier oportunidad para optimizar, porque si no se va a notar. Para otros géneros sus cualidades con los sprites son directamente estupendas.

Señor Ventura yo lo que dije fue de donde tú sacaste la información y para mi punto de vista es así como debe de ser fuiste directo a la fuente, al creador del parche
Aquí dejó el enlace

https://www.zeldix.net/t2002p25-killer- ... mega-patch

Señor Ventura escribió:

Cirote3 escribió:Si no eres moderador, ¿quién eres tú para decirme lo que puedo escribir y lo que no? ¿Quién es el que está "imponiendo su rasero", "calificando los mensajes de los demás", "faltando al respeto" y "vetando participar"?

Ok, te respondo a propia petición tuya, luego no te quejes de la clase de respuesta que es.


¿Quien califica los mensajes de los demás?, tu lo hiciste. Una queja por tu actitud no es reproducir los motivos de mi queja... y parece mentira tener que explicar esto.
hilo_super-nintendo-hilo-oficial_1413431_s3400#p1756903119

En un mismo post eres capaz de decir que si no soy moderador no soy nadie para decir que cosas no se deben poner aunque sean ataques hacia mi, pero al mismo tiempo exigir cuando debo participar en el hilo, y en que condiciones de redacción debo hacerlo, porque si no es una falta de respeto.
hilo_super-nintendo-hilo-oficial_1413431_s3400#p1756912695

Yo te dije que escribir en un hilo sin leer los mensajes de los demás es de mala educación. Lo sigo manteniendo, y dudo mucho que cualquier persona que lleve suficiente tiempo participando en foros piense de otra forma. Si no lo compartes, lo siento por ti.

Tú en cambio me dijiste que no puedo hablar de otras consolas porque "el resto de consolas sobran, no vas a aceptar batallitas ni discusiones de patio de colegio" y me ordenaste que "lo dejara ahí" como si fueras un moderador o el dueño del foro. ¿Ves la diferencia entre los dos comportamientos? ¿Vuelves a ver la falta de educación?

Señor Ventura escribió:@M68K Llevar la contraria no es una falta de respeto, ni muchísimo menos, de hecho es una oportunidad para dejar claras posturas que se pudieran venir malinterpretando.

¿Te has parado a pensar que igual eres tú el único que está malinterpretando?

Señor Ventura escribió:En mi opinión, el enemigo con cuchillo que indicas en tu captura no debería sostenerlo en horizontal para ahorrar un sprite de 16x16.

Yo creo que quedaría fatal si el cuchillo no llevara su propio sprite. ¿Puedes hacer un dibujo/boceto a ver cómo quedaría?

Señor Ventura escribió:Lo que único que digo es que la configuración adecuada para el final fight 2 pide a gritos sprites de 32x32 y 8x8, no 32x32 y 16x16.

Si usas sprites de 8x8 igual te quedas sin sprites en pantalla, sin ROM o sin CPU. Lo más normal es que Capcom hiciera mil pruebas y decidiera los tamaños de sprite óptimos en base a ellas. ¿Puedes probar que tu setup es mejor que el de Capcom?

Señor Ventura escribió:La configuración de sprites de snes es la que es, y para ciertos géneros exige no dejar pasar cualquier oportunidad para optimizar, porque si no se va a notar. Para otros géneros sus cualidades con los sprites son directamente estupendas.

A mí no se me ocurre ningún género en el que la configuración de sprites de la SNES sea mejor que la de Mega Drive. Si has llegado hasta aquí, ¿puedes mencionar alguno?

Entonces aplícate el cuento, y léeme bien. El resto de lo que haces, y has estado haciendo durante meses, no tiene ninguna justificación.

Y aquí se acaba el tema.

@Señor Ventura
Pienso que, por mucho que se vea o se muestre, la elección de 16x16-32x32 te da la libertad incluso de sacrificar algunos sprites puntuales (como los que has mencionado) donde apenas se dibuja nada a cambio de evitar una posible saturación de OAM donde en un momento dado se te pueden juntar 2 jugadores con objetos, 3 enemigos enormes, efectos a las colisiones etc... y si se van a suceder escenas como estas constantemente, cualquiera se decantaría por los tamaños de 16x16 y 32x32.


Te estás fijando demasiado en puntos concretos donde la optimización 16x16-32x32 no cumple su función cuando a nivel general se optimiza mejor con todo lo que muestra el juego.

Y entiendo que digas "tendrían que haber dibujado de forma que esos 3 pixeles no se desaprovechasen por 1 sprite".

A un grafista se le da una serie de indicaciones y no tiene por qué saber programar. El grafista va a haciendo su trabajo y se le va dando el visto bueno/malo. Imagínatelo terminando su trabajo sólo en un pj: 50 sprites de Haggar listos para usarlos.
- Programador: Oye... que he estado probando y hay algunos momentos en los que tengo que gastar un sprite de 16x16 por que sólo dibuja 3 pixeles.
- Grafista: Ajam, y no me lo podías decir antes cuando aprobaste el boceto? de hecho ¿El gasto de ese sprite hace que le juego sea injugable o que no se pueda meter en pantalla o no sea estable?
- Programador: No, se puede poner tranquilamente con la configuración que tengo pero...¿Podrías redibujarlo?
- Grafista: 50 posturas. De un sólo personaje. Por 3 pixeles que puedes poner sacrificando 1 sprite, Ajam,¿Quieres que mientras lo hago te abanique?

Además de todo esto, se realizan test varios durante el desarrollo constantemente, la elección es puramente de trade off con lo que se ha diseñado a mostrar, lo que el diseño de sprites exigen y lo que el programador adapta. Y para ellos ha tenido mucho más sentido evitar consumo de OAM antes queevitar el posible flickering respecto a los personajes que van a poner en pantalla.

No digo que cambies de opinión, tú puedes seguir erre que erre con tu punto tanto como desees. Luego otra cosa es ponerse a programar y configurar unos determinados aspectos dentro de un sistema limitado de tamaño de sprites buscando un balance lo más estable y lógico posible en un código que contenga offsets de OAM, tamaño de entradas, DMA, WRAM, registros de PPU, Operaciones, gestión específica del 65816...

Que un sprite o varios tenga píxeles sin utilizar en un frame concreto no significa que esos recursos estén desperdiciándose: para juzgar la optimización hay que mirar cómo funciona el sistema completo, no un elemento aislado.

Señor Ventura escribió:Entonces aplícate el cuento, y léeme bien. El resto de lo que haces, y has estado haciendo durante meses, no tiene ninguna justificación.

Y aquí se acaba el tema.

De verdad te digo que no sé de lo que estás hablando.

¿Puedes por lo menos centrarte en las preguntas relacionadas con la SNES que te hice en el último mensaje y responder a alguna de ellas? ¿Llegaste a leerlas?

M68K escribió:Que un sprite o varios tenga píxeles sin utilizar en un frame concreto no significa que esos recursos estén desperdiciándose: para juzgar la optimización hay que mirar cómo funciona el sistema completo, no un elemento aislado.

+1000

La gente que no sabe programar suele centrarse en el árbol en vez de en el bosque.

Yo estoy enganchadisimo a este hilo dónde por fin no se lanzan afirmaciones al vuelo sino con debugger.

¿Si tienes un rato @M68K, puedes analizar el KI?, es de los pocos juegos VS (porque que no me atrevo a decir el único) que no usa cinemascope y tiene ya los sprites muy decentes de tamaño, a mi me parece un portento técnico en SNES.

¿Crees que se podrian haber hecho con los sprites del arcade como se dice por ahí porque al igual que Capcom los de Rare tampoco sabian optimizar? ¿Se está aprovechando el hardware que hay?

Siento volvertelo a pedir pero como han vuelto a sacar el tema pues ya es algo que me encantaria saber sobre todo cuando no tenemos la supuesta rom hackeada para analizar.

Un Saludo.

7Force escribió:Enormes ejemplos y enormes explicaciones.

Bravo, chavales, así da gusto entrar en los hilos

Hacía tiempo que no disfrutaba de datos técnicos. Nunca he entendido del tema ni me he calentado la cabeza, pero cuando te lo explican de esa manera, da gusto.

Gracias por los aportes.

@Señor Ventura Cuando hablas de que en Capcom fueron vagos, o no optimizaron el juego (perdona si hay inexactitud en mis palabras), ¿Eres consciente de que crees tener una llave que un buen grupo de "cerebritos" japoneses que se jugaban el pan no dieron con ella?

Parte de razón tiene, pero no solo Capcom era "vaga" (el caso que más me escama en Snes es el Capitán Comando), habían muuuuchas compañías que lo eran. Y no pequeñas, precisamente.

Lo que pasa que usar como argumento el tema del sprite ese enano de 16x16 para usarlo como apoyo a esta "corriente" -por así decirlo- de llamar vaga a Capcom, pues en este caso concreto parece un poco erroneo. O no tan "así" como parece.

El mismo Capitán Comando me parece mucho más reseñable, con unos fondos que dan puta pena. Y unos sprites que parecen moverse a 30 fps.
Dudo horrores que ese juego en concreto no pueda tener una mejor versión. Y me refiero en su tiempo, no una actualizada de estas que se hacen hoy en día. Supongo que al ser un juego relativamente largo, usaron los 16 mb para meter todas las fases (bueno, ahora no recuerdo si las tiene todas, pero tiene un buen puñao) y hubo que recortar por otro lado. Ni idea, pero me parece un caso bastante llamativo.

Por otro lado, Final Fight 2 siempre he pensado que es un juego muy competente y sólido, con unos sprites tremendos en Snes. Los ves y dices "esto sí que sí". Nunca entendí muy bien ese aura que tiene de "juego meh". No será top de tops, pero competente es. Más que otros, en mi opinión. A mi me parece mejor que el 1 en Snes, mismamente.

Y eso, habría que relajarse un poquito y no ponerse tan a la defensiva cuando se replica algo. Para eso esto es un foro de opinión. Lo que no puede ser es venir a decir "lo mio" y no querer recibir ningún tipo de respuesta por que no me gusta lo que me dicen.

Buen finde!

@7Force Final Fight 2 me lo he pasado un par de veces y lo he disfrutado mucho, a mi me parece un gran juego.

Ese aura de "juego meh" que dices, se la dan los eruditos de la primera parte arcade. Para hacer "su" juego intocable, hace falta rajar del resto de versiones o secuelas.

Está claro que como en cualquier compañía dentro o fuera de los videojuegos, Capcom tendría que recortar lo que hiciera falta para sacar los juegos a tiempo con los desarrolladores que tenían a mano. Pero el tiempo de desarrollo al elegir un par de tamaños de sprite u otro es el mismo, así que dudo mucho que eligieran 16x16 y 32x32 por "vagancia".

Otro tema que creo que no se ha mencionado es que con sprites de 8x8 es más fácil tener parpadeos que con sprites de 16x16, ya que en la SNES aparte de haber un límite de 34 tiles de sprites por scanline, hay un límite de 32 sprites por scanline. Reducir el tamaño de los sprites aumenta el número de ellos por scanline, lo que hace más fácil alcanzar el segundo límite.

Aunque para mí el Final Fight 2 es el más aburrido de los 3, como decís en la parte técnica está muy bien hecho, mucho mejor que el primero. Nunca lo pondría como ejemplo de la supuesta "vagancia" de Capcom.

Dene escribió:@Señor Ventura Cuando hablas de que en Capcom fueron vagos, o no optimizaron el juego (perdona si hay inexactitud en mis palabras), ¿Eres consciente de que crees tener una llave que un buen grupo de "cerebritos" japoneses que se jugaban el pan no dieron con ella?

Nunca he entendido esa manía que se tiene con criticar el trabajo de los demás sin tener ni puta idea de su trabajo. Son como los que se ponen a criticar al entrenador de su equipo de fútbol en la barra del bar o como los jubilados con los edificios en construcción

7Force escribió:Y eso, habría que relajarse un poquito y no ponerse tan a la defensiva cuando se replica algo. Para eso esto es un foro de opinión. Lo que no puede ser es venir a decir "lo mio" y no querer recibir ningún tipo de respuesta por que no me gusta lo que me dicen.

A mí cuando me corrigen me parece algo bueno porque cuando pasa aprendo algo nuevo. Lo suyo sería dar las gracias en vez de enfadarse cuando te corrigen

Estoy siguiendo el hilo con palomitas porque no soy ni de la SNES ni de la Mega Drive. En general me cae mejor SEGA, pero en esa generación, la SNES se me antoja "más natural" para mi alma de MS-DOS (además de que se parece más a la Play, mi consola favorita). En 8 bits tuve un CPC de disco a color.

El caso es que me imagino la cara que se le pondría a un fan del Commodore 64 leyéndoos. Como sabéis, el Golden Axe de esa plataforma solo tenía un fruto enemigo por pantalla. Más que error, fue un engaño: claramente querían que las pantallitas quedaran bonitas.

Como curiosidad, en Lemon64 hay análisis del juego tanto de fans como de revistas. Y en la revista inglesa ZZap!64, le cascaron un 96... cuando en un análisis, los periodistas mencionan a los programadores con su nombre de pila, ya sabes que algo no va bien. Como todos estaban en Inglaterra, todo quedaba en casa. Se nota a la legua que se conocían.

@naxeras
Intentaré responder lo mejor posible con lo que sabemos, lo que podemos ver, lo que se ha visto y lo que el debugger me muestra.

Empecemos sobre lo que el debugger nos dice de Ki de SNES:
- El juego se ejecuta en mode 1, uno de los mejores modos gráficos de SNES y de los más utilizados. 2 fondos a 4bpp para el juego (15 colores por tile + 1 transparente de entre 8 paletas) y el fondo 3 a 2bpp para las barras de vida/nombres (3 colores por tile + 1 transparente de entre 8 paletas)


- El juego está en FastROM.

Pero no sólo hay que fijarse en que el flag de FastROM esté habilitado; también hay que mirar que el código se esté ejecutando en la zona de memoria rápida de la ROM. Entre los bancos $80 y $FF (los Bancos 83D... se encuentran en esa zona):


- No usa Color Math ni Pseudo High Resolution Mode porque ADEMÁS tener el flag de High Res Mode inactivo (registro $2133.3)

Tampoco muestran diferente información Main Screen Layers y Sub Screen Layers:

Para que hubiera un pseudo High res mode en modo 1 (simular 512p de ancho), esos registros deberían mostrar configuración diferente. Tendría que verse algo así:
Main: A C E G I

Sub : B D F H J

Pero lo que tenemos es:

Main: A A A A A

Sub : A A A A A

- Utiliza los tamaños de sprites más pequeños: 8x8 y 16x16


- Los 16KBs máximos de VRAM reservada para tiles para sprites se dividen en 2 bancos, 1 banco de 8KB para el jugador 1 y un banco de 8KBs para el jugador 2.


- Los luchadores no se animan al mismo tiempo, esto es, si necesitan cambiar de postura al mismo tiempo, primero se anima uno en un frame y luego el otro (muy típico en juegos de lucha donde el tiempo de VBlank no da para todo) y la transferencia de tiles se hace EXACTAMENTE el frame anterior a cambiar de postura.

Esto es lo que sabemos con certeza.
----------------------------------------------------------------------------------

Lo que seguramente te interesa especialmente: ¿Por qué KI no utiliza barras negras (aumento artificial de VBlank para ganar tiempo)?

Respuesta rápida: Porque durante el frame entero tiene tiempo para los cálculos, transferencias de datos y preparación para el siguiente frame.

El animar una vez a cada personaje ayuda mucho en este aspecto. ¿Qué podemos observar de esto?
Vemos qué ocurre durante 1 frame previo al cambio de postura:

¿Qué son esos puntos azules diagonales que vemos en lo que resta de VBlank? En la tabla de abajo de VBlank pone lo que se está haciendo en ese momento en cada scanline y vemos que cada 60 ciclos la CPU (puntos azules) está leyendo un registro... ¿Qué es? Entre el espacio de dos puntos azules... ¿La CPU está haciendo trabajo útil o está simplemente dando vueltas esperando algo del VBlank?


Para averiguarlo vamos a la dirección que se repite cada 60 ciclos (Address) buscando qué demonios pasa en HVBJOY ($4212) y me llevó a la dirección $81DF9A, que es la dirección del código donde se realiza esa lectura.
Entonces encontré este "wait loop"
$81DF98 SEP #$20
$81DF9A LDA $4212
$81DF9D BMI $81DF98

Lo que hace es que simplemente la CPU lee a cada rato HVBJOY para comprobar si el VBlank sigue activo o ya ha acabado: LDA $4212 lee el registro y BMI $81DF98 vuelve al principio del bucle mientras el bit 7 esté activo; cuando VBlank termina y ese bit pasa a 0, el salto no se ejecuta y la CPU continúa con el resto del código.

Esto es, la CPU no está haciendo absolutamente nada más que esperar a que VBlank termine para ponerse con el código durante el siguiente frame. Y si alguien se lo pregunta, ese tiempo restante, no se puede aprovechar para nada, ya se ha hecho todo lo que había que hacerse en ese frame.


-------------------------------------------------------------------

¿Esto qué nos dice?

Que tal y como esta configurado el juego, NO es necesario tener bandas negras (aumento artificial de VBlank) porque tiene tiempo necesario para realizar sus cáculos/rutinas y transferencias durante todo el frame.

Ahora la pregunta que quizás alguno se haga ¿Teniendo tanto VBlank con la CPU esperando, por qué no se animan a los 2 jugadores?

Volvamos a la imagen que hemos puesto antes con los colores de verde y morado de lo que ocurre en VBlank.
Lo que vemos es el gasto para 1 sólo personaje. Si hiciésemos transferencias de los 2 personajes a la vez, tranquilamente se duplican los puntos verdes de escritura/lectura en OAM y de transferencias gráficas necesarias a VRAM. ¿Cuánto Vblank nos queda? Aún parece que hay tiempo pero...

Pero aún hay más:

¿Y si a la CPU teniendo que calcular la postura del segundo jugador no le da tiempo a realizarlo mientras se dibuja la pantalla?
¿Y si la CPU pasa demasiado tiempo descomprimiendo/preparando gráficos para el P2?
¿Y si necesita comunicarse con el SPC700 y le pilla a este en una rutina que acaba de empezar y le hace esperar demasiado a la CPU para recibir órdenes?
(Para comunicarse con el sistema de sonido y decirle "ei! hay una colisión, haz el sonido de "Booom!!!", el SPC700 tiene que comprobar cada cierto tiempo si la CPU le espera para darle una orden, pero si en el momento que la CPU quiere decirle algo al SPC700 pero este, tras comprobar que no le han llamado está haciendo sus cosas hasta terminar sus bucles, es tiempo que se pierde).
¿Y si hay otro escenario donde también haya que calcular las animaciones de fondo por que hay más en él?
(La reducción de animación general ayuda, de ahí que juegos como Gundam o Power Rangers: The Fighting Edition muestren tan poca animación de fondo).

Conociendo esas posibles variables de otras tantas, dejar espacio para imprevistos es algo necesario.

No sabemos con certeza que, en el tiempo sobrante de VBlank que vemos, de tiempo a la CPU a terminar los cálculos si intentásemos animar simultáneamente a los dos jugadores. Pero lo que sí sabemos es que no se configuró de esa manera cuando hacerlo ayuda visualmente a tener un juego más fluido. Luego teniendo ese tiempo sobrante, decidieron programar el juego de manera que no hubiera riesgo de quedarse sin Vblank y sin tener que tirar de bandas negras.

------------------------------------------------------------------------

Entonces entramos en la siguiente pregunta que haces Naxeras:

¿Es posible usar los gráficos del arcade en SNES sin el uso de bandas negras?

Depende. Si da tiempo sí, si no da tiempo, no.
Parece sencillo pero me explico:
Esta imagen que han posteado no es concluyente de si eso es posible o no.


¿Por qué?

Por que si es para tan sólo animar dos personajes por turnos entre frames sin nada más no es prueba de capacidad.
¿Los personajes pueden realizar posturas diferentes además del base? No lo vemos, no está comprobado.
¿En esa imagen hay colisiones, cambios en la barra de vida de los personajes, y efectos cuando se golpean? No lo vemos, no los hay, no está comprobado que puedan hacerlo.
¿Está el sistema de sonido implementado para cuando golpean, caen, caminan, rugen?? No hay sonido, no está comprobado.
¿La CPU puede calcular todos las variables, datos, preparación previa de transferencia de tiles, escrituras OAM antes del tiempo de Vblank? No lo sabemos, no se muestra, no está comprobado.

----------------------------------------------------------------------------------

Entonces entramos en las hipótesis lo que conocemos y lo que no.
Pongamos como ejemplo juegos como Gundam o el de los Power Rangers:

No necesitas bandas negras para adaptar su Relación de Aspecto a algo proveniente de un arcade (meter un AR de 4:3 dentro de un AR de 8:7) como se hace con Street Fighter ya que NO son ports sino juegos desarrollados para esta consola.

Luego: ¿Qué juegos de lucha a 60 fps (importante que no a 30) se han visto con tamaños de PJs de Gundam o Power Rangers o mayores que no usen bandas negras? ¿Que cantidad de animación hay de fondo? ¿Tiene tiempo la CPU de descomprimir gráficos, realizar sus rutinas, conectar con el SPC700 antes de llegar a VBlank para dedicarse exclusivamente a transferencias gráficas y lectura/escritura OAM?

Y por último habría que mirar si los sprites del KI de arcade son mayores a los juegos citados y podemos sacar ciertas suposiciones (que no certezas absolutas) que pueden validar el punto de si es posible o no un juego de lucha en SNES con ese tamaño de PJs sin bandas negras.

Más que nada es preguntarse porqué ha existido una "misma" solución (aumento de Vblank, las bandas engras) llevado a cabo por diferentes compañías en diferentes épocas con diferentes devs, cuando se trata de juegos de lucha con personajes de tamaño considerablemente grandes con mucha exigencia DMA.

Vaya, espero que te haya servido. Si tienes dudas dime

@M68K Gracias por tus explicaciones técnicas!!!
Es muy de agradecer que alguien se tome todo el tiempo que te tomas tú en usar el debbuger, en hacer cálculos con datos reales y, sobre todo, en no afirmar ni desmentir tajantemente cosas que como bien dices: no lo vemos, no está comprobado (lo mismo va para @cirote3)

Me quito el sombrero ante vosotros

Lo más impresionante hasta la fecha que se a visto en snes es el KoF del programador Rafael aquí dejó un enlace https://x.com/faeldaniel/status/2048523 ... 84829?s=12

@M68K gracias por el post otra vez, así da gusto.

Hace tiempo comentamos en este hilo que efectivamente el Killer Instinct de la SNES actualiza solo un personaje por frame y otros juegos como el Street Fighter Alpha 2 no, con sus ventajas e inconvenientes.

Dejo enlaces a algunos de mis mensajes:
hilo_super-nintendo-hilo-oficial_1413431_s3100#p1756640160
hilo_super-nintendo-hilo-oficial_1413431_s3100#p1756642665
hilo_super-nintendo-hilo-oficial_1413431_s3100#p1756643169
hilo_super-nintendo-hilo-oficial_1413431_s3150#p1756643507

@cirote3 @M68K

Muchas gracias por las explicaciones.

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

Snes escribió:Lo más impresionante hasta la fecha que se a visto en snes es el KoF del programador Rafael aquí dejó un enlace https://x.com/faeldaniel/status/2048523 ... 84829?s=12

Lo que es una pena de esto es que no hay demo todavia cuando se supone que se iba a sacar sobre todo con la controversia que hubo con los 50HZ que dan mas tiempo de VBLANK es una pena porque asi se podria analizar si va a 60fps, 30fps o 25fps, hace tiempo que no saca novedades.


En cuanto a si merece la pena lo de 30fps... yo no tengo ni idea de KI ni el de SNES ni de arcade (vamos nunca me he puesto con ellos en serio) asi que no puedo opinar si el sacrificio merece la pena jugablemente pero los juegos que conozco yo diria que en SNES van a 60 como en el arcade. SF2, SSF2, SFA2, Fighter History y la versión mizoguchi que este último no solo tiene bandas si no que tiene un marco negro y se hace raro, si alguno de estos va a 30 (que lo dudo porque las bandas están gordotas ahí) diria que si merece la pena el sacrificio.

Para mi esos juegos jugablemente son una delicia, el powerinstinc yo diria que va a 60 pero tiene ralentizaciones severas severas, no se si usa slowrom pero ufff afecta mucho a la jugabilidad tambien tiene bandas asi que parece que la mayoria de estudios optaban por mantener los 60fps del Arcade y sacrificar banda y tamaños de personaje que ademas hace que las roms sean mas pequeñas que meter los 30fps sin bandas.

Un Saludo.