¿Hubiese sido posible un Metal Slug decente en SNES?

* 01 feb 2019 13:07

2 valoraciones positivas

Enlace permanente

@magno , aprovechando te hago una preguntita. ¿La detección de colisiones es vía hard? ¿La hace la CPU o la PPU? Creo recordar que en los micros de 8 bits las colisiones las soportaban los chips de video dejando a las cpus libres. Pero vamos te pregunto desde el desconocimiento.

No conozco ninguna PPU que haga detección de colisiones, ya que las PPUs suelen trabajar con las tiles de la imagen y aplican efectos sobre ellas, pero no saben si dentro de esa tile, en el pixel (4,6) por ejemplo empieza un sprite que colisiona con una pared que está en la tile adyacente. Es decir, que la PPU trabaja con píxeles/tiles y no con lo que representan esas tiles/píxeles, ya sean personajes o escenarios.
La colisión siempre la detecta la CPU, que es la que procesa unos metadatos que van asociados a los sprites: tamaño del sprite, dirección donde mira, altura a la que está desde el suelo, etc.
Y se hace por software, no por hardware, ya que si se hiciera por hardware tendría que ser una unidad dedicada a la que le pasaras esos metadatos y calculara la colisión; esos metadatos cambian según el tipo de juego, por lo que no podría ponerse como un hardware que se usara de forma genérica.

* 01 feb 2019 13:16

Enlace permanente

El juego salió en el año 96 cuando ya había muchos juegos de 32 megas y el chip FX2.

En 1996 no había muchos juegos de 32 megabytes, lo que había era muchos juegos de 32 megabits (4 megabytes). Doom 64 es de 1997 y va metido con calzador en una rom de 64 megabits (8megabytes).

Los primeros juegos de N64 suelen ocupar 8 megabytes (Star Wars Shadows of Empire, Mario 64, Wave Race, Mario kart 64, Doom 64) y alguno de 12 (Goldeneye creo). Puede que haya alguno de 32 en esas fechas, pero este tamaño de ROM en general no abunda en todo el fullset suele ser en juegos de 1997 en adelante.

En Snes no estoy seguro, pero creo que lo máximo fueron 32 megabits (4 megabytes).

Obviamente, yo estaba hablando de 32 megabits.

El usuario al que he citado dice que los juegos de Super Nintendo de la época eran de 16 megas (se entienden megabits porque juegos de 16 megabytes NO hay ninguno), y yo le replico que no, que en 1996 ya no eran 16, sino 32 megabits.

En la época los cartuchos se medían en megabits (tanto en SNES como en N64). Cuando en SNES hablamos de megas son megabits siempre.

Si leyeras mis replicas de más adelante con un compañero del foro te darías cuenta de que lo que acabas de afirmar sobre el usuario "al que acababas de citar" lo has supuesto tú solo por ti mismo cogiendo una sola frase de todo mi mensaje para sacarla del contexto y llevarla donde mejor te ha parecido, no las pienso repetir todas que llevo un día regulero y voy fatal de tiempo, un mal día lo tiene cualquiera, pero bueno venga, aunque solo una...

No, no he dicho que ese fuese sólo el motivo, de hecho he comenzado diciendo "con los conocimientos actuales y sin limite de espacio, quizás a su manera,", ya ahí entran tres factores en juego, los conocimientos actuales, el límite de espacio, y tener que realizarlo a su manera con sus rutinas gráficas particulares; tampoco he afirmado que solo hubiesen juegos de 16 megas, de hecho por eso escribí "como se estilaba en la época", ya que los demás fueron los que menos, luego ya está lo que cada uno quiera acotar mi mensaje, tampoco he dicho en ningún momento que no se pudiese hacer nada, pero vaya sí, ni triplicándolo creo que sería suficiente para hacer algo de peso, es que los juegos de neo geo pesan una barbaridad y tienen mucha chicha, es sólo una percepción personal mía eso sí, claro está.

Tampoco se podría haber hecho un Metal Slug para SNES en su momento con los conocimientos antiguos, pero no porque esos conocimientos y capacidades fueran insuficientes, sino porque Metal Slug no existía durante la época fuerte de las 16bits, y ningún programador de 16bits lo pudo tener como referencia. El primer Metal Slug salió en el 1996, en los últimos estertores de las 16bits, y para cuando la saga se hizo tan popular SNES ya estaba más que liquidada.

Ya claro, eso sí, yo ya en fechas me pierdo, pero cada vez que recuerdo las demás conversiones de neo geo de aquella época y extrapolo... la verdad que no soy demasiado optimista de que hubiesen sacado algo decente, no sé hasta que punto le hubiesen sacado partido con la técnica de entonces, más teniendo en cuenta el factor tiempo y rentabilidad, eso sí, a día de hoy lo coge un grupo güeno de verdad, y con el cariño que se merece lo adapta, podría salir algo interesante, dentro de lo que cabe claro, porque la calidad de la versión de neo geo es que es sublime y sempiterna.

* 01 feb 2019 13:46

Enlace permanente

Si leyeras mis replicas de más adelante con un compañero del foro te darías cuenta de que lo que acabas de afirmar sobre el usuario "al que acababas de citar" lo has supuesto tú solo por ti mismo cogiendo una sola frase de todo mi mensaje para sacarla del contexto y llevarla donde mejor te ha parecido, no las pienso repetir todas que llevo un día regulero y voy fatal de tiempo, un mal día lo tiene cualquiera, pero bueno venga, aunque solo una...

No te sigo, yo lo que hablaba con Calculinho es que tanto tú como yo estábamos hablando de megabits, y eso es cierto.

Si quieres replicarme, cítame sobre mi mensaje original, NO sobre la respuesta a Calculinho:
viewtopic.php?p=1747246867

* 01 feb 2019 13:56

Enlace permanente

Con el paso del tiempo sigues teniendo el mismo cacao mental con la SNES y cómo funciona D
Ya te digo que tu afirmación no es cierta

Creo que el problema mas común que tenemos es que se relaciona la forma de definir ciertos aspectos técnicos, con lo que se interpreta, de una forma literal.

La OAM que se ve en el vídeo existe, no tiene nada de incierta.

no hay ninguna máscara de sprites, pero voy a intentar que llegues tú solo a la conclusión: si existe tal máscara... ¿dónde se almacena en la PPU? Es decir, si la PPU ha de enmascarar píxeles para no mostrarlos en pantalla, habrá que decirle en algún sitio qué píxeles se dibujan y cuáles no. ¿Sugieres que hay entonces una zona de memoria VRAM con información de máscara para cada píxel?
Si esto fuera así, necesitarías un buffer del tamaño de la pantalla para guardar esa máscara y por tanto, habría que decirle a la PPU dónde empieza ese buffer. ¿Qué registro de la PPU se usa para ello?

Son sprites, sin mas.

Y creo que se entiende y se ve perfectamente que se dispone de ellos a modo de lienzo, de máscara, de pantalla, de cortina. También se entiende así si se observa el vídeo.

Luego se han usado estas cosas por el foro para tirar mierda, provocar, y demás historias, y no creo que sea correcto, porque se entiende perfectamente que quiero decir, mas aún con un vídeo que lo contextualiza sin problema.

Los sprites llegan así a la vram de la snes desde la ram del sfx, dividios en tiles, y en el caso del super mario world son representados en sprites, es que ni entro en detalles.

Solución: no existe nada de eso que dices de máscara: el color 0 de la paleta es el color transparente para cada sprite; eso quiere decir que todos los píxeles que dibujes en el sprite con ese color, se verá transparente, es decir, dejará ver lo que hay detrás del sprite. Eso no es una técnica, eso es una obligación en un sistema basado en tiles para que los sprites no tengan que rellenar todo un tile y puedan tener formas redondeadas.
Y como te decía, esto no se usa en "algún juego" en concreto, sino en TODOS absolutamente del catálogo de la SNES, porque es la forma en la que trabaja la PPU.

No me has entendido.

No, ya que si haces scroll de los BG, también tienes que mover los sprites para que sigan ese scroll, lo cual implica actualizar toda la copia de la tabla OAM que tienes en RAM antes de enviarla a OAM. Por tanto la CPU no queda libre, ha de calcular las colisiones de TODOS esos sprites en la nueva posición del scroll.

Exigiría una sincronización mas difícil de llevar a cabo que hacerlo todo directamente con un procesador de apoyo.

Por eso dije que lo suyo sería hacerlo todo desde ahí. En el caso concreto del super mario world 2, al no haber scroll, la snes puede pintar el fondo ella sola, y lo que hay dentro de los sprites son calculados por el super fx para luefgo ser enviados a la vram.

No, ya te he comentado muchas veces que el fill-rate de la SNES no suele ser el problema en el 99% de los casos.
Si con "fill-rate" te refieres al límite de píxeles por scanline en tiles de sprites, el límite sigue estando si usas esa "técnica" que dices: de hecho se ve en el video que has puesto, ya que el máximo de ancho son 8 tiles de 16x16 (es decir, las 32 tiles 8x8 por scanline).

Me refiero que si haces que cada elemento movil de esa escena sea representada por los sprites que correspondan, te pasarías de tasa de relleno, y no habría OAM suficiente.

Ya te digo que no es ningún "truco" y por supuesto que con el chip de apoyo NO te saltas la limitación de la PPU. Piensa bien eso que dices, es una barbaridad: la PPU tiene una limitación en cómo lee las tiles de su VRAM interna, y dices que con un chip externo, que como mucho puede ESCRIBIR en esa VRAM, la PPU mágicamente deja de tener esa limitación. Eso no es como dices, es técnicamente imposible.

Te la saltas porque estás evitando que sea representado de la forma ordinaria, y así si que no hay recursos.

¿Cuantos elementos móviles hay en la pantalla de presentación del super mario world que se ve en el vídeo? (lo que se ve dentro de cada sprite).

resumiendo: es imposible entonces saltarse el límite de sprites por scanline de la SNES ¿?

De verdad, puse hasta un vídeo, yo es que no se que tengo que hacer ya.

Sobre todo para que deje de usarse para insultar, que esa es otra.

* 01 feb 2019 14:08

Enlace permanente

Si leyeras mis replicas de más adelante con un compañero del foro te darías cuenta de que lo que acabas de afirmar sobre el usuario "al que acababas de citar" lo has supuesto tú solo por ti mismo cogiendo una sola frase de todo mi mensaje para sacarla del contexto y llevarla donde mejor te ha parecido, no las pienso repetir todas que llevo un día regulero y voy fatal de tiempo, un mal día lo tiene cualquiera, pero bueno venga, aunque solo una...

No te sigo, yo lo que hablaba con Calculinho es que tanto tú como yo estábamos hablando de megabits, y eso es cierto.

Si quieres replicarme, cítame sobre mi mensaje original, NO sobre la respuesta a Calculinho:
viewtopic.php?p=1747246867

Puff, qué pereza, mucho lío ya, aceptamos pulpo como animal de compañía y ya está

01 feb 2019 14:20

Enlace permanente

@magno , aprovechando te hago una preguntita. ¿La detección de colisiones es vía hard? ¿La hace la CPU o la PPU? Creo recordar que en los micros de 8 bits las colisiones las soportaban los chips de video dejando a las cpus libres. Pero vamos te pregunto desde el desconocimiento.

No conozco ninguna PPU que haga detección de colisiones, ya que las PPUs suelen trabajar con las tiles de la imagen y aplican efectos sobre ellas, pero no saben si dentro de esa tile, en el pixel (4,6) por ejemplo empieza un sprite que colisiona con una pared que está en la tile adyacente. Es decir, que la PPU trabaja con píxeles/tiles y no con lo que representan esas tiles/píxeles, ya sean personajes o escenarios.
La colisión siempre la detecta la CPU, que es la que procesa unos metadatos que van asociados a los sprites: tamaño del sprite, dirección donde mira, altura a la que está desde el suelo, etc.
Y se hace por software, no por hardware, ya que si se hiciera por hardware tendría que ser una unidad dedicada a la que le pasaras esos metadatos y calculara la colisión; esos metadatos cambian según el tipo de juego, por lo que no podría ponerse como un hardware que se usara de forma genérica.

Creo que la Mega Drive y Master System sí tienen un flag que indica que un sprite colisiona con otro. Pero vamos, es un booleano y ya, aunque quizás sea útil para descartar colisiones y luego hacer los cálculos correspondientes en la CPU

01 feb 2019 14:27

Enlace permanente

Sexy MotherFucker está baneado del subforo por "faltas de respeto"

De verdad, puse hasta un vídeo, yo es que no se que tengo que hacer ya.

Sobre todo para que deje de usarse para insultar, que esa es otra.

Pero coño, si yo no he dicho nada despectivo, ni he aludido a nadie. Le he preguntado a magno, una autoridad en esta comunidad sobre tecnicismos de SNES precisamente para ir al grano del asunto sin hacer sangre de nada.

Voy a leerme vuestros tochos a vér qué carayo es lo que no he entendido, y de paso el vídeo ese que colgaste.

* 01 feb 2019 14:35

4 valoraciones positivas

Enlace permanente

@Señor Ventura
Lo primero de todo es que nadie te está insultando, sólo te estoy explicando en qué te equivocas. Y aunque le intentes dar vueltas semánticamente, lo que exponías no es cierto; te respondo a continuación:

La OAM que se ve en el vídeo existe, no tiene nada de incierta.

La OAM no es lo que se ve en el video por mucho que la pestaña de la ventana diga eso: lo que se ve en el video es la parte de VRAM que almacena las tiles de los sprites apuntados desde la OAM. La OAM es una tabla de 544 bytes con los primeros 512 bytes con los datos para los 128 sprites (4 bytes por sprite) y los 32 bytes siguientes (256 bits) son los 2 bits extras para la posición horizontal del sprite y el otro para cambiar la página de VRAM donde están las tiles del spruite. Por tanto, la OAM son 544 bytes donde no hay tiles, por lo que estás viendo en ese video no es la OAM, es la VRAM (que es el único sitio posible donde se alamacenan las tiles que se ven en pantalla, ya sean de BGs o de sprites)

Son sprites, sin mas.

Y creo que se entiende y se ve perfectamente que se dispone de ellos a modo de lienzo, de máscara, de pantalla, de cortina. También se entiende así si se observa el vídeo.

¿A modo de lienzo? Dices que se dispone a modo de lienzo como en todos los juegos de SNES... por tanto no hay ninguna "técnica" ahí, es como funciona el sistema. Lo que no es de ninguna manera es una máscara; supongo que no estás muy familiarizado con estos términos y los usas sin el debido conocimiento, pero para nada es una máscara, más bien es algo parecido a un canal alfa, donde un color se usa para hacer la transparencia.

Luego se han usado estas cosas por el foro para tirar mierda, provocar, y demás historias, y no creo que sea correcto, porque se entiende perfectamente que quiero decir, mas aún con un vídeo que lo contextualiza sin problema.

No se entiende perfectamente lo que quieres decir, porque leyendo tus palabras das una idea totalmente errónea de lo que realmente ocurre en la SNES; quizá sí sepas cómo va a SNES, pero entonces tu problema es que lo explicas mal.
Ya te lo dije anteriormente: no te metas en estos barrizales y nadie usará tus propios comentarios en tu contra.

Los sprites llegan así a la vram de la snes desde la ram del sfx, dividios en tiles, y en el caso del super mario world son representados en sprites, es que ni entro en detalles.

Claro, esto que dices sí es verdad, así es como funciona el SuperFX, nada de máscaras ni técnicas raras que solucionen el problema de sprites por scanline.

Exigiría una sincronización mas difícil de llevar a cabo que hacerlo todo directamente con un procesador de apoyo.

Por eso dije que lo suyo sería hacerlo todo desde ahí. En el caso concreto del super mario world 2, al no haber scroll, la snes puede pintar el fondo ella sola, y lo que hay dentro de los sprites son calculados por el super fx para luefgo ser enviados a la vram.

No dijiste eso ni de coña; en este comentario dices que "no hay scroll" y yo te estaba respondiendo a éste en el que dices qué pasaría si hubiera scroll:

Y la gracia de hacerlo con sprites, es que a la snes le dejas libre los planos para que su sistema gráfico pueda hacer scroll con uno o varios planos,

Me refiero que si haces que cada elemento movil de esa escena sea representada por los sprites que correspondan, te pasarías de tasa de relleno, y no habría OAM suficiente.

Maaaaaaaadre mía, qué cacao llevas......... ¡que la OAM no lleva tiles! A ver, la "tasa de relleno" de la que tanto hablas es la capacidad de enviar píxeles a pantalla, que en el caso de SNES es fija: la SNES está diseñada para ser suficientemente capaz de generar la resolución de 256x240 píxeles de pantalla, es decir, que el fill-rate se deriva del reloj de píxel y la resolución, ambas fijas; lo que supongo que quieres decir es la tasa de envío de tiles a VRAM, que no es el fill rate, pero en este caso, esa tasa de envío de tiles a VRAM no tiene que ver con la OAM porque ésta no lleva tiles.

Te la saltas porque estás evitando que sea representado de la forma ordinaria, y así si que no hay recursos.

No es cierto, no te la saltas de ninguna manera porque esa imagen del SMW2 es una imagen como cualquier otra hecha con sprites y sigue teniendo la misma limitación, que ya te he comentado que en el video se ve claramente como no ocurre el error: hay 32 tiles en un scanline, por tanto, no hay problema.

¿Cuantos elementos móviles hay en la pantalla de presentación del super mario world que se ve en el vídeo? (lo que se ve dentro de cada sprite).

Malinterpretas lo que estás viendo en ese video totalmente: los "elementos móviles" son tiles que se están actualizando en VRAM, mientras que los sprites son estáticos, es decir, la tabla OAM está configurada para que aparezcan en pantalla ciertos objetos de 16x16 píxeles y hace un "layout" con esos sprites, poniéndolos uno al lado de otro de la manera adecuada para la imagen. Luego, el SuperFX está generando la imagen y envía a VRAM las tiles que se pintarán en esas posiciones de pantalla. No hay ningún misterio más, es lo que se hace en TODOS los juegos de SNES.

resumiendo: es imposible entonces saltarse el límite de sprites por scanline de la SNES ¿?

De verdad, puse hasta un vídeo, yo es que no se que tengo que hacer ya.

Pues estaría bien que empezaras a entender de lo que hablas, por que en ese video no explica nada de lo que has dicho en los otros posts.

* 01 feb 2019 15:32

Enlace permanente

Sexy MotherFucker está baneado del subforo por "faltas de respeto"

Si se analiza el metal slug, la primera fase, es facil ver q esta todo diseñado para no saturar la vram

Mas bien habría que decir que está todo diseñado pensando en una Neo-Geo, donde el uso de la vram y datos en general es totalmente diferente a cómo los tratan SNES o MD:

- El LSPC (chip gráfico de la Neo Geo) puede leer los sprites directamente desde las ROMS gráficas del cartucho (C-ROM sprites o S-ROM para Fix Layer/Marcadores) y operar sobre la marcha con ellos, cartuchos que funcionan a una velocidad de transferencia de 8 Mhz, eso sin contar la tasa de relleno final del propio chip a la pantalla el cual rula a 24 Mhz.

Por comparar los cartuchos de SNES funcionan a velocidades de 2'68 Mhz (lo-rom) o 3'58 Mhz (hi-rom), y los de Mega Drive a 5 Mhz (MROM) o 7,67 Mhz (EPROM).

- Luego tiene 64 kb de vram que no utiliza de manera tradicional, otros 16 Kb exclusivamente para las paletas (lo cual es una burrada), 128 Kb fijas de ROM para los zooms, otras 128 kb para el fix layer (marcadores), y otras distribuciones que no termino de entender pero que de las cuales llego a la conclusión de que la Neo Geo es una bestia de pura fuerza bruta.

Vamos que entre las ROMS gigantescas, el acceso/uso ultra-directo a los datos de éstas, el brutal ancho de banda por frame, el uso flexibe de la vram, los pozos de memoria anexos, etc, tenemos un bicho que tiene poca o ninguna necesidad de repetir elementos en pantalla, y que potencialmente puede pintar lienzos con 3840 colores a la vez con la limitación de 16 por sprite/tile/patrón (15 + transparente).

Aquí un reportaje sobre las entrañas de esta bestia:

https://disruptiveludens.wordpress.com/ ... o-neo-geo/







Decididamente es otro nivel por "peros" que tenga.

* 01 feb 2019 15:49

1 valoración positiva

Enlace permanente

Un sistema que nace en 1990 y llega comercialmente hasta 2004, sin ayuda ni mejora alguna, exactamente con el mismo hardware, viendo como a su paso nacen chips y addons para las 16bits, 2 generaciones de consolas más y varias generaciones de arcade de sus rivales directos (CPS1, CPS2...), como para no considerarlo una bestia.

Parte será causa de la debilidad en hardware de SNK, y por tanto de la necesidad de sacarle todo el jugo posible a MVS; pero es que si el sistema no hubiera sido tan solvente eso habría resultado imposible.

01 feb 2019 15:59

Enlace permanente

@Sexy MotherFucker

Pues analiza el primer nivel y luego me dices

* 01 feb 2019 16:03

Enlace permanente

Sexy MotherFucker está baneado del subforo por "faltas de respeto"

@theelf que no digo que no sea cierto lo que dices, digo que en general ese es el tipo de diseño para Neo Geo a partir de muchos megabits, ya que no tiene necesidad de saturar la vram debido a su facilidad para leer directamente desde las ROMs y refrescar las memorias al vuelo, a diferencia de SNES/MD que están limitadas por su única VRAM en la que guardan todo (paletas, sprites, tiles de fondo, etc) y su escaso ancho de banda por frame con el que pegan "pantallazos" a trancas y barrancas.

Que hiciste una puta demo de Metal Slug para Mega Drive, respeto máximo chavón xD

* 01 feb 2019 17:38

Enlace permanente

Una de las cosas que mas se notarian en una hipotetica conversion de Metal Slug a Supernes serian el recorte en animaciones pues en los juegos originales hasta los personajes tienen animaciones faciales. Ahora bien yo me pregunto algo, que tanto impacto tienen estas animaciones en los juegos aparte de hacerlos ver espectaculares?, o sea las animaciones aportan realmente algo a la jugabilidad?.

Para mi no, si estan bonitas y son detalles esteticos que molan pero si no las tuviera el juego jugablemente seguiria siendo igual, claro solo es mi opinion pero la exagerada cantidad de animaciones de MS me parecen solo detalles estéticos para presumir putensia grafica.

En donde si que podria haber una repercusion jugable es en la cantidad de enemigos en pantalla pero supernes ya demostro en el port de Kings of the Round que es capaz de mostrar varios enemigos en pantalla, sobre todo consideramos que los personajes de Metal Slug son enanos en comparacion con el tamaño de los personajes que suelen tener los juegos de Supernes.

* 01 feb 2019 17:40

Enlace permanente

a diferencia de SNES/MD que están limitadas por su única VRAM en la que guardan todo (paletas, sprites, tiles de fondo, etc)

¿Tu estás seguro de eso? Me parece muy raro eso que dices de que en SNES y MD se transfiriesen los recursos graficos a una RAM en vez de usarlos desde la ROM directamente.
Las paletas, si, mas que nada porque eso permite efectos de ciclado y otras cosas, y los sprites, me imagino que algun efecto especial podría requerirlo, pero no creo que sea la practica generalizada para el transcurso habitual del juego. Lo que se almacenará en RAM será la informacion de cómo construir la escena, pero a la hora de dibujarla, los graficos se leerán, en su mayoría, desde la ROM, especialmente los fondos, y en la VRAM solo estará un mapa de donde va cada celdilla y dónde está en la ROM.
En ese sentido, y con sus salvedades, la tecnica basica es igual en todo sistema 2D clasico. Luego está que en los sistemas domésticos contemporaneos, el chip grafico no puede manejar tantos objetos y seguramente tampoco podrá acceder a tanta ROM de una sola vez. Mucho bankswitching del ala. Desde el desconocimiento de los detalles tecnicos de NEO-GEO, me aventuro a asumir que tendrá mucho hardware dedicado a poder acceder a un monton de ROM simultaneamente, cosa que la diferenciará de los mas modestos sistemas domésticos de la epoca.

O sea, puedo equivocarme. No tengo suficiente certeza de que sea como digo como para afirmarlo categoricamente, pero de verdad que me suena rarísimo lo que dices.

* 01 feb 2019 17:46

1 valoración positiva

Enlace permanente

Una de las cosas que mas se notarian en una hipotetica conversion de Metal Slug a Supernes serian el recorte en animaciones pues en los juegos originales hasta los personajes tienen animaciones faciales. Ahora bien yo me pregunto algo, que tanto impacto tienen estas animaciones en los juegos aparte de hacerlos ver espectaculares?, o sea las animaciones aportan realmente algo a la jugabilidad?.

Para mi no, si estan bonitas y son detalles esteticos que molan pero si no las tuviera el juego jugablemente seguiria siendo igual, claro solo es mi opinion pero la exagerada cantidad de animaciones de MS me parecen solo detalles estéticos para presumir putensia grafica.

En donde si que podria haber una repercusion jugable es en la cantidad de enemigos en pantalla pero supernes ya demostro en el port de Kings of the Round que es capaz de mostrar varios enemigos en pantalla, sobre todo consideramos que los personajes de Metal Slug son enanos en comparacion con el tamaño de los personajes que suelen tener los juegos de Supernes.

Estamos hablando de una forma de expresión artística, como son los videojuegos (al menos los buenos). Esos detalles no solo molan, sino que son elementos distintivos de los juegos y de sus autores.

Si nos ponemos a revisar todos los juegos, para eliminar ese tipo de detalles "innecesarios", como si fuéramos bots de Skynet o de Matrix, el panorama genérico que íbamos a dejar en los catálogos sería bonico.

------

Para mí, SNES puede recibir un port adaptado de Metal Slug, como a cualquier sistema se puede adaptar cualquier juego. Incluso creo que ese port podría aportar cosas de las que el extenso catálogo de SNES carezca. Simplemente, se dowgradea o reprograma el juego original hasta dónde sea posible en SNES, lo mejor posible.

Sin embargo, ¿Podría SNES haber dado a luz a la saga Metal Slug, aun siendo una versión al nivel de la capacidad de SNES? Imposible, porque los creadores del juego necesitaron una maquina tan potente como MVS/AES para concebir la formula y detalles de esa saga. Esos detalles de las animaciones son muestra de lo agusto que trabajaron con el sistema.

* 01 feb 2019 17:49

Enlace permanente

Si nos ponemos a revisar todos los juegos, para eliminar ese tipo de detalles "innecesarios", como si fuéramos bots de Skynet o de Matrix, el panorama genérico que íbamos a dejar en los catálogos sería bonico.

Pues si, acabarían todos los juegos con graficos esquematicos tipo Atari 2600 o peor xDDD
O, ya siendo aun más radicales, serían todo aventuras de texto, con montones de coordenadas y datos de estado para informarnos de dónde están las cosas. Total, para qué gastar memoria en inútiles graficos.

* 01 feb 2019 18:02

Enlace permanente

Pues si, acabarían todos los juegos con graficos esquematicos tipo Atari 2600 o peor xDDD
O, ya siendo aun más radicales, serían todo aventuras de texto, con montones de coordenadas y datos de estado para informarnos de dónde están las cosas. Total, para qué gastar memoria en inútiles graficos.

A eso se le llama "Reductio ad absurdum" y es una falacia muy fea a mi parecer.

No hace falta irse al extremo, solo digo que aveces se les dan a los gráficos mas importancia de la que tienen, ahora que si tu me dices que Metal Slug es un juego divertido porque tiene buenos gráficos y deja de ser divertido si no los tiene, entonces me cayo.

Y para que veas que no eres el único que puede hacer "Reductio ad absurdum" ahí va la mia, no entiendo para que las compañías se molestan en pulir la jugabilidad, en hacer juegos retantes y en poner modos multijugador, si al final lo único que tiene que hacer es poner unos bonitos gráficos que la gente se contenta con eso, jugarían con una patata mientras tenga buenos gráficos

* 01 feb 2019 18:12

Enlace permanente

En lo que no estamos de acuerdo es en que no pasa nada por mutilar características de Metal Slug, simplemente porque SNES necesite un montón de recortes y más para mover una versión adaptada del juego; claro que importan, y se debe considerar a todas luces "downgrade", aunque haya que asumirlas.

Metal Slug Advance es uno de los mejores títulos de GBA, siendo una versión dowgradeada gráficamente de los juegos de Neo-Geo. Al juego le añadieron profundidad jugable, pero para compensar otras perdidas. Perdidas no solo "estéticas" (prefiero decir artísticas), sino también jugables.

La ambientación y apariencia artística son muy importantes en los juegos, porque eso logra que te apetezca más o menos jugarlos. La calidad artística de Metal Slug va más allá de la potencia gráfica. Al menos cuando yo lo vi por primera vez, vi algo que jamas había visto, pero es que el sistema que lo movía sí que estaba harto de verlo en arcades.

01 feb 2019 18:16

Enlace permanente

Hay juegos que soportan mejor que otros los downgrades gráficos. Me ha gustado un método que he visto esta semana para "Atarizar" juegos de NES. Algunos hasta viendo pixeles como puños siguen pareciendo divertidos.

* 01 feb 2019 18:22

Enlace permanente

Sexy MotherFucker está baneado del subforo por "faltas de respeto"

@radorn yo no he dicho que sean "vramdependientes" cómo por ejemplo una PlayStation o Saturn, de hecho he mencionado su ancho de banda por frame en el que transfieren datos continuamente desde la rom. Lo que he dicho es que ese ancho de banda es muy escaso (6kb y pico SNES, y 7 y pico MD), por lo que las tandas de información que pueden traer es bastante limitada, y debido a esto esto tienen que exprimir sus diminutas memorias repitiendo y espejando tiles de fondos/sprites fijos de la vram cómo si no hubiese un mañana, y el resto volcándolo cómo puedan desde el cartucho.

La Neo Geo en cambio puede leer directamente las ROMS gráficas del cartucho cómo si fuese una vram más, al igual que las de sonido ADPCM, aunque lógicamente no puede escribir en ellas. Luego aparte tiene una vram muy flexible, OTRA memoria exclusiva para las paletas, ROM de serie en los cartuchos para el fix layer (marcadores), para los sprites con zoom, etc.

En contraposición a esto SNES y MD sólo tienen su vram y lo que puedan transportar desde el cartucho a ésta en cada pantallazo.

* 01 feb 2019 18:45

Enlace permanente

@Oystein Aarseth A ver, obviamente estoy exagerando, y, viendo que no quedó claro antes, a pesar del absurdo y mis propias risas, lo digo ahora.

No obstante, como ya dije antes (aunque nadie parece haberle prestado atención), uno de los elementos definitorios de MS es la cantidad de cosas que concurren en pantalla todo el tiempo, con gran fluidez la mayoría del mismo, y el gran detalle de graficos y animaciones, con explosiones masivas y metralla volando por todos lados mientras montones de enemigos pululan por el escenario y asaltan al jugador, vehiculos y mechas por todas partes... en fin.
No solo es que la vistosidad y la fluidez de todo ello sean un caramelito para los ojos, es que con todo eso interactuas tambien.
Se puede hacer un juego con licencia Metal Slug en SNES y MD, si, pero la experiencia jugable va a tener importantes diferencias, no solo la experiencia audivisual, incluso si nos empeñamos en separarlas, lo cual creo que es un error.

Mi reduccion al absurdo será una falacia, pero el hecho sigue siendo que un Metal Slug en los sistemas domésticos populares contemporáneos hubiese sido bastante diferente al original de NEO-GEO, incluso si ignoramos la experiencia audivisual. A nivel jugable no serían lo mismo, e incluso la experiencia audivisual impondría una actitud diferente en el juego.
Por ejemplo, igual yo soy muy parado, pero, los Metal Slug siempre se me han dado mal en parte porque me abruma todo el caos que se genera a mi al rededor con explosiones, tiros volando, cosas pululando, proyectiles y granadas haciendo parabolas, mientras un monton de energúmenos pululan dando saltitos por ahí... Todo eso genera una atmósfera y es informacion sensorial que el jugador tiene que manejar y provoca un estado psicologico y anímico en él. A mi, por desgracia, me despista bastante, aunque seguro que si me entreno me adaptaría a ello.

Lo que intento decir es que la presentacion audivisual no siempre es un elemento superficial y reemplazable, si no que incluso afecta a la jugabilidad y Metal Slug y otros titulos de iRem que comparten estas características, son un gran ejemplo de ello. Es cierto que, en muchos juegos, un "downgrade" grafico no afecta a la jugabilidad, pero creo que hay excepciones, y esta es una.

LLegados a este punto, incluso te animo a re-evaluar si mi reduccion al absurdo es simple y llanamente una falacia o si, por la contra, ilustra, mediante la exageracion, algo que si es real.

@Sexy MotherFucker
Bueno, basicamente sigues diciendo lo mismo que antes. Resumiendo con las nuevas correcciones: Que las PPUs de estas dos (o como se llame en MD) no leen directamente la ROM a la hora de dibujar la pantalla, si no que la VRAM tiene que hacer las veces de caché de gráficos en cada frame.
Vuelvo a preguntar si estás seguro de eso, porque contradices todas las nociones que yo tenía hasta ahora.
Desde luego en NES los graficos se usan directamente desde ROM, desde el bloque CHR, concretamente, y yo tenía entendido que, en las 16bit de cartucho la tecnica era basicamente igual. Esto de transferir a VRAM los graficos en si nunca lo había oído antes y, para serte sincero, me chirria estrepitosamente.

* 01 feb 2019 19:21

1 valoración positiva

Enlace permanente

Sexy MotherFucker está baneado del subforo por "faltas de respeto"

@radorn ¡es que precisamente la NES es la única consola que se asemeja a la Neo Geo en ese aspecto! Fíjate por dónde lo has clavado.

Pc-Engine, SNES y MD en cambio usan mecanismos DMA con todas las ventajas y desventajas que ello aporta, estando mucho más limitadas en cuanto accesos directos y anchos de banda.

Seguro no; lo siguiente, es junto al tamaño de las roms la mayor ventaja de Neo Geo y muchos ARCADES del momento respecto a las 16 bits:

El LPSC al contrario de otros sistemas puede leer directamente los patrones/sprites directamente de la ROM de los cartuchos y operar desde ellos

https://disruptiveludens.wordpress.com/ ... o-neo-geo/

Léete el report, lo explica todo bastante bien, aunque se deja detalles

* 01 feb 2019 19:34

Enlace permanente

@Sexy MotherFucker Pues sorprendido me dejas... Aun sin leer el enlace, que en algun momento lo haré (ya me has pasado varios enlaces de ese autor, creo), te creo. Además, una vez establecido esto, cobran sentido otros datos que había oido sobre el conteo de patillas en el bus de cartucho de las 16bit comparado con NES, que son muchas menos, como un mecanismo de simplificacion y abaratamiento del hardware.
Con N64 ya fueron un paso mas lejos, usando el cartucho como almacenamiento secundario para todas las tareas de alto rendimiento (graficos y logica del juego, dejando el acceso directo al cartucho para samples de sonido y datos de animacion, basicamente), y, por supuesto, los sistemas de CD solo usan el CD directamente para streaming de audio y video.

Aclarado el tema, pues, y yo agradecido por la lección.

Los 8bit de SEGA, MasterSystem, GameGear y derivados, son tan directos como NES o tiran mas hacia SNES y MD tambien?

02 feb 2019 00:02

Enlace permanente

@magno , aprovechando te hago una preguntita. ¿La detección de colisiones es vía hard? ¿La hace la CPU o la PPU? Creo recordar que en los micros de 8 bits las colisiones las soportaban los chips de video dejando a las cpus libres. Pero vamos te pregunto desde el desconocimiento.

No conozco ninguna PPU que haga detección de colisiones, ya que las PPUs suelen trabajar con las tiles de la imagen y aplican efectos sobre ellas, pero no saben si dentro de esa tile, en el pixel (4,6) por ejemplo empieza un sprite que colisiona con una pared que está en la tile adyacente. Es decir, que la PPU trabaja con píxeles/tiles y no con lo que representan esas tiles/píxeles, ya sean personajes o escenarios.
La colisión siempre la detecta la CPU, que es la que procesa unos metadatos que van asociados a los sprites: tamaño del sprite, dirección donde mira, altura a la que está desde el suelo, etc.
Y se hace por software, no por hardware, ya que si se hiciera por hardware tendría que ser una unidad dedicada a la que le pasaras esos metadatos y calculara la colisión; esos metadatos cambian según el tipo de juego, por lo que no podría ponerse como un hardware que se usara de forma genérica.

El chip de vídeo del C64 (VIC-II) además de scroll por hard, sprites, etc. también proporciona detección de colisiones y juraría, que alguien me corrija si me equivoco por que hablo de memoria de hace muuuchos años, que éstas se podían programar incluso en basic.
https://www.c64-wiki.com/wiki/VIC#VIC-II
https://www.c64-wiki.com/wiki/Sprite#Collision_detection

Por eso te preguntaba. De nuevo hablo del desconocimiento, pero no sé si tiene sentido que puedas dibujar el sprite pero no sepas si hay colisiones y más cuando tienes decenas o centenas de éstos elementos en pantalla.

02 feb 2019 03:16

Enlace permanente

@Señor Ventura
Lo primero de todo es que nadie te está insultando, sólo te estoy explicando en qué te equivocas. Y aunque le intentes dar vueltas semánticamente, lo que exponías no es cierto; te respondo a continuación:

No he dicho que tu me estés insultando, sino que otros usuarios usan tus correciones para descalificarme a mi, cuando comúnmente se deben mas a no llegar a un entendimiento, que a que no esté viendo bien las cosas, o a que me equivoque tanto, tanto, TANTO.

Mira los votos positivos que has recibido. Están encantados.

Pero me temo que en esta ocasión no se me ha entendido, aunque eso dará igual, y para esas personas será otra equivocación mas que será usado para lo de siempre. Por eso decía lo que decía.

La OAM que se ve en el vídeo existe, no tiene nada de incierta.

La OAM no es lo que se ve en el video por mucho que la pestaña de la ventana diga eso: lo que se ve en el video es la parte de VRAM que almacena las tiles de los sprites apuntados desde la OAM. La OAM es una tabla de 544 bytes con los primeros 512 bytes con los datos para los 128 sprites (4 bytes por sprite) y los 32 bytes siguientes (256 bits) son los 2 bits extras para la posición horizontal del sprite y el otro para cambiar la página de VRAM donde están las tiles del spruite. Por tanto, la OAM son 544 bytes donde no hay tiles, por lo que estás viendo en ese video no es la OAM, es la VRAM (que es el único sitio posible donde se alamacenan las tiles que se ven en pantalla, ya sean de BGs o de sprites)

Lo se, se que en la tabla OAM no hay tiles, es una tabla de atributos para los sprites.

La tabla de atributos de los sprites consiste en establecer una coordenada X y una coordenada Y en los dos primeros Bytes, número de tile en el segundo Byte, dos bits del cuarto Byte para flipear el sprite en dos coordenadas (bit 7 Y, bit 8 X), los bits 4 y 5 para la prioridad, bits 1 2 y 3 para el número de la paleta. Los 32 Bytes adicionales destinan 2 bits por sprite, que definen su tamaño, y hasta donde tenía entendido, su coordenada X.

Un poco caótico, pero el concepto ya lo tenía claro (repito, tengo claro el concepto de tabla OAM, no que cada bit de los atributos sirvan justo para lo que menciono).

¿A modo de lienzo? Dices que se dispone a modo de lienzo como en todos los juegos de SNES... por tanto no hay ninguna "técnica" ahí, es como funciona el sistema. Lo que no es de ninguna manera es una máscara; supongo que no estás muy familiarizado con estos términos y los usas sin el debido conocimiento, pero para nada es una máscara, más bien es algo parecido a un canal alfa, donde un color se usa para hacer la transparencia.

No, en todos los juegos de snes varias decenas de sprites no simula estar representando varios centenares de sprites.

Si observas la imagen de la presentación del super mario world 2, y no sus sprites desde un debugger, podrás notar el número de objetos que están siendo calculados POR EL SUPER FX.

Si ese número de objetos tuviesen que ser representados con los 128 slots para sprites de snes, no serían suficientes porque te pasarías del límite por scanline, y seguramente porque necesitarías mas de 128 sprites.

Sin embargo, usando los 40 sprites que la snes destina para que el super fx cambie su información gráfica desde la ram del cartucho (esto es, renderizar la imagen, dividirla en tiles, y mandarla a la VRAM), podrás visualizar todo lo que se renderice desde el mismo.


En definitiva, ahí hay 40 sprites, pero hay muchos mas objetos que 40.

No se entiende perfectamente lo que quieres decir, porque leyendo tus palabras das una idea totalmente errónea de lo que realmente ocurre en la SNES; quizá sí sepas cómo va a SNES, pero entonces tu problema es que lo explicas mal.
Ya te lo dije anteriormente: no te metas en estos barrizales y nadie usará tus propios comentarios en tu contra.

Permíteme la licencia de aludir a la acepción que en un foro no especializado en programación, se le pueda dar a la palabra "máscara".

Creo que mas allá de la jerga de programación, se puede entender a que me refería, y mas con un vídeo que contextualiza lo que está pasando.

Se me puede entender, creo yo, vamos.

Claro, esto que dices sí es verdad, así es como funciona el SuperFX, nada de máscaras ni técnicas raras que solucionen el problema de sprites por scanline.

No solucionas el problema del límite de sprites total, y por scanline, sino que lo simulas.

Pero si todos esos objetos tuvieran que representarse usando un sprite por cada uno de ellos, si te estarías encontrando con esa limitación, por eso al usar esta forma de representar la escena, te saltas ese límite. No de una forma literal, sino que te evitas el tener que toparte con ese límite.

No he pretendido decir otra cosa en todo este tiempo.

Exigiría una sincronización mas difícil de llevar a cabo que hacerlo todo directamente con un procesador de apoyo.

Por eso dije que lo suyo sería hacerlo todo desde ahí. En el caso concreto del super mario world 2, al no haber scroll, la snes puede pintar el fondo ella sola, y lo que hay dentro de los sprites son calculados por el super fx para luefgo ser enviados a la vram.

No dijiste eso ni de coña; en este comentario dices que "no hay scroll" y yo te estaba respondiendo a éste en el que dices qué pasaría si hubiera scroll:

Y la gracia de hacerlo con sprites, es que a la snes le dejas libre los planos para que su sistema gráfico pueda hacer scroll con uno o varios planos,

Si he dicho que lo lógico sería hacerlo todo (sprites y planos) desde el procesador de apoyo:

"aunque lo lógico es que el procesador que calcula la posición de los objetos también se encargue de dibujar unos planos".
viewtopic.php?p=1747248599

Me refiero que si haces que cada elemento movil de esa escena sea representada por los sprites que correspondan, te pasarías de tasa de relleno, y no habría OAM suficiente.

Maaaaaaaadre mía, qué cacao llevas......... ¡que la OAM no lleva tiles! A ver, la "tasa de relleno" de la que tanto hablas es la capacidad de enviar píxeles a pantalla, que en el caso de SNES es fija: la SNES está diseñada para ser suficientemente capaz de generar la resolución de 256x240 píxeles de pantalla, es decir, que el fill-rate se deriva del reloj de píxel y la resolución, ambas fijas; lo que supongo que quieres decir es la tasa de envío de tiles a VRAM, que no es el fill rate, pero en este caso, esa tasa de envío de tiles a VRAM no tiene que ver con la OAM porque ésta no lleva tiles.

No llevo ningún cacao. La snes pone 40 sprites, y el super fx pone muchísimos mas objetos en esa pantalla.

Si intentas que la snes dibuje cada objeto usando sprites, llegas al límite antes de dibujarlo todo. Ciertamente es así.

Te la saltas porque estás evitando que sea representado de la forma ordinaria, y así si que no hay recursos.

No es cierto, no te la saltas de ninguna manera porque esa imagen del SMW2 es una imagen como cualquier otra hecha con sprites y sigue teniendo la misma limitación, que ya te he comentado que en el video se ve claramente como no ocurre el error: hay 32 tiles en un scanline, por tanto, no hay problema.

Desde el mimso momento en que le evitas a la snes tener que usar un sprite para cada uno de todos esos objetos, te estás saltando su limitación. No es que consigas poner mas sprites de los que soporta la snes. Eso no es lo que está pasando.

¿Cuantos elementos móviles hay en la pantalla de presentación del super mario world que se ve en el vídeo? (lo que se ve dentro de cada sprite).

Malinterpretas lo que estás viendo en ese video totalmente: los "elementos móviles" son tiles que se están actualizando en VRAM, mientras que los sprites son estáticos, es decir, la tabla OAM está configurada para que aparezcan en pantalla ciertos objetos de 16x16 píxeles y hace un "layout" con esos sprites, poniéndolos uno al lado de otro de la manera adecuada para la imagen. Luego, el SuperFX está generando la imagen y envía a VRAM las tiles que se pintarán en esas posiciones de pantalla. No hay ningún misterio más, es lo que se hace en TODOS los juegos de SNES.

Los elementos móviles son tiles que se están actualizando en la VRAM, efectivamente, nunca he dicho lo contrario, de hecho eso mismo lo he tenido que mencionar bastantes veces a lo largo de este hilo, y de otros muchos hilos mas, porque es lo que entiendo de como funciona eso.

Por otro lado, querrás decir que eso sucede en todos los juegos de snes que usan el super fx, ¿no?.

Pues estaría bien que empezaras a entender de lo que hablas, por que en ese video no explica nada de lo que has dicho en los otros posts.

Entender, y querer ser entendido. Seamos justos.

* 02 feb 2019 07:41

Enlace permanente

Sexy MotherFucker está baneado del subforo por "faltas de respeto"

Mira los votos positivos que has recibido. Están encantados.

En mi caso yo estoy encantado de que exista gente tan ducha en la materia técnica que saque tiempo y ganas de compartir su conocimiento en EOL, por eso al igual que con wwwendigo o kusfo trato de ser cortés y agradecido. Entiendo que en cierto momento yo no tuve un comportamiento muy afortunado en el subforo contigo, pero vamos te aseguro que eso para mí forma parte del pasado cómo una mala racha personal que tuve.

Y ahora, de nuevo, voy a leerme vuestros tochos a ver qué no he entendido xD

02 feb 2019 13:22

Enlace permanente

A mí también me parece bastante triste que algunos aprovechen para meterse con Ventura cuando magno le corrige en algunas cosas, máxime cuando la mayoría no tienen ni una décima parte de conocimiento en programación.

En vez de hacer leña del árbol caído os animo a que le contraargumentéis con conocimiento de causa.

02 feb 2019 13:42

Enlace permanente

@shutupandsmile

Quizás algunos le tengan ganas de los MD VS Snes, más que nada. No digo que sea en todos los casos.

Yo ni voy a hacerle de abogado defensor ni a juzgarlo, aunque quiera o no me pueda fijar en ciertas actitudes, máxime cuando es un usuario habitual del foro.

Es obvio que es un forero que domina sobre programacion y por mi parte, y dado que soy un cero a la izquierda en el tema, me da gusto leer sus aportaciones aunque muchas veces no entienda ni la cuarta parte dada mi ignorancia jeje. Pero también es obvio que a veces se flipa un poco (dicho con todo el respeto) quizás por su amor a ciertos sistemas y eso le pierde un poco.

* 02 feb 2019 13:56

Enlace permanente

Mira los votos positivos que has recibido. Están encantados.

En mi caso yo estoy encantado de que exista gente tan ducha en la materia técnica que saque tiempo y ganas de compartir su conocimiento en EOL, por eso al igual que con wwwendigo o kusfo trato de ser cortés y agradecido. Entiendo que en cierto momento yo no tuve un comportamiento muy afortunado en el subforo contigo, pero vamos te aseguro que eso para mí forma parte del pasado cómo una mala racha personal que tuve.

Y ahora, de nuevo, voy a leerme vuestros tochos a ver qué no he entendido xD

No me refería a ti. Cuando lo dije había 4 votos positivos. Ahora deben haber como 15 o así xD

Y tampoco dije que tu me hubieras insultado tampoco, me refería a como se usan estas cosas por el foro para atacar a lo personal. En esta ocasión no me he equivocado en nada, ni tampoco estoy dejando de comprender como funciona la snes en este caso concreto, salvo porque no hay un enmascaramiento de sprites, pero si que se puede entender que la definición de "máscara" va en el sentido de que se usan 40 sprites como una pequeña pantalla de cine.

Es obvio que es un forero que domina sobre programacion

Solo quiero decir que no domino nada sobre programación, ni estoy haciendo nada ahora mismo.

Soy un usuario normal que se apunta algunas cosas que va leyendo por ahí, y debato y hablo de ellas porque vengo aquí a desconectar y soñar con mis "y que hubiera pasado si", de vez en cuando.

02 feb 2019 14:01

1 valoración positiva

Enlace permanente

A mí también me parece bastante triste que algunos aprovechen para meterse con Ventura cuando magno le corrige en algunas cosas, máxime cuando la mayoría no tienen ni una décima parte de conocimiento en programación.

En vez de hacer leña del árbol caído os animo a que le contraargumentéis con conocimiento de causa.

Yo lo qué no entiendo es porque se lo lleva a lo personal, la verdad. Es una tendencia en este foro que se da a menudo, no se si por los usuarios que se toman las cosas a la tremenda o por otra cosa.

Diferir, corregir, o decirle a una persona que esta equivocada en algo o ha dicho una burrada sobre una cosa concreta, o que no sabe como funciona X, no es insultarla, es simplemente decir lo que se piensa.

* 02 feb 2019 14:17

2 valoraciones positivas

Enlace permanente

Si observas la imagen de la presentación del super mario world 2, y no sus sprites desde un debugger, podrás notar el número de objetos que están siendo calculados POR EL SUPER FX.

Si ese número de objetos tuviesen que ser representados con los 128 slots para sprites de snes, no serían suficientes porque te pasarías del límite por scanline, y seguramente porque necesitarías mas de 128 sprites.

Sin embargo, usando los 40 sprites que la snes destina para que el super fx cambie su información gráfica desde la ram del cartucho (esto es, renderizar la imagen, dividirla en tiles, y mandarla a la VRAM), podrás visualizar todo lo que se renderice desde el mismo.

En definitiva, ahí hay 40 sprites, pero hay muchos mas objetos que 40.

No te voy a contestar todo el tocho que has puesto porque creo que he entendido ya dónde te equivocas, y sí, llevas un cacao considerable...
Me ha parecido entender que CREES que el SuperFX calcula cada elemento de esa imagen del SMW2 por separado: los cuatro montículos de enmedio de la isla, la casa, etc... y que los va rotando individualmente, los compone en una imagen y luego la envía a VRAM. ¿Eso eso lo que crees? Por eso dices que hay más de 40 objetos.
No estoy seguro en el caso concreto de esa parte del SMW2, pero hay un 99% de posibilidades de que eso no sea como dices. ¿No te parece muchísimo más lógico que sea una imagen pre-renderizada y almacenada en ROM en cada una de las posiciones rotadas cierto ángulo? Piensa el esfuerzo de alamacenar cada elemento de esa escena por separado, rotarlo (lo cual implica almacenarlo de todas formas en ROM en cada uno de los frames de rotación), para luego componerlo todo haciendo blitting y enviarlo a VRAM.

Ejecutando paso a paso el SuperFX en esa zona, parece que está haciendo lo que digo, no tiene pinta de estar cogiendo elementos individuales para componer la imagen.

Y aún así, aunque tuvieras razón... ¿qué tiene que ver esto con una "máscara de tiles" de la que hablabas al principio? ¿Y no te das cuenta de que esto no supera la limitación de sprites por pantalla de la SNES? Es cierto que si fuera como dices, el SuperFX podría estar calculando cada "enemigo" (por poner un ejemplo de sprite) como tiles sueltas sin estar restringido a los 128 de la SNES, pero luego es la PPU la que tendría que mostrar ese enemigo como un sprite por pantalla, por lo que sigue limitando el número de sprites de la PPU. Y si ese "enemigo" calculado por el SuperFX lo convirtieras a una tile para ponerlo en un BGx, tendrías el problema del scroll que te decía antes.

En esta ocasión no me he equivocado en nada, ni tampoco estoy dejando de comprender como funciona la snes en este caso concreto, salvo porque no hay un enmascaramiento de sprites, pero si que se puede entender que la definición de "máscara" va en el sentido de que se usan 40 sprites como una pequeña pantalla de cine.

Sí que te has equivocado y no quieres reconocerlo, eso es un grave problema.

02 feb 2019 14:29

Enlace permanente

@Señor Ventura

No se si programas o no. Quería decir que dominas bastante el tema aunque sea desde un punto de vista teórico. Y sobre todo desde lo profano de mi situación desde luego es digno de admiración.

02 feb 2019 15:30

3 valoraciones positivas

Enlace permanente

@Señor Ventura

No se si programas o no. Quería decir que dominas bastante el tema aunque sea desde un punto de vista teórico. Y sobre todo desde lo profano de mi situación desde luego es digno de admiración.

No te engañes, la realidad es que solo tiene un montón de datos memorizados que repite como un papagayo, pero que no entiende realmente, y que usa en ciertos hilos defender ideas absurdas. Fijate en como magno lo esta desmontando constantemente.

* 02 feb 2019 15:49

1 valoración positiva

Enlace permanente

No te engañes, la realidad es que solo tiene un montón de datos memorizados que repite como un papagayo, pero que no entiende realmente, y que usa en ciertos hilos defender ideas absurdas. Fijate en como magno lo esta desmontando constantemente.

No, constatadamente no es la realidad que repita datos memorizados sin entender lo que significan.

Por otro lado, constatadamente si que atacais sin tener ni idea de que cosas rebatís, y pasais de señalar a alguien con la intención de ridiculizarle, a quedar en evidencia vosotros mismos, para empezar por vuestro comportamiento de niño de 12 años, y para terminar por una evidente falta de entendimiento que compensais con ataques al hombre de paja.

Atacarme a mi no desacredita muchas de las cosas que digo.

@Señor Ventura

No se si programas o no. Quería decir que dominas bastante el tema aunque sea desde un punto de vista teórico. Y sobre todo desde lo profano de mi situación desde luego es digno de admiración.

Yo también soy un profano, lo que pasa es que tengo bastante curiosidad.