Freestate escribió:Muy interesante lo que reseñas. Cambiamos el argumento pues. Cuales serian tu los que no habria manera de hacerlos en snes? O tiraras por el ordago de que absolutamente todos serian factibles? Supongo que los del superfx salen de la lista.
Es posible que
ballz 3D funcionase con bastante mal rendimiento sin un DSP. Es un juego que usa un plano en modo 7, así que no puedes usar el ppu1 a modo de coprocesador matemático para cálculos en coma flotante. Sin embargo, una versión como la de megadrive, prescindiendo del plano en modo 7 exactamente igual que esta, con seguridad funcionaría exactamente igual de bien porque tienes disponible precisamente esos cálculos extras, y es que hablamos de una cantidad bastante remarcable de potencia adicional.
Exhaust heat II lleva un procesador a 10mhz para controlar la IA de los oponentes. Es de cajón que si se lo enchufas a la cpu te vas a cargar el rendimiento. Otra cosa es si se nota esa IA, pero estas cosas puedes definirlas manualmente mediante una base de datos, y a correr... pero, no, sin chip de apoyo no podría procesarlo con la misma rapidez.
En realidad poquitos juegos que usen un DSP o un SA-1 se escapan de las posibilidades de la snes.
-El
gradius III necesita el SA-1 para funcionar bien, pero es que hablamos de un juego con una optimización pobremente planificada, hay una sobre redundancia bastante exagerada calculando colisiones innecesarias.
-El
jikkyou oshaberi parodius parece usar el SA-1 especialmente para descomprimir datos de la ROM y así no tener que usar una mas grande. Seguramente haga otras cosas como apoyo a la cpu, pero la acción en pantalla no es muy diferente de la de los otros dos parodius (que no llevan chip), así que dudo que no pudiera hacerse sin el SA-1 usando una ROM mas grande (que para eso la snes puede direccionarlas).
-Los
mega man x2 y x3 funcionan el 99% del tiempo ajenos al chip CX. Con eso está todo dicho... eso, y que no tengo tan claro que los vectores que tiene que calcular no pudieran hacerse por otros métodos, o calculándolos mediante el ppu1.
Por cierto...
Estoy leyendo que
Super mario RPG y los dos
Kirbys podrían haber usado el SA-1 para programarlos usando C puro y ahorrarse los plazos de optimización.
txefoedu escribió:Un suponer, si un juego con chip de apoyo se podía programar en 10.000 horas de trabajo para que fuera fluido, pero sin chip hay que optimizar código y dedicarle mucho más tiempo, tal vez les merecía la pena meterle un chip, que el juego saliera antes y que su desarrollo fuera más barato, aunque producir el cartucho iba a subir algo de precio por llevar chip extra. Tel vez lo compensaban con el marketing de "ojo que este juego lleva un chip especial para potenciar tu SNES"
Me parece una conclusión correcta.
A los costes de tiempo de desarrollo reducidos le sumas los costes de hardware adicional en el cartucho, y tras un cálculo de gastos a lo mejor te sale mas a cuenta que optimizar y alargar los tiempos de desarrollo.
Y además añades colateralmente el factor antipirateria de sacar a la venta un juego que los copiones no pueden reproducir
Todo esto en suma, me parece plausible.
txefoedu escribió:Los juegos que usan chip para descomprimir gráficos, entiendo que más que como medida antipiratería lo harían porque sería más barato meter un chip extra para esa función (Street Fighter Alpha 2 sería el ejemplo más conocimos en su época), que meter ROMs más grandes. Si además con ello evitaban la piratería, mataban dos pájaros de un tiro.
Hace poco han destripado el código de este juego, y la conclusión es que no pasó por la fase de optimización.
Código sucio, usa casi exclusivamente C en lugar de ASM, driver de sonido infame que provoca congelamientos... un desastre, y aún así funciona....
Pues no se lo pensaron dos veces, y lo sacaron a la venta, pero es un juego mejorable. De hecho han pulido un poco el driver de sonido, y adios parones. Sigue teniendo problemas con sonidos que no se reproducen siempre, pero es que es eso... un port bastante negligente (en contra de la voluntad de los programadores casi con total seguridad, vaya eso por delante).
Es un juego que podría acercarse mucho mas a la versión playstation. No puedo saber si esto podría ser así en cuanto a tamaño de los personajes (porque para eso necesitas mas tiempo de DMA, y es una incógnita cuanta cpu necesitas tras optimizar), pero como mínimo las animaciones las podría incluir todas, y los efectos de sonido, o mejorar las músicas, también está al alcance.
La velocidad del juego con algún modo turbo adicional también
txefoedu escribió:https://youtu.be/pmJyQiL9wYg?t=118
El gradius III es un caso especial. Implementaron la compatibilidad con el SA-1 para corregir mediante fuerza bruta una falta de optimización flagrante... que ya no es solo falta de optimización, sino que para rematarlo usa una slow rom que obliga a la cpu a bajar hasta los 2,68mhz (un 30% menos de su velocidad real, así, porque si).
Seguramente encuentres el documento usando google si lo buscas un poquito. Expusieron mediante una gráfica cuantos puntos de colisión detecta el juego a cada frame, y con cuantos podría hacerse para el mismo resultado... y la diferencia no es ni siquiera grande, es ENORME.
Por un lado bajas la frecuencia de la cpu, y por otra la sobrecargas de cálculos que no necesitas calcular. Aún con esas el SA-1 se lo come con patatas, pero es un juego que no debería tener un rendimiento tan nefasto usando solo la cpu de la snes. De hecho, obligando a que funcione a 3,58mhz ya corrige la mayoría de las ralentizaciones, aún a pesar de que la falta de optimización sigué presente.
![[qmparto]](/images/smilies/net_quemeparto.gif "Que me parto!")
![[+risas]](/images/smilies/nuevos/risa_ani3.gif "más risas")
![[oki]](/images/smilies/net_thumbsup.gif "Ok!")
![[bye]](/images/smilies/nuevos2/adio.gif "adios")
