castlevania sotn, posible en sistemas inferiores?

@Paprium en el caso de super nes los chips añaden mas potencia o alguna característica, la consola fue pensada para eso, por eso el slot de cartucho tiene 2 sectores extras para los contactos usados en varios cartuchos con chips extras como el sdd-1, o sea eso forma parte de ella, esta hecho en su época por su empresa de manera oficial, asi como el 32x de megadrive o el mega cd, que se habla mucho de que estos anulaban casi toda la consola, como que no se sumaba, pero bueno son productos oficiales.
que el paprium tenga problemas de rendimiento no me explico, pero que usen colores y sonidos que se asemejen a los de la consola original seguramente es a propósito, mas sabiendo que ese cartucho usa un chipset ARM que se usaba en celulares baratos de hace unos años atrás.

@cristus

Te digo que, Paprium el juego, analizando pantalla por pantalla , escenario por escenario , y situación por situación, no hace absolutamente nada que no pueda hacer una Megadrive.

Tiene sus fallos y sus limitaciones , como todos los juegos.

Y te lo dice alguien que le ha dedicado cientos de horas y lo ha exprimido a tope.

Perdón por el offtopic que no tiene nada que ver con el tema original del hilo pero tenía que responder por alusiones.

@puch666
Hola.. llego un poco tarde, pero sí, las pruebas que hice del SOTN son :
- Meter la OST completa en un cartucho de N64, ocupó los 64MB y sonaba muy bien, pero lo suyo sería componer en midi o no sería viable
- Pruebas de animación con Alucard y distintas paletas
- Pruebas de scroll, en los escenarios más complejos con más planos de scroll 2D, no llegué a probar los 3D

En aquel momento no había SDK 2D (libre no propietario), así que tuve que crear uno para N64, que es lo que me tomó más tiempo.

Tampoco llegué a juntarlo todo para un test real, con colisiones y tal, pero vamos, vi que el juego era 100% viable, incluso sin usar el chip de apoyo RSP.

El único limitante sería el tamaño del cartucho, si te daban uno de 12, de 16 o de 32MB.

Conker64 escribió:@puch666
Hola.. llego un poco tarde, pero sí, las pruebas que hice del SOTN son :
- Meter la OST completa en un cartucho de N64, ocupó los 64MB y sonaba muy bien, pero lo suyo sería componer en midi o no sería viable
- Pruebas de animación con Alucard y distintas paletas
- Pruebas de scroll, en los escenarios más complejos con más planos de scroll 2D, no llegué a probar los 3D

En aquel momento no había SDK 2D (libre no propietario), así que tuve que crear uno para N64, que es lo que me tomó más tiempo.

Tampoco llegué a juntarlo todo para un test real, con colisiones y tal, pero vamos, vi que el juego era 100% viable, incluso sin usar el chip de apoyo RSP.

El único limitante sería el tamaño del cartucho, si te daban uno de 12, de 16 o de 32MB.

Hombre, si una playstation puede, una n64 debería ir mucho mas sobrada... ¿no?, o nos estamos perdiendo algo.

@Señor Ventura
N64 sin usar el RSP.

La versión Saturn tiene ralentizaciones en la parte de los lobos gigantes, cuando derrotas a varios con explosiones por todo el cuerpo, donde además hay 5 planos de scroll.

Esto no significa nada, puede ser mala optimización, pero si que hay varias zonas con "cierta exigencia" que requieren prestar atención, cierta optimización, si se van a hacer de cualquier manera yo aseguraría que no haya ninguna caída en ningún momento.

estuve jugando la versión hack de saturn y arreglaron algunas cosas, lo de las transparencias la verdad que es un alivio. los objetos hechos por polígonos no están tan mal, se ven igual o muy parecido a los de ps1, siendo un aspecto donde esta consola iba mejor. en conclusión si hoy una sola persona pudo hacer esas mejoras, una empresa con 20 personas profesionales con tantos recursos disponibles como que podían haber hecho algo bastante mejor.

el rsp en nintendo 64 es un chip de apoyo? sabia que tenia uno que se hablaba del "vector unit", recién leí un poco sobre el, debe ser el que programaba factor5 en microcódigo, se usa para efectos gráficos y de sonido por lo que entendí, tal vez algunos juegos prescinden de su uso así como pasaba en saturn con alguno de sus chips.

Conker64 escribió:El único limitante sería el tamaño del cartucho, si te daban uno de 12, de 16 o de 32MB.

No se le puede llamar "limitante", pero muchos de los efectos de transparencia del SOTN se verían peor en la N64 por falta de additive blending.

El SOTN lo usaba en muchas transparencias, como las sombras del prota cuando corre o la transformación de Drácula:

cristus escribió:@Paprium en el caso de super nes los chips añaden mas potencia o alguna característica, la consola fue pensada para eso, por eso el slot de cartucho tiene 2 sectores extras para los contactos usados en varios cartuchos con chips extras como el sdd-1, o sea eso forma parte de ella, esta hecho en su época por su empresa de manera oficial, asi como el 32x de megadrive o el mega cd, que se habla mucho de que estos anulaban casi toda la consola, como que no se sumaba, pero bueno son productos oficiales.
que el paprium tenga problemas de rendimiento no me explico, pero que usen colores y sonidos que se asemejen a los de la consola original seguramente es a propósito, mas sabiendo que ese cartucho usa un chipset ARM que se usaba en celulares baratos de hace unos años atrás.

Sería interesante revisar tus creencias antes de soltarlas como verdades absolutas y añadir simple y llana desinformación.

MegaCD no anula en absoluto a la Megadrive. El slot lateral es exactamente igual al de cartuchos y actúa como una expansión sobre la circuitería de Megadrive como cualquier otro chip metido en cartucho. Por eso no suma colores y se ve limitado por el ancho de banda del puerto.

Mega32X tampoco anula en absoluto a la Megadrive. Aunque sí hace un bypass sobre Megadrive teniendo su propia salida de vídeo, puede solapar, y lo hace asiduamente, las capacidades gráficas y sonoras de la Megadrive. Esto es, las suma.

Paprium no utiliza los colores de Megadrive "seguramente a propósito". Paprium, como cualquier otro juego que salga por la salida de vídeo de la Megadrive, usa los colores de la Megadrive de stock porque sigue usando el VDP de Megadrive. Como cualquier otro chip, se ciñe a las capacidades y limitaciones del chip de vídeo de la consola huésped. Lo más que pueden hacer los chips es precocinar las imágenes y servírselas al chip gráfico en un formato que entiendan de antemano. La única manera de saltarse esas limitaciones es meter una salida de vídeo en el cartucho. Todo lo que ves en Paprium lo hace el chip gráfico de Megadrive de stock.

Por último, Megadrive, como casi cualquier otra consola, también tiene pins dedicados en su slot de cartuchos pensados para expansiones externas, mismamente los de audio estéreo que luego puede remezclar con su propio audio. Así es como la GameGear sacaba la imagen de la tele con su sintonizador, sin ir más lejos.

Un saludo.

@riffraff
N64 soporta operaciones de additive blending en el color combiner, no se usa comercialmente porque los colores se voltean, de hecho en esos mismos tests del SOTN lo probé porque era algo que me preocupaba:


Esa zona amarilla debería verse blanca.

Workaround:


Aquí conseguí paliar el defecto, pero trabajando a mano con RGB y solo para efectos azules, la idea sería tener un "buffer controlado", no sé hasta que punto daría el ancho de banda, a pantalla completa, pero ahí está.

De todas formas tienes razón en que en su día simplemente hubieran optado por no usarlo y los efectos se verían más apagados con alpha.

Como tú dices, N64 soporta additive blending, pero dependiendo de los colores origen el resultado es todo lo contrario a lo que se espera, ya que el resultado no se "clampea" (¿cómo se dice eso en español? ).

Para los casos en los que los colores de origen están bajo control, se podría activar, pero por ejemplo para las sombras del prota cuando corre no sería posible activarlo.

Conker64 escribió:@Señor Ventura
N64 sin usar el RSP.

La versión Saturn tiene ralentizaciones en la parte de los lobos gigantes, cuando derrotas a varios con explosiones por todo el cuerpo, donde además hay 5 planos de scroll.

Esto no significa nada, puede ser mala optimización, pero si que hay varias zonas con "cierta exigencia" que requieren prestar atención, cierta optimización, si se van a hacer de cualquier manera yo aseguraría que no haya ninguna caída en ningún momento.

Había entendido que se estaba usando el hardware completo, y que conseguirlo sin el apoyo del RSP era mas bien una estimación... sorry.

riffraff escribió:Como tú dices, N64 soporta additive blending, pero dependiendo de los colores origen el resultado es todo lo contrario a lo que se espera, ya que el resultado no se "clampea" (¿cómo se dice eso en español? ).

Para los casos en los que los colores de origen están bajo control, se podría activar, pero por ejemplo para las sombras del prota cuando corre no sería posible activarlo.

Si no he entendido mal, la cosa es que hay que vigilar que el valor dado no exceda del límite porque en lugar de no ofrecer "resultados nuevos", lo que hace es volver al principio, desde donde incluso ni siquiera partiste, de hecho.

De ahí la idea de un buffer para controlarlo manualmente, aunque no se si sería posible no limitarse al ancho del bus a costa del rendimiento para que el número de valores sea tan alto que puedas despreocuparte, y ni buffers, ni gaitas.

Imagino que he dicho una burrada, podemos zanjarlo con un "ea ea, ya pasó".

xD