¿Paprium en Snes?

titorino escribió:@emerald golvellius si nada que ver en planteamiento, esta chulo pero el out one es mucho out zone.
En la época me marcó, sobre todo la ost.
Mi padre llegó a tener esa placa en propiedad y uff que recuerdos.
Artísticamente una maravilla como todo lo que paría toaplan.

Aun conservo esa PCB,con el tiempo me fui quitando muchas de encima,pero Out Zone y otras verticales como Last Duel y Sky Soldiers las guardo,me gustan mucho ese tipo de juegos.

tu padre sabia...

emerald golvellius escribió:@Señor Ventura Pregunta sin semilla de respuesta,de verdad.

si tienes los medios los conocimientos y el deseo de llevar Out Zone de Toaplan a una Consola y la cosa esta entre MD y SNES ¿cual?

ves ese tipo de colores en SNES?,te imaginas ese juego en SNES?,es algo que aunque he visto de todo en SNES no se por que me cuesta imaginarme ese tipo de juegos en ella,quizas sea por que Megadrive tiene Conversiones del estilo?,opinion?

En teoría la MD va más suelta en los shooters horizontales por el tema de la resolución. Pero no son pocos los juegos verticales en la consola con óptimos resultados como los Aleste, Truxton, V-Five etc.

Uno que le le hubiera ido a medida a Snes es el Typhoon (A-Jax) que seguro que conoces como experto en shooter que eres y como amante de la X68k. Primero por ser vertical y luego por las partes de perspectiva trasera donde el modo 7 luciria en todo su esplendor.

gaditanomania escribió:
Uno que le le hubiera ido a medida a Snes es el Typhoon (A-Jax) que seguro que conoces como experto en shooter que eres y como amante de la X68k. Primero por ser vertical y luego por las partes de perspectiva trasera donde el modo 7 luciria en todo su esplendor.

Tambien el Trigon tambien conocido como Lightning Fighters, de Konami.

@gaditanomania @chinitosoccer
El A-Jax es bueno,pero el Trigon es increible,a mi ese juego me parece una pasada,aunque se me hizo siempre dificilisimo y larguisimo.
creo que es un juego muy enfocado al 2 players para poder utilizar aquellas armas como ampliadas que se colocaban entre los 2 jugadores.

la Version del Sharp de A-jax les quedo casi identica "a mis ojos al menos",ese juego lo jugue por primera vez en ZX Spectrum,conservaron los Stage del Avion,ademas era el Stage 1 cambiaron el Orden de las pantallas,imaginate todo color azul y sin musica.

Super aleste, super swiv, y aero fighters, son mucho mejores que esos.

Ponte los cascos y aguanta 10 segundos.

https://youtu.be/EdU-ncKO3xo?t=335

chinitosoccer escribió:

gaditanomania escribió:
Uno que le le hubiera ido a medida a Snes es el Typhoon (A-Jax) que seguro que conoces como experto en shooter que eres y como amante de la X68k. Primero por ser vertical y luego por las partes de perspectiva trasera donde el modo 7 luciria en todo su esplendor.

Tambien el Trigon tambien conocido como Lightning Fighters, de Konami.

Ese o no lo conozco o no lo recuerdo por ese nombre. Le daré un tiento

@emerald golvellius

Me pones los dientes más largos aun con el Trigon. Y la curiosidad con el port del A-Jax de X68k, a ver qué tal lo portaron.

.

Syuk escribió:Tengo entendido que los 128 sprites en pantalla es únicamente con el uso de sprites pequeños de 8x8 en resoluciones de 256x224. Cuadros mayores limitarían incluso a un máximo de 57 y están limitados al uso de 2 tamaños simultáneos en pantalla.

No es que esté limitado a 57 sprites, es que basta con 57 sprites para llenar la pantalla. La connotación que le das es tan negativa, que no es cierto. El ppu1 siempre puede gestionar 128 sprites.

A 64x64 pixels llenas la pantalla con 16 sprites, pero no es que se limite su capacidad a 16 sprites, es que bastan 16 sprites para llenar la pantalla.

La ventaja de esto es la versatilidad. En juegos de naves, poder poner 100 balas en pantalla lo puedes hacer con sprites pequeños, los brawlers los puedes hacer con sprites mas grandes.

O también un pang lleno de bolitas. La forma en que trabaja la snes es una ventaja para esta clase de juegos. Nunca hay aspectos malos.

Syuk escribió:También leí que de los 32 sprites por línea tenía la limitación de mostrar hasta un máximo de 273 píxeles (que por los tamaños vistos en la foto podrían superar el marco idílico de la imagen) mientras que en MD son 20 (de tamaño MUY variable) pero pudiendo mostrar por línea hasta 320 píxeles.

Son 256 pixels por scanline, al menos haciendo las cosas por las buenas.

En megadrive son 10 sprites de 32 pixels de ancho, 20 sprites de 16 pixels de ancho, y así sucesivamente.

Syuk escribió:Lo que requeriría meterle bastante mano para adaptar el juego a SNES y hacer una versión dedicada a su arquitectura. Podríamos sacar un juego cromáticamente más rico, se podría hacer un scaling por hardware de forma más sencilla que la de software creada por WM, efectos FX más nítidos, en general los sprites parecerían más grandes por la resolución, pero la realidad es que son del mismo tamaño pero mostrando muchísima menos pantalla, reducción de número de enemigos en pantalla... Vamos, las ventajas y desventajas de cada una de las consolas.

No necesariamente tendrías que reducir el número de enemigos en pantalla. Basta con que no coincidan todos en línea, y la diferencia en todo caso se reduciría seguramente a un enemigo menos, no a varios (aunque ya digo que si permanece en otra zona de la pantalla no tendrían por qué haber menos enemigos)... a cambio puedes poner unos gráficos mas coloridos, e incluso salvar mas ancho de banda.

Syuk escribió:PD: he jugado a ese hackrom de FF y ese gif plantea un escenario idílico en el que no alcanza por línea el máximo de SNES, pero el resto del juego es una auténtica fiesta de flickering.

Los final fight desperdician muchos sprites. Parpadea porque supera los 32 tiles de sprites por línea, pero se puede dibujar lo mismo con alrededor de solo 20 sprites, y quedarte espacio para meter incluso mas enemigos en pantalla.

No sería idílico, sería optimización. Paprium le ha puesto mucho cuidado a ese detalle, por eso pasa menos.

.

Syuk escribió:Aquí está el tema, que hay que tener ese cuidado concreto para evitar el flickering, pero al ser enemigos que suben y bajan constantemente o cambias la IA para que se aparten de la línea cuando hay una cantidad grande de sprites (cosa nada práctica) o reduces significativamente la cantidad de ellos cambiando así la jugabilidad.

¿Por qué no es práctico redistribuir la posición de los enemigos en pantalla?. Cuanto mas sofisticada es la IA, mas opta por no embarullar todos los enemigos en una misma posición, y en su defecto rodea al jugador descongestionando la sobrecarga de sprites por scanline.

¿Que limitaciones te obligan a reducir signitificativamente el número de enemigos en pantalla?.

Syuk escribió:Mirando la imagen de cuadros de sprites que has puesto, también observó que hay sprites en movimiento sin marcar (abajo a la derecha) de los items de aumento de vida y mejora. Tan sólo esos dos ya mostrarían dos cuadros más de 8x8 extra a procesar.

¿Que implican esos dos sprites de 8x8 adicionales?.

Syuk escribió:Habría que tener en cuenta también las poses de las acciones de cada Sprite, tranquilamente un puñetazo hacia adelante puede añadir por línea hasta 2 cuadros de 8x8 o 3-4 más con un golpe de cadena o "tubo de hierro" al sprite del personaje. En SNES al sólo poder mostrar 2 tamaños de sprites ha de procesar mayor cantidad de ellos mientras que en MD puedes colocar más cuadros de tamaño variable para ahorrar memoria teniendo mayor margen de optimización sin generar tanto proceso. Con una caja de 16x8 (el del puñetazo hacia adelante) ya tendría menor carga y mayor ahorro en memoria. Si no quieres sufrir un flickering continuo has de sacrificar bastante cosas en pantalla. Normalmente en SNES se sacrifica el número de sprites por acción para aliviar al procesador principal de carga, cosa que afecta a la fluidez de movimiento (véase comparativas por sprite de MK, Earthworm Jim, Tinhead...)

¿De que carga hay que aliviar al procesador?.

¿Por qué un sprite de 16x8 tiene menos carga para el procesador?

¿Que es procesar sprites?.

¿Por qué megadrive puede colocar mas sprites pequeños para dibujar esos tubos de hierro o cadenas que snes?.

Syuk escribió:SNES a 256x224 en la práctica dista mucho de poder mover 128 sprites en pantalla, incluso 80.

128 sprites en pantalla lo ponen muchos juegos, tanto en unos pocos objetos grandes a base de muchos sprites, como en muchos objetos pequeños a base de pocos sprites.

He visto una demo que pone mas de 100 bañas en pantalla, mas las naves. Cada bala es un sprite y un objeto, que es independiente de todos los demás obetos. 128 en total.

Syuk escribió:Necesitaría que no hubiera un scroll en movimiento (y aún menos que sea parallax) y sprites pequeños de 8x8 y un máximo de 16x16 para tener variedad de tamaño y no derrochar alegremente los huecos en memoria.

¿Que son los huecos en memoria?.

¿No es posible que haya scroll en movimiento para mostrar muchos sprites?.

Syuk escribió:Un buen ejemplo del uso de esta cantidad de sprites en movimiento sería el SmashTV de SNES. Pero le sigue faltando variedad de tamaño para ser realmente eficiente en shutmap, tamaños como 8x16, 16x24, 16x32, 24x32... Simultáneamente.

¿Ves balas muy grandes en los shoot em ups?. Precisamente poder poner 32 protectiles en línea en lugar de 20, es una ventaja.

Y no son imprescindibles tamaños de sprites raros para naves normales cuando puedes poner hasta 128, y eso de que la cpu no puede hacerlo es una milonga.

Syuk escribió:Pero una resolución a 256x224 deja mucho que desear a los shoot em ups donde es necesario mayor visión de pantalla, scroll parallax y proceso continuo de cajas de impacto y de sprites de tamaños diferentes.

¿Seguro?, los shoot em ups verticales son mas óptimos a 256x224 que a 320x224.

Además:
-La visión de pantalla para shoot em ups horizontales dependen de las proporciones del dibujo, no de la resolución.
-El scroll parallax no depende de la resolución, sino del sistema gráfico, el cual es mejor en snes.
-El proceso contínuo de detección de colisiones es peor para el rendimiento a mayor resolución, no a menor resolución.
-Los sprites de tamaños diferentes son mucho menos importante que poder poner muchos mas sprites en pantalla.

Syuk escribió:SNES sufre de ralentizaciones cuando llega el punto de cálculo por exceso de elementos en pantalla y mayor es este efecto en juegos que exijan scroll rápido.

¿Por qué un scroll rápido causa ralentizaciones?.

Syuk escribió:Por poner un ejemplo comparativo, hablaría de Thunder Force III vs Thunder Spirits, donde se ven claramente esas ralentizaciones con menor cantidad de sprites en pantalla y teniendo una resolución a lo ancho menor que hace que muchas veces no te de tiempo a reaccionar ante un proyectil que aparece en pantalla.

Mal ejemplo has ido a poner. Thunder spirits es un port de un juego para un sistema diferente, y además obligan al juego a que la cpu funcione al 65% de su velocidad.

Pregunta: ¿En que puntos del juego hay menos sprites en pantalla?. Lo que veo es el mismo flickering en ambas consolas por muchos que digas que en una pasa, y en la otra no.


Demasiado bien parada ha salido:

O que la Snes dibuja usando 128 sprites la Mega lo hace usando solo 70.

@Señor Ventura ¿Qué juegos así potentes conoces que usen la hi-rom?

EPSYLON EAGLE escribió:O que la Snes dibuja usando 128 sprites la Mega lo hace usando solo 70.

Lo que hace el batman returns y los final fight es incorrecto. No puedes comparar juegos que usan mal el dibujado con los sprites con los juegos que usan bien el dibujado con los sprites.


Con respecto a lo que pueden dibujar:
Sprites de 64 pixels de ancho: MD 0 y SN 4.
Sprites de 32 pixels de ancho: MD 10 y SN 8.
Sprites de 16 pixels de ancho: MD 20 y SN 16.
Sprites de 8 pixels de ancho: MD 20 y SN 32.


Prefiero la situación de snes, porque te permine llenar la pantalla usando menos tiles (preservando el ancho de banda), obtienes un beneficio cuando toca usar sprites de pequeño tamaño, puedes usar sprites enormes usando un único sprite, y tan solo pierde en campos intermedios, donde puede compensar la desventaja usando el excedente de sprites disponibles para dibujar mas fuera de los scanlines mas sobrecargados.

La ventaja de megadrive se traduce en que, por ejemplo en brawlers, la MD puede poner 7 objetos en línea, y la SN solo 6 (puede que incluso 8 a 6), pero puede poner mas personajes en pantalla si están bien distribuídos y si el diseño lo hace posible gracias a que realmente puede poner mas sprites, y además gana por goleada en el resto de situaciones.

Se echa de menos usar sprites rectangulares (aunque es posible ponerlos), pero con una planificación en el arte de los dibujos puedes no dejar huecos en los cuadrados, y no necesitar emplear sprites rectangulares. Por el mismo precio puedes hacer los gráficos aún mas grandes. Si te fijas en la tabla de atributos de los sprites del final fight 3, notarás como se desaprovechan, y como se desperdician... ¿consecuencia?= gasto de ancho de banda, parpadeos, y menos sprites disponibles. Todo esto es innecesario.

Super PadLand escribió:@Señor Ventura ¿Qué juegos así potentes conoces que usen la hi-rom?

No le va a dar lecciones a una megadrive, ni muchísimo menos, pero el rendering ranger, aunque aburrido, se exhibe muy bien, y totalmente libre de ralentizaciones (algo pocas veces visto en cualquier máquina de esa generación).

El super swiv rinde igual que en megadrive.

El super aleste satisface muchísimo comparándolo con los shoot em ups mas bestias, ¡y eso que lleva una rom a 2.68mhz!.

El gradius III exige mucho músculo por culpa de una mala programación, y a 3.58mhz pasa con nota.

El TMNT in time/hyperstone heist tiene un motor realmente bien pulido, que permite mas de una decena de IA's simultáneas tanto en snes como en megadrive.

El street racer no solo deja clara la potencia del PPU1, sino que la cpu se comporta muy bien calculando las coordenadas de nada menos que 28 objetos a 60fps.

El SOS pone 4 planos simultáneamente. Mas que potencia, es una curiosidad, porque pocas veces se hizo eso en todo el catálogo.

El art of fighting 2 abre una puerta muy interesante a un tipo de solución gráfica que es totalmente posible en snes... Dream Basketball Dunk & Hoop y super goal 2 también se mojan en lo mismo, y el resultado deja muy buen sabor de boca.

El nba give'n go es espectacular, pero sobre todo por la sensación de que con mas memoria puedes conseguir poner mas detalles en los gráficos, y con un SA-1 consigues los 60fps con la gorra, acercándote mucho al juego arcade con dos chorradas.


Lo que mas me sorprende de la snes, es como es posible que con un par de chorraditas puedes ofrecer cosas de placas muy superiores. Obviamente no es lo mismo, pero ahí está.

@Señor Ventura

(algo pocas veces visto en cualquier máquina de esa generación).

A 256x224.... La otras máquinas de esa generación, incluída la Pc-Engine, tienen contextos más díficiles para el género (también mejores configuraciones de CPU claro). De hecho la PCE para los verticales suele emplear ratios de 256x239 sin despeinarse.

Yo lo siento pero es que jamás voy a poder concederle mucho crédito o mérito alguno a la SNES en ese campo concreto de su hardware. Si necesitas optimizar al EXTREMO para que un shooter corra bien a una res de 256x224, cuando otras máquinas hacen lo mismo a 320, 336 o 512 x224/39/56, sin tanto esfuerzo, es que algo no da la talla en el sistema, al menos para los estándares 16 bits de ciertos géneros, y aquí por supuesto meto a los ARCADES que eran los que los marcaban.

-La visión de pantalla para shoot em ups horizontales dependen de las proporciones del dibujo, no de la resolución.

Menos nunca es más, ni igual tampoco. Aunque como esté dibujada la escena influye a nivel estético, al final más líneas de imagen ayudan a tener mayor capacidad de maniobra real, por no hablar de unas colisiones más sofisticadas a nivel pixel. Por mucho que redibujes nunca vas a conseguir un aspect-ratio 1:1 pasando de 384 a 256, yo nuevamente lo siento pero NO PUEDO ser indulgente con el hecho de que la SNES esté capada a 256x224 (full screen) cuando ya en 1990 era un ratio que el 99% de sistemas incluído Arcades y ordenadores ya se había dejado atrás salvo para determinados contextos.

O si no díselo a los desarrolladores de Taito en la época

Sexy MotherFucker escribió:A 256x224.... La otras máquinas de esa generación, incluída la Pc-Engine, tienen contextos más díficiles para el género (también mejores configuraciones de CPU claro). De hecho la PCE para los verticales suele emplear ratios de 256x239 sin despeinarse.

¿Tienen mejores configuraciones de CPU?. Podríamos estar hablando de que la snes con el 65816+PPU1 podría ser la mas potente de todas. Menudo giro de guión.

Llevais tanto tiempo considerando a la snes una consola con una cpu raquítica, que no habeis pretado atención a los cambios.

Sexy MotherFucker escribió:Yo lo siento pero es que jamás voy a poder concederle mucho crédito o mérito alguno a la SNES en ese campo concreto de su hardware. Si necesitas optimizar al EXTREMO para que un shooter corra bien a una res de 256x224, cuando otras máquinas hacen lo mismo a 320, 336 o 512 x224/39/56, sin tanto esfuerzo, es que algo no da la talla en el sistema, al menos para los estándares 16 bits de ciertos géneros, y aquí por supuesto meto a los ARCADES que eran los que los marcaban.

Thunder force IV se ejecuta en un área de pantalla inferior al del rendering ranger, o aero fighters.

Puedes argumentar que su resolución no permite tener un área de visión mas panorámico, pero no que la snes se maneje en áreas de pantalla mas pequeñas, porque no es cierto por defecto.

Del mismo modo que renegar de poder tener planos a 512x224/448 o 512x239/478, solo porque el campo de los sprites se conserva en 256x224/239, es rechazar una virtud sin considerar que aún así se siguen ganando cosas.

Sexy MotherFucker escribió:Menos nunca es más, ni igual tampoco. Aunque como esté dibujada la escena influye a nivel estético, al final más líneas de imagen ayudan a tener mayor capacidad de maniobra real, por no hablar de unas colisiones más sofisticadas a nivel pixel. Por mucho que redibujes nunca vas a conseguir un aspect-ratio 1:1 pasando de 384 a 256, yo nuevamente lo siento pero NO PUEDO ser indulgente con el hecho de que la SNES esté capada a 256x224 (full screen) cuando ya en 1990 era un ratio que el 99% de sistemas incluído Arcades y ordenadores ya se había dejado atrás salvo para determinados contextos.

O si no díselo a los desarrolladores de Taito en la época

Hablamos de que la resolución imponga no tener área de visión por defecto. Eso dependerá de la proporción del dibujo. Lo que implica ya lo sabemos todos, pero no se está hablando de eso.


P.D: Lo que no se es el por qué de la negativa a hablar de estas cosas en el hilo oficial de la snes, cuando ahí nadie podría llamar la atención por hacerlo

@Señor Ventura La alta resolución completa es inviable para según que tipo de juegos, que es un límite al que puede llegar está bien, pero el para qué?, funciona para mantener una jugabilidad? es la pregunta clave. No hay respuesta, la respuesta es que solo unos pocos alcanzan los 512x448 y si las compañías desecharon este modo es que lastraba a todo lo demás y probablemente sea cuestión del hardware. En esa resolución la consola no se siente bien para mantener siempre un experiencia que llegara al mínimo, depende de que tipos de juegos. Y hay pocos. Si la consola hubiera traido el Motorola a 10Mhz que descartaron entonces todo lo que siempre has comentado se hubiera cumplido sin pensar en hipótesis. Al final el Ricoh aunque muy versatil y más rápido en respuesta (2 ciclos) nunca fue pulido a tal extremo por lo que quiera que sea. Solo con los chips solucionaron la "página cero" de registros, etc...

@Andrómeda Nunca se consideró poner un motorola en la snes, eso fué un bulo. La snes se pensó con un 65816 porque se pretendía otorgarle retrocompatibilidad con la nes.

Tanto es así que la cpu arranca por defecto en modo nativo, que es el modo de funcionamiento en el que funciona como la cpu de la nes.

Sobre lo demás, no es un hecho que las compañías desechaban el modo de alta resolución porque lastraba. Consumes el doble de ancho de banda que necesitan los planos a 256x224, pero no rendimiento. El sistema gráfico tiene un modo a 512x224/448 y para garantizar su desempeño lo hace bajo la profundidad de color adecuada.

No se utilizó masivamente, entre otras cosas porque sería doblar la memoria dedicada a los planos, y si ya de por si les costaba abrir la mano para conceder un tamaño de rom grande, imagínate doblando el gasto en memoria.

Señor Ventura escribió:@Andrómeda Nunca se consideró poner un motorola en la snes, eso fué un bulo. La snes se pensó con un 65816 porque se pretendía otorgarle retrocompatibilidad con la nes.

Tanto es así que la cpu arranca por defecto en modo nativo, que es el modo de funcionamiento en el que funciona como la cpu de la nes.

Sobre lo demás, no es un hecho que las compañías desechaban el modo de alta resolución porque lastraba. Consumes el doble de ancho de banda que necesitan los planos a 256x224, pero no rendimiento. El sistema gráfico tiene un modo a 512x224/448 y para garantizar su desempeño lo hace bajo la profundidad de color adecuada.

No se utilizó masivamente, entre otras cosas porque sería doblar la memoria dedicada a los planos, y si ya de por si les costaba abrir la mano para conceder un tamaño de rom grande, imagínate doblando el gasto en memoria.

Exacto, no puedes poner muchos tiles diferentes en pantalla a 512x224, además tienes que bajar la resolución y los colores creo que se limitan a 16 en pantalla.

Hay un ejemplo potente de la alta resolución y su problemática y por lo que yo la descarto aunque no deja de ser algo curioso que puede lograr la Snes, este es un juego de coches de Snes alta resolución:




PD: Lo del Motorola tenía entendido que sí, que iba a ser un pepinazo (como todas a priori)pero el dueño de Nintendo quería retrocompatibilidad con Nes esto abarató además costes de consola pero lastraba la CPU de un conjunto brutal con el Motorola a 10MHz, aunque el SA1 puede llevar a la máquina a números bastante altos de MHz pero con el cuello de botella.

Señor Ventura escribió:¿Tienen mejores configuraciones de CPU?. Podríamos estar hablando de que la snes con el 65816+PPU1 podría ser la mas potente de todas. Menudo giro de guión.

Te estás adscribiendo a esa hipotética posibilidad como si fuese la segunda venida de Cristo en 16 bits, cuando la tiste realidad es que de momento sólo te tenemos a ti hablando con un tío en Nesdev que no acaba de tener claro para qué puede utilizarse ese recurso tan forzado:

https://forums.nesdev.com/viewtopic.php ... 3&start=15

¿Multiplicaciones para tareas lógicas de CPU en un juego de16 bits? Ya me dirás para qué las quiere; si acaso se me ocurre para darle masticados pequeños escalados de sprites rollo Paprium o Yoshi's Island, y luego pinche/corte para copiar en memoria, o para cálculos poligonales si acaso, pero está por ver hasta qué punto es posible todo ello, porque lo mismo tú ya te estás imaginando un chip FX surgido de la nada.

¿Los multiplicadores del PPU1 van a hacer que el 65816 sea más solvente haciendo barridos de imagen? ¿Hay IAs, físicas, etc, que realmente requieran multiplicar cosas es 1 programa de 16 bits? ¿La SNES va a mejorar sus brawlers, shooters?

Porque si la respuesta es "ya veremos", por favor, emplea el argumento de los multiplicadores cuando haya algo con que poder sujetarlo mínimamente.

Llevais tanto tiempo considerando a la snes una consola con una cpu raquítica

Su CPU no, la configuración: bajo clock incluso para un 65816, posibles roms que le castran aún más la frecuencia, Wram a distinta frecuencia, etc. Y es 1 pena porque es 1 micro ideal para consolillass con sistemas DMA basadas en mapa de tiles.

Menos mal que tiene la suerte de tener un modo fijo de 256x224 que la alivie en ciertos géneros, yo cada día tengo más claro que el no darle un modo opcional "full screen" fue una medida de precaución más allá de hacerla retrocompatible con la NES.

Thunder force IV se ejecuta en un área de pantalla
inferior al del rendering ranger, o aero fighters.

La Mega Dive en su modo chunky, a no ser que tenga desactivadas las scanlines en negro, es decir; que el VDP no las esté dibujando, comienza hacer barridos de imagen desde la esquina exacta donde comienzen los 320x224 pixels, o sea que en TF IV la CPU gasta una capacidad de proceso similar por mucho que la acción real ocurra por debajo de los marcadores.

La PC-Engine lo mismo, y haciendo barridos de imagen es mucho más solvente que la SNES, y que la MD también, aunque para otros menesteres su CPU Custom sea en líneas generales menos potente que un 65816 o M68k.

El sistema gráfico tiene un modo a 512x224/448 y para garantizar su desempeño lo hace bajo la profundidad de color adecuada.

Y castrando las tranparencias, el Modo-7, reduciendo los planos de scroll, restringiendo memoria, etc; logrando que todo lo que le da personalidad propia a la SNES se esfume, porque de modos hi-res, a excepción de la Neo Geo AES, gozan todos los sistemas de 16 bits domésticos en mayor o menor medida. Yo no dudo de que puedan utilizar esos modos de manera interesante, pero un Rendering Ranger ya no cabe en ese contexto.

De cualquier forma para discutir de shooters yo prefiero preguntarle a magno sobre el modo de 512×224, porque tú te las pintas demasiado felices siempre y luego al final xD

Señor Ventura escribió:

EPSYLON EAGLE escribió:O que la Snes dibuja usando 128 sprites la Mega lo hace usando solo 70.

Lo que hace el batman returns y los final fight es incorrecto. No puedes comparar juegos que usan mal el dibujado con los sprites con los juegos que usan bien el dibujado con los sprites.


Con respecto a lo que pueden dibujar:
Sprites de 64 pixels de ancho: MD 0 y SN 4.
Sprites de 32 pixels de ancho: MD 10 y SN 8.
Sprites de 16 pixels de ancho: MD 20 y SN 16.
Sprites de 8 pixels de ancho: MD 20 y SN 32.


Prefiero la situación de snes, porque te permine llenar la pantalla usando menos tiles (preservando el ancho de banda), obtienes un beneficio cuando toca usar sprites de pequeño tamaño, puedes usar sprites enormes usando un único sprite, y tan solo pierde en campos intermedios, donde puede compensar la desventaja usando el excedente de sprites disponibles para dibujar mas fuera de los scanlines mas sobrecargados.

La ventaja de megadrive se traduce en que, por ejemplo en brawlers, la MD puede poner 7 objetos en línea, y la SN solo 6 (puede que incluso 8 a 6), pero puede poner mas personajes en pantalla si están bien distribuídos y si el diseño lo hace posible gracias a que realmente puede poner mas sprites, y además gana por goleada en el resto de situaciones.

Se echa de menos usar sprites rectangulares (aunque es posible ponerlos), pero con una planificación en el arte de los dibujos puedes no dejar huecos en los cuadrados, y no necesitar emplear sprites rectangulares. Por el mismo precio puedes hacer los gráficos aún mas grandes. Si te fijas en la tabla de atributos de los sprites del final fight 3, notarás como se desaprovechan, y como se desperdician... ¿consecuencia?= gasto de ancho de banda, parpadeos, y menos sprites disponibles. Todo esto es innecesario.

Prefieres lo que quieres, pero el hecho es que la configuración del sprite de Snes es uno de tus talones de Aquiles, toma esta escena, por ejemplo:

A diferencia de Megadrive no puedes usar cualquier tile en VRAM para componer los sprites, hay un espacio reducido y es mejor usar sprites pequeños para aprovechar la memoria. Se usan un total de 10 sprites para el personaje, el escudo y la espada necesitan sprites independientes pues podemos obtener nuevas mejoras y actualizarlos a lo largo del juego, ojo al cofre, 4 sprites para representarlo.


En Megadrive en lugar de usar 14 sprites de 16x16 podríamos hacer esta combinación para sumar un total de 5.
- 1 sprite de 32x24 para el cofre, no solo es un sprite, ahorramos tener que hacer un rectángulo de 32x32
- 1 sprite de 16x32 para la espada
- 1 sprite de 8x16 para el escudo, ahorramos 8 pixels por linea, pero si el escudo se actualiza a uno más grande la ventaja sería nula
- 2 sprites de 32x24 para el personaje



En resumen :

Megadrive puede pintar 320 pixels de sprite por scanline, Snes son 256 o 272, depende del modo, generalmente 256.

También maneja mejor los huecos al poder usar a la vez todos los tamaños disponibles y tiene sprites intermedios como 24x24, Snes solo puede manejar 2 tamaños a la vez, desaprovecha pixels y pinta menos.

Aún así en modo 256x224 Snes podría llevar ventaja, Megadrive pasa a pintar lo mismo por scanline, aunque sigue teniendo la ventaja de poder usar todos los tamaños.

Otro dato curioso, Snes puede manejar un total de 56 sprites en pantalla de 32x32, para poder mostrar 128 deben ser de 16x16, en Megadrive pueden ser 70 de 32x32, 80 de 32x24, 80 de 24x24, etc..

Snes manejando 56 sprites de 32x32 (100% pantalla), sacado de una techdemo de nesdev.

Sexy MotherFucker escribió:Te estás adscribiendo a esa hipotética posibilidad como si fuese la segunda venida de Cristo en 16 bits, cuando la tiste realidad es que de momento sólo te tenemos a ti hablando con un tío en Nesdev que no acaba de tener claro para qué puede utilizarse ese recurso tan forzado:

https://forums.nesdev.com/viewtopic.php ... 3&start=15

¿Multiplicaciones para tareas lógicas de CPU en un juego de16 bits? Ya me dirás para qué las quiere; si acaso se me ocurre para darle masticados pequeños escalados de sprites rollo Paprium o Yoshi's Island, y luego pinche/corte para copiar en memoria, o para cálculos poligonales si acaso, pero está por ver hasta qué punto es posible todo ello, porque lo mismo tú ya te estás imaginando un chip FX surgido de la nada.

¿Los multiplicadores del PPU1 van a hacer que el 65816 sea más solvente haciendo barridos de imagen? ¿Hay IAs, físicas, etc, que realmente requieran multiplicar cosas es 1 programa de 16 bits? ¿La SNES va a mejorar sus brawlers, shooters?

Porque si la respuesta es "ya veremos", por favor, emplea el argumento de los multiplicadores cuando haya algo con que poder sujetarlo mínimamente.

No, sexy, multiplicaciones y divisiones para todo lo que necesite de multiplicaciones y divisiones, y casi a coste cero.

Tan simple como eso, no le busques la vuelta para anular lo que es, porque si para una "tarea lógica" procesas mas rápido a base de multiplicaciones, mas potencia tendrás.

El ppu1 ni siquiera sabe lo que está haciendo, ni para que. Tu le pones una multiplicación, y te la hace como un rayo. No es un coprocesador, no hay que interrumpirle ni sincronizarse con el, son operaciones artiméticas *casi* gratis, y ya. Que no es poco precisamente.

Sexy MotherFucker escribió:Menos mal que tiene la suerte de tener un modo fijo de 256x224 que la alivie en ciertos géneros, yo cada día tengo más claro que el no darle un modo opcional "full screen" fue una medida de precaución más allá de hacerla retrocompatible con la NES.

No darle un modo a 320x224 te ahorra un montón de costes en complejidad. Los PPU's ya eran complejos de por si, si le metes mas modos gráficos encareces su proceso de fabricación. Y la compatibilidad con la nes era buscada.

Sexy MotherFucker escribió:La Mega Dive en su modo chunky, a no ser que tenga desactivadas las scanlines en negro, es decir; que el VDP no las esté dibujando, comienza hacer barridos de imagen desde la esquina exacta donde comienzen los 320x224 pixels, o sea que en TF IV la CPU gasta una capacidad de proceso similar por mucho que la acción real ocurra por debajo de los marcadores.

El thunder force iv funciona a 320x178 en pal, y 320x192 en ntsc. Olvídate de lo que hace el VDP, la CPU solo tiene que centrarse en esas resoluciones, que es donde se sitúa el campo de los sprites (de hecho lo que hay debajo de lo que era el marcador, es una amalgama de absolutamente NADA).

Sexy MotherFucker escribió:La PC-Engine lo mismo, y haciendo barridos de imagen es mucho más solvente que la SNES, y que la MD también, aunque para otros menesteres su CPU Custom sea en líneas generales menos potente que un 65816 o M68k.

Eso es relativo. Sus sistema gráfico hace unas cosas, el sistema gráfico de la megadrive hace otras, y el de la snes hace sus propias cosas también.

Sexy MotherFucker escribió:Y castrando las tranparencias, el Modo-7, reduciendo los planos de scroll, restringiendo memoria, etc; logrando que todo lo que le da personalidad propia a la SNES se esfume, porque de modos hi-res, a excepción de la Neo Geo AES, gozan todos los sistemas de 16 bits domésticos en mayor o menor medida. Yo no dudo de que puedan utilizar esos modos de manera interesante, pero un Rendering Ranger ya no cabe en ese contexto.

Pero tío, que estás poniendo planos de hasta 512x478, ¿que mas quieres?.

¿Que sus planos pasan a tener 16 y 4 colores por tile?, pues de acuerdo, ni que fuese mala cosa cuando tienes 16 sub paletas, ¡y tienes planos en alta resolución!.

Sexy MotherFucker escribió:De cualquier forma para discutir de shooters yo prefiero preguntarle a magno sobre el modo de 512×224, porque tú te las pintas demasiado felices siempre y luego al final xD

Los planos en alta resolución pasan a tener tiles de 64 Bytes. Necesitas dedicar mas ancho de banda para actualizar los tiles a la hora de hacer scroll, pero, ¿cuanto crees que necesitas con 3 planos?, ¿o con dos planos, siendo uno de ellos de 256 colores?. El esfuerzo para los PPU's y el DMA es el mismo en esos casos.

EPSYLON EAGLE escribió:Prefieres lo que quieres, pero el hecho es que la configuración del sprite de Snes es uno de tus talones de Aquiles, toma esta escena, por ejemplo:

A diferencia de Megadrive no puedes usar cualquier tile en VRAM para componer los sprites, hay un espacio reducido y es mejor usar sprites pequeños para aprovechar la memoria. Se usan un total de 10 sprites para el personaje, el escudo y la espada necesitan sprites independientes pues podemos obtener nuevas mejoras y actualizarlos a lo largo del juego, ojo al cofre, 4 sprites para representarlo.

¿Me rebates para decir lo mismo que yo?.

Ahí se usan tiles para dibujar solo unos pocos pixels, ni siquiera usan tiles de 8x8 para dibujar los pocos pixels que le faltan al cofre, usan los de 16x16 igualmente. No está optimizado, y si hace falta redibujar para que quepa en dos sprites de 16x16, pues se hace, y punto.

Para la super nintendo no es problema usar dos sprites de 16x16 en lugar de uno de 32x16, porque le sobran sprites, y siguen siendo 4 tiles de sprites para ese scanline, que supone exactamente la misma sobrecarga. Lo que le mata al king of dragons es el uso reiterado de sprites que podrías ahorrarte ponerlo.

Tu mismo lo has puesto, se están usando mas sprites de los necesarios. Todo eso se podría hacer con menos sprites.

.

EPSYLON EAGLE escribió:En resumen :

Megadrive puede pintar 320 pixels de sprite por scanline, Snes son 256 o 272, depende del modo, generalmente 256.

También maneja mejor los huecos al poder usar a la vez todos los tamaños disponibles y tiene sprites intermedios como 24x24, Snes solo puede manejar 2 tamaños a la vez, desaprovecha pixels y pinta menos.

Que un juego malgaste sprites para pintar 4 pixels no significa que no se pueda evitar situándolos de una manera mas inteligente. Eso de que megadrive "maneja mejor los huecos", cuando es algo que depende del programador, es totalmente falso.

Puedes optimizar en megadrive usando menos sprites, si, pero eso no significa que la snes no pueda optimizar igualmente. Puede necesitar mas sprites pintar la misma escena que la mega, pero impedir la saturación de los scanlines igual de bien.

EPSYLON EAGLE escribió:Aún así en modo 256x224 Snes podría llevar ventaja, Megadrive pasa a pintar lo mismo por scanline, aunque sigue teniendo la ventaja de poder usar todos los tamaños.

Hablando de sprites, la snes tiene ventajas que la otra no tiene, le pongas la resolución que le pongas.

Un juego de aviones con 120 balas es un ejemplo... o un smash tv... o un pang... o usar sprites para partículas... yo no lo subestimaría tan a la ligera.

EPSYLON EAGLE escribió:Otro dato curioso, Snes puede manejar un total de 56 sprites en pantalla de 32x32, para poder mostrar 128 deben ser de 16x16, en Megadrive pueden ser 70 de 32x32, 80 de 32x24, 80 de 24x24, etc..

¿Y te parece una desventaja?.

Nunca vas a poner 50 o 70 sprites de 32x32 en una situación de juego normal. ¿Cuantos sprites de 32x32 pone paprium antes de llegar al flickering?.

Ahora, con sprites pequeños ya es otra historia, ahí ya si se nota la diferencia entre 80 y 128.

Señor Ventura escribió:¿Me rebates para decir lo mismo que yo?.

Ahí se usan tiles para dibujar solo unos pocos pixels, ni siquiera usan tiles de 8x8 para dibujar los pocos pixels que le faltan al cofre, usan los de 16x16 igualmente. No está optimizado, y si hace falta redibujar para que quepa en dos sprites de 16x16, pues se hace, y punto.

Para la super nintendo no es problema usar dos sprites de 16x16 en lugar de uno de 32x16, porque le sobran sprites, y siguen siendo 4 tiles de sprites para ese scanline, que supone exactamente la misma sobrecarga. Lo que le mata al king of dragons es el uso reiterado de sprites que podrías ahorrarte ponerlo.

Tu mismo lo has puesto, se están usando mas sprites de los necesarios. Todo eso se podría hacer con menos sprites.

"Le sobran sprites" es totalmente falso, tengo certeza que ni en Snesdev estarán de acuerdo con semejante declaración...

Cuanto el KoD creo que no se usó sprites de 8x8 para evitar sobrecargar la CPU, ya sabes, más sprites, más colisiones y lógica para procesar, recuerda que el juego ya pasa a la pantalla muy pequeña para ahorrar recursos...

Señor Ventura escribió:Que un juego malgaste sprites para pintar 4 pixels no significa que no se pueda evitar situándolos de una manera mas inteligente. Eso de que megadrive "maneja mejor los huecos", cuando es algo que depende del programador, es totalmente falso.

Puedes optimizar en megadrive usando menos sprites, si, pero eso no significa que la snes no pueda optimizar igualmente. Puede necesitar mas sprites pintar la misma escena que la mega, pero impedir la saturación de los scanlines igual de bien.

Que puedes optimizar en ambos es correcto, pero igualmente jamás!

Supongamos que en un juego la navecita tiene 32 píxeles de ancho y 24 píxeles de alto.

En Super Nes puedes usar uno sprite de dimensiones 32 x 32 desperdiciando pixels abajo o use la configuración "óptima" 2 sprites de dimensiones 16x16 arriba combinados con 4 sprites de 8x8 abajo, no hay sprites rectangulares en Snes, y solo se pude usar 2 tamaños a la vez.

En Mega Drive puedes pintar con solo 1 sprite, porque su tabla de sprites permite combinaciones de sprites de todas las dimensiones y se pueden usar libremente.

8x8, 8x16, 8x24, 8x32
16x8, 16x16, 16x24, 16x32
24x8, 24x16, 24x24, 24x32
32x8, 32x16, 32x24, 32x32

Mega Drive hace más con mucho menos.

Señor Ventura escribió:Hablando de sprites, la snes tiene ventajas que la otra no tiene, le pongas la resolución que le pongas.

Un juego de aviones con 120 balas es un ejemplo... o un smash tv... o un pang... o usar sprites para partículas... yo no lo subestimaría tan a la ligera.

Conozco bien las maravillas de Snes y no lo subestimo, el problema está en sobrestimar las capacidades del dispositivo que és su caso.

Cuando se habla "ventaja" de Snes, estás refiriéndose-se a los sprites de dimensiones 64 x 64? Creo extraña ventaja que se come la VRAM y 1/4 del ancho de banda de sprites pero...

Sí hablas de la ventaja de poder mostrar más sprites pequeños de 8x8 píxeles, si la concedo, pero cuando usa muchos tenga cuidado con la CPU. Y estoy realmente curioso por el juego de aviones y 120 balas, ¿dónde están los enemigos?

Señor Ventura escribió:Nunca vas a poner 50 o 70 sprites de 32x32 en una situación de juego normal. ¿Cuantos sprites de 32x32 pone paprium antes de llegar al flickering?.

Ahora, con sprites pequeños ya es otra historia, ahí ya si se nota la diferencia entre 80 y 128.

Respondiendo usando tu lógica, nadie nunca pondrá 128 pequeñitos sprites de 8x8 en una situación de juego normal.

Vaya vaya ósea que lo que llevo discutiendo durante días aquí al final se está cumpliendo .
Ya dije que " gratis " no hay nada nunca y las cábalas que se hacen a veces son totalmente erróneas . Si la máquina hubiera sido la segunda venida de Cristo no creo que los programadores tuvieran que lidiar en su época con limitaciones en el hardware .
Un apunte que lo he puesto en el foro principal de Prapium pero que ha pasado desapercibido . Esto supongo que te interesará @Sexy MotherFucker según los programadores han mejorado los VDP de Mega Drive y ahora son 94 sprites en vez de 80 . Supongo que será por el DSP . Y han hecho también algo sobre los scrolls . Dicen que en el libro de las ediciones inversor salen esas cosas .

Ventura no se conforma con contar con una paleta de color envidiable, ni con la posibilidad de rotar escenarios, ni con las transparencias, ni con sonido digital... Lo quiere ganar todo para su Snes, hasta lo que no se puede

robotnik16 escribió:Ventura no se conforma con contar con una paleta de color envidiable, ni con la posibilidad de rotar escenarios, ni con las transparencias, ni con sonido digital... Lo quiere ganar todo para su Snes, hasta lo que no se puede

Lo que no se puede es decir que la megadrive puede poner 70 sprites de 32x32, y quedarse todo el mundo tan tranquilo mientras se empiezan a afilar los cuchillos si alguien dice que el ppu1 le proporciona multiplicaciones gratis al 65816.

O decir que la forma en que usa los sprites el king of dragons o los final fights es lo normal en snes, y si explicas que no es así empiezan las discusiones.

Que yo sepa he mencionado minimo en dos ocasiones que en entornos de brawlers de personajes grandes megadrive puede poner uno o dos enemigos mas por linea que snes, pero es que lo obviais, y al final "lo quiero ganar todo para mi snes".

Como querais, ¿eh?. Esto ya va torciendose, así que por mi parte lo dejo aquí.

jeje no lo sé, no estoy leyendo demasiado, los tecnicismos fuera de foros de desarrolladores no suelo tenerlos muy en cuenta.

De momento va bien la cosa, prosigan, pon el gif de las 120 balas y demás que te dijo Epsylon @Señor Ventura .

Y como ves lo que dijo Hookun de Paprium?¿, para darle un halo al hilo que iba del juego. 94 en vez de 80 no es moco de pavo.

@Andrómeda
Buahh eso no interesa . Lo que no entiendo de este chico es que nunca nombra al Súper Metroid que para mí es el mayor exponente de lo que se podría esperar de Snes y para mí el mejor juego absoluto de las 16 bits y pone ejemplos de juegos que su mayor parte exceptaundo unos pocos han pasado muy desapercibidos y no le llegan a la suela de los zapatos a la competencia en cuanto ha demostrar una supuesta superioridad que jamás ha sido demostrada .

Hookun escribió:@Andrómeda
Buahh eso no interesa . Lo que no entiendo de este chico es que nunca nombra al Súper Metroid que para mí es el mayor exponente de lo que se podría esperar de Snes y para mí el mejor juego absoluto de las 16 bits y pone mierdas que no le llegan a la suela de los zapatos a la competencia .

No sé en que lio estáis pero para él Super Metroid es de sus juegos favoritos o tal vez su favorito de Snes, es lo único que puedo aportar. No uses la palabra mierda y ese tipo de lenguaje barato para sus ejemplos, por lo menos un respeto entre ambos y a los demás que os leen aunque no creas que son válidos, si no esto va a acabar mal por todos los hilos.

@Andrómeda
Pues a ver qué quieres que te diga que haya grandes juegos en el sistema de una calidad incuestionable y busque ejemplos de potencias en juegos que han pasado la mayor parte con más pena que gloria es como poco curioso . Que quizás me haya excedido con la palabra mierda puede pero es que hay cada cosa que seamos sinceros dan vergüenza ajena . Ya cambio la expresión a una más " aceptable " .

robotnik16 escribió:jeje no lo sé, no estoy leyendo demasiado, los tecnicismos fuera de foros de desarrolladores no suelo tenerlos muy en cuenta.

Lo mejor que haces.

Pues a mi este Paprium que quieren que les diga.....a medida que voy viendo videos mi opinión sobre el va empeorando, vaya chapuza, ya podían haber utilizado ese DSP con los 94 sprites para un hack/mejora del Final Fight CD, para el Bare Knuckle 3...., o ir directamente a por un port del SOR Remake a Megadrive,

Como dije, me entusiasmaría mucho mas un hack como el del Final Fight 2 pero para el Rival Turf 2 o Peace Keepers

chinitosoccer escribió:Pues a mi este Paprium que quieren que les diga.....a medida que voy viendo videos mi opinión sobre el va empeorando, vaya chapuza, ya podían haber utilizado ese DSP con los 94 sprites para un hack/mejora del Final Fight CD, para el Bare Knuckle 3...., o ir directamente a por un un port del SOR Remake a Megadrive,

Como dije, me entusiasmaría mucho mas un hack como el del Final Fight 2 pero para el Rival Turf 2 o Peace Keepers

Eso no podrían hacerlo por temas legales, esos juegos no son de WM, necesitarían pagar licencias, y no lo van a hacer. Ellos hacen juegos nuevos no hacks de juegos ajenos a la empresa. Lo lógico es usar su propia tecnología en juegos propios.

Pues yo cada vídeo que veo del Paprium más impresionante me parece y más ganas tengo de tenerlo . Pero como sobre gustos no hay nada escrito ...

chinitosoccer escribió:Pues a mi este Paprium que quieren que les diga.....a medida que voy viendo videos mi opinión sobre el va empeorando, vaya chapuza, ya podían haber utilizado ese DSP con los 94 sprites para un hack/mejora del Final Fight CD, para el Bare Knuckle 3...., o ir directamente a por un port del SOR Remake a Megadrive,

Como dije, me entusiasmaría mucho mas un hack como el del Final Fight 2 pero para el Rival Turf 2 o Peace Keepers

¿Se puede leer algo al respecto?.

Andrómeda escribió:De momento va bien la cosa, prosigan, pon el gif de las 120 balas y demás que te dijo Epsylon @Señor Ventura .

Hay un vídeo en youtube, pero lo han puesto en privado y no se puede ver.

Recuerdo haber visto imágenes, y está muy bien. Eran en torno a 110 balas, el resto se reservaba para naves y explosiones.

Andrómeda escribió:Y como ves lo que dijo Hookun de Paprium?¿, para darle un halo al hilo que iba del juego. 94 en vez de 80 no es moco de pavo.

Me parece la mar de curioso, y sería perfecto si implica poder dibujar mas sprites por línea. Me pregunto que habrá pasado ahí ahora como para que nunca antes lo hayamos podido ver.

Todavía hay cosas con las que se está trasteando, como el hdma, que permite un nivel "postprocesado" del que todavía ni nos imaginamos, o lo ya mencionado del ppu1, que ya estaba documentado desde siempre, pero que ahí se quedaba, muerto de aburrimiento.

chinitosoccer escribió:Pues a mi este Paprium que quieren que les diga.....a medida que voy viendo videos mi opinión sobre el va empeorando, vaya chapuza...

Que los dioses del SENTIR se apiaden de tu descarriada alma de hereje.

chinitosoccer escribió:Pues a mi este Paprium que quieren que les diga.....a medida que voy viendo videos mi opinión sobre el va empeorando, vaya chapuza, ya podían haber utilizado ese DSP con los 94 sprites para un hack/mejora del Final Fight CD, para el Bare Knuckle 3...., o ir directamente a por un port del SOR Remake a Megadrive,

Como dije, me entusiasmaría mucho mas un hack como el del Final Fight 2 pero para el Rival Turf 2 o Peace Keepers

Fue un placer conocerte. Gente que ha gastado euros en un juego homebrew jamás aceptará que no fueron bien invertidos (tampoco me sorprende, sucede con gente que reserva juegos actuales o ed. coleccionistas y salen como churros).

stormlord escribió:

chinitosoccer escribió:Pues a mi este Paprium que quieren que les diga.....a medida que voy viendo videos mi opinión sobre el va empeorando, vaya chapuza, ya podían haber utilizado ese DSP con los 94 sprites para un hack/mejora del Final Fight CD, para el Bare Knuckle 3...., o ir directamente a por un un port del SOR Remake a Megadrive,

Como dije, me entusiasmaría mucho mas un hack como el del Final Fight 2 pero para el Rival Turf 2 o Peace Keepers

Eso no podrían hacerlo por temas legales, esos juegos no son de WM, necesitarían pagar licencias, y no lo van a hacer. Ellos hacen juegos nuevos no hacks de juegos ajenos a la empresa. Lo lógico es usar su propia tecnología en juegos propios.

Lo que él está pidiendo es legal: Usar sus conocimientos para hacer un hack y mejorar otros juegos.
Lo que tú dices es ilegal, pero no incompatible con lo anterior: Comercializar el juego hackeado.

Si no romhacking, steam, clandlan, nexus, etc. estaría cerrado desde hace siglos.

Se me olvidaba contestar a algo...

EPSYLON EAGLE escribió:"Le sobran sprites" es totalmente falso, tengo certeza que ni en Snesdev estarán de acuerdo con semejante declaración...

El límite de 128 sprites compensa el gasto de algunos, o muchos sprites extra, porque es una cantidad grande que no vas a agotar fácilmente, eso es lo que significa "le sobran sprites". Puede compensar mucho, puede compensar poco, o puede no compensar nada, depende de lo que haya que mostrar.

Las expresiones pueden entenderse como una expresión, o pueden entenderse de forma literal.

EPSYLON EAGLE escribió:Que puedes optimizar en ambos es correcto, pero igualmente jamás!

Supongamos que en un juego la navecita tiene 32 píxeles de ancho y 24 píxeles de alto.

En Super Nes puedes usar uno sprite de dimensiones 32 x 32 desperdiciando pixels abajo o use la configuración "óptima" 2 sprites de dimensiones 16x16 arriba combinados con 4 sprites de 8x8 abajo, no hay sprites rectangulares en Snes, y solo se pude usar 2 tamaños a la vez.

En Mega Drive puedes pintar con solo 1 sprite, porque su tabla de sprites permite combinaciones de sprites de todas las dimensiones y se pueden usar libremente.

8x8, 8x16, 8x24, 8x32
16x8, 16x16, 16x24, 16x32
24x8, 24x16, 24x24, 24x32
32x8, 32x16, 32x24, 32x32

Mega Drive hace más con mucho menos.

Puedes:

-Usar un sprite de 32x32 para hacer la nave mas grande, y así no queda ningún espacio desperdiciado, ganando un gráfico mas detallado (y mas grande, como ya he mencionado).

-También puedes usar dos sprites de 16x16 y 4 sprites de 8x8. Gastas 5 sprites en lugar de 1, pero optimizas la carga de sprites por scanline exactamente igual, y el límite de 128 sprites amortigua en cierto grado el impacto de tener que gastar 5 de golpe para esa tarea en lugar de solo 1.

-Usar sprites rectangulares, que aunque no lo sepas, si se puede. Se accede indicando un valor del registro OBSEL de la OAM (puerto $2101h), a "110" permite usar sprites de 16x32 pixels y 32x64 pixels, y a "111" permite usar sprites de 16x32 pixels y 32x32 pixels. En el contexto de un juego de naves no es recomendable porque necesitas sprites pequeños para representar las balas, pero en otros géneros puede ser realmente útil.

EPSYLON EAGLE escribió:Conozco bien las maravillas de Snes y no lo subestimo, el problema está en sobrestimar las capacidades del dispositivo que és su caso.

Cuando se habla "ventaja" de Snes, estás refiriéndose-se a los sprites de dimensiones 64 x 64? Creo extraña ventaja que se come la VRAM y 1/4 del ancho de banda de sprites pero...

Si un objeto es grande, pues es grande. Un sprite de 64x64 pesa 2048 Bytes, y si tienes que representar un objeto así de grande, te va a dar lo mismo hacerlo con un sprite de 64x64, con un plano, o con varios sprites de 32x32, o 16x16, u 8x8.

¿Para que se querría usar un sprite de 64x64 en gráficos que no lo llenen?. Partimos de un supuesto de un sprite de 64x64 que sea totalmente aprovechado, y por lo tanto es una ventaja que ese sprite solo gaste un slot en la tabla OAM de los 128 sprites disponibles.

EPSYLON EAGLE escribió:Sí hablas de la ventaja de poder mostrar más sprites pequeños de 8x8 píxeles, si la concedo, pero cuando usa muchos tenga cuidado con la CPU.

No es lo mismo 128 sprites que 128 objetos.

Ya he puesto un gif con el batman returns, el cual funciona empleando los 128 sprites porque los 3 o 4 objetos que salen en pantalla están representados a base de sprites de 8x8. Y se mueve sin ningún problema de rendimiento.

Luego tienes el pang, que incluso en los momentos en los que solo muestra 40 sprites a base de bolitas pequeñas, supone mas cpu a pesar de emplear 88 sprites menos que el batman returns.

La diferencia se entiende fácil. Una cosa no le supone ningún esfuerzo a la cpu, y la otra si.

EPSYLON EAGLE escribió:Y estoy realmente curioso por el juego de aviones y 120 balas, ¿dónde están los enemigos?

Creo que eran 110 balas, y el resto para naves, etc.

18 sprites para la nave del jugador y 8 o 10 naves enemigas, es mas que de sobra.

EPSYLON EAGLE escribió:Respondiendo usando tu lógica, nadie nunca pondrá 128 pequeñitos sprites de 8x8 en una situación de juego normal.

No es mi lógica, es que 70 sprites de 32x32 supone un escenario incontrolable a la hora de evitar parpadeos. Es una locura. No puedes llenar la pantalla de esa forma si quieres que se entienda algo lo que está pasando en pantalla.

128 sprites de 8x8 en pantalla sin embargo, si puedes emplearlo en una situación de juego normal:

EPSYLON EAGLE escribió:Prefieres lo que quieres, pero el hecho es que la configuración del sprite de Snes es uno de tus talones de Aquiles, toma esta escena, por ejemplo:

A diferencia de Megadrive no puedes usar cualquier tile en VRAM para componer los sprites, hay un espacio reducido y es mejor usar sprites pequeños para aprovechar la memoria. Se usan un total de 10 sprites para el personaje, el escudo y la espada necesitan sprites independientes pues podemos obtener nuevas mejoras y actualizarlos a lo largo del juego, ojo al cofre, 4 sprites para representarlo.

¿Estas seguro de que esto es tan rígido? ¿o te basas en lo que ves en esa herramienta?

Lo digo porque en NES, con el mapper MMC5 se podía dibujar sprites de 8x16 seleccionando cualquier tile de la memoria rom de video (CHR) que tuviese el cartucho, y no solo limitarse a los 256 tiles que en ese momento mostraba el mapeador por defecto en la memoria de vídeo PPU.

Me cuesta que algo que en NES se solucionó con un mapper, en la SNES no se hubiese tenido en cuenta.

@Diskover
La forma de trabajar de NES es totalmente diferente a la de SNES de ahí que se estén viendo y se hayan visto cosas increíbles en la 8bits de Nintendo impensables para su Hardware .

Diskover escribió:¿Estas seguro de que esto es tan rígido? ¿o te basas en lo que ves en esa herramienta?

Es que... 4 sprites para un cofre... y a alguien le parecerá normal que esa sea la forma de dibujarlo solo porque es snes.

Si son solo dos tipos de sprite los que permite mostrar, pero si por cada sprite que usas te están sobran un 60% de pixeles, o incluso mas, es obvio que estás usando mas de los que debes. Solo tienes que ver ese gif, la falta de optimización es del programador, no del hardware.

Señor Ventura escribió:

Diskover escribió:¿Estas seguro de que esto es tan rígido? ¿o te basas en lo que ves en esa herramienta?

Es que... 4 sprites para un cofre... y a alguien le parecerá normal que esa sea la forma de dibujarlo solo porque es snes.

Si son solo dos tipos de sprite los que permite mostrar, pero si por cada sprite que usas te están sobran un 60% de pixeles, o incluso mas, es obvio que estás usando mas de los que debes. Solo tienes que ver ese gif, la falta de optimización es del programador, no del hardware.

Desde luego es una decisión de diseño poco acertada. Si vas a consumir 4 tiles para dibujar un cofre, al menos usalos bien y dibuja un cofre grande.

Para entendidos como el señor Ventura,

Siempre he creído que la conversión de "The punisher" para Mega Drive, podría haber salido mucho más cercana al arcade (algo así, salvando las distancias como se ve el Final Fight de Mega cd), los personajes son pequeños y con pocos cuadros de animación, cosa que no ves en SOR2 o 3, y la paleta de colores es super gris...

Con un cartucho sin limitación de megas como el Paprium, Se podría hacer una conversión cercana al arcade?

DIE escribió:Para entendidos como el señor Ventura,

Siempre he creído que la conversión de "The punisher" para Mega Drive, podría haber salido mucho más cercana al arcade (algo así, salvando las distancias como se ve el Final Fight de Mega cd), los personajes son pequeños y con pocos cuadros de animación, cosa que no ves en SOR2 o 3, y la paleta de colores es super gris...

Con un cartucho sin limitación de megas como el Paprium, Se podría hacer una conversión cercana al arcade?

Siempre.

Menos colores, melodías rebajadas, bastantes menos enemigos en pantalla... pero en esencia es una meta alcanzable algo que recuerde al mismo juego, y con una jugabilidad intacta.

El port actual del punisher es una broma de mal gusto.