Chip FX y juegos que podrían haber salido usando ese sistema.

NO

Añado otro más a la palestra:

Lands Of Lore the throne of chaos.

@gordon81 con los chips de apoyo necesarios hasta la NES. Ojalá lo hubieran hecho.

Podrian haber sacado un monton de Dungeons Crawlers,algunos salieron de todos modos pero eran versiones muy Light,por ejemplo el Dungeon Master,a mi me gustaria que hubiera salido el Dark Savant.

quitando los videos, podria haber salido el resident evil.

Absolutamente. Y a unos buenos 30fps teniendo en cuenta que habría que jugarlo en una ventana para dejar espacio a todo lo demás (me atrevería a decir que mas, pero el límite estaría antes en el ancho de banda que en la capacidad del chip).

Doom es mas complejo de renderizar, y el resultado existente en la consola en realidad es mejorable.

Dejando el doping actual de lado, me quiero centrar exclusivamente en los chips de apoyo oficiales de Nintendo en aquella epoca, así como el SVP.

No quiero convertir esto en un debate de si con un fpga y mierdas similares se puede ejecutar el crysis en una super o una mega o una nes.

Volviendo al tema técnico, yo creo que podrían haber salido grandísimos dungeo crawlers o railcasters como el imprescindible ShadowCaster.

A menor resolución sí, a lo mejor sin las texturas del suelo o el techo como en Doom, pero creo que podría haberse aprovechado muchísimo la tecnología de aquella epoca.

Realmente yo no entiendo mucho de esto, ni sé hasta que punto el chip de super era tan capaz, pero en GBA (sé que era muy superior a snes) había juegos como yo lo llamaba, semi 3D (después había otros que si era 3d, pero yo no hablo de esos) que creo que si podría la la snes perfectamente, por ejemplo el Tekken o mortal kombat o algún juego de coche que explotando el modo 7.





Obviando el modelado de los coches en este.


Está es el de gba, pero en nds tienes los laberintos en 3d, pero esta versión de GBA yo creo que si


Rony




En gba es que creo que hay muchos ejemplos de donde podría llegar el fx de super si lo hubieran explotado y hasta donde podría haber llegar la super.

Por desgracia, estas cosas se suelen quedar en demos o curiosidades del tipo "y si...".

Quiero decir, me encantaría que hubiera más homebrew de calidad y lanzamientos tan locos como el de Paprium para SNES. Sí, existen algunos hacks de mejora de títulos antiguos y demás, pero no veo nada parecido a un proyecto tipo Xeno Crisis o Tanzer en el que no haga falta reventarlo a base de hormonas como a Paprium para SNES.

Espero que la comunidad desarrolladora retro le meta mano a la máquina de Nintendo con títulos de calidad.

@Chuss80 GBA es el "Super 32X" de la Super Nintendo, la 32 bits de entrada.

@Bad Apple pero no va a pasar, la clave es la documentación, salen juegos para MD, Amiga, Master System, Spectrum, pero miras los chips y estamos hablando del M68k y el Z80, quizás los dos chips más populares de la historia y perfectamente documentados. Eso ni pasa ni va a pasar con el de la SNES, salvo milagro del destino.

@eknives Me imagino que ese será uno de los puntos. Pero por otra parte pues extraña que en la época trabajaban más compañías para Nintendo que para cualquier otra y a día de hoy queden tan pocos resquicios de herramientas para hacer algo chulo.

Aunque sea un juego al que no le tengan que meter un SFX o un SA-1, con que vaya a pelo y esté bien diseñado, tendrían aún un público enorme que aseguraría sus ventas.

A este paso sólo veo progreso en plataformas 8 bit y en MD que logran revivir hasta cierto punto esos sistemas. A título personal, me bastaría con un "F-Zero 2" aunque fuese sin licencia y sacando los recursos del primero. Sería suficiente para tirarles los billetes a la cara.

NewDump escribió:NO

Fuera del más que discutible NO sin argumentos, ¿qué tiene que ver ese vídeo con la pregunta que se está haciendo?, ni siquiera es una demo técnica de nada que implique el rasterizado normal que se podía hacer en esa época, es una prueba de raytracing puro con un hard inexistente para la SNES como tal.

Es que no entiendo esa mención al vídeo.

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


Al hilo, por supuesto que SI.

Porque:

1.- La serie de juegos Alone in the Dark está basada en técnicas de imágenes 2D para los fondos, jugando con una perspectiva 3D pero fija, sobre las que se impresionan los modelos 3D del jugador, NPCs, y algunos objetos. El número de triángulos a manejar sin duda es menor que cualquier Firefox, y además incluso están menos texturizados. Así que sería perfectamente posible haber pasado algo del estilo de Alone in The Dark o técnicamente un poco mejor a la SNES (salvando la limitación de la resolución algo menor).

2.- Ultima Underwold. También posible, de hecho está de sobra demostrado que eso podría ser Y MÁS. La existencia de Doom usando el FX2 ya lo prueba, y a pesar de suelos y techos texturizados vs lo viso en DOOM Snes, lo cierto es que con semejante tamaño de ventana, y en general el técnicamente más pulido en cuanto a texturizado y sombreado Doom, o con un alcance de visión netamente más lejano, aún siendo última un juego con un engine un poco más "libre" en cuanto a ángulos y alturas, lo cierto es que requiere menos potencia que Doom.

Es simple ver porqué sí podría ir. Ultima Underworld en PC va bien en un 386, DOOM NO. Y como el FX no deja de ser una cpu generalista a la que se puede adaptar relativamente bien cualquier engine 3d por soft, siempre y cuando no necesite tirar de coma flotante (irá bien con engines que se basen enteros o punto fijo), pues la respuesta es otra vez sí.

3.- Lands of Lore también. En algunos aspectos es más sencillo que Ultima Underworld a pesar de su buen aspecto general. Y también usa un tamaño de ventana muy reducido, con una resolución efectiva bastante baja a renderizar. Hasta se podría mantener o mejorar esa resolución en SNES a costa de modificar el interfaz y hacer que ocupara menos pantalla (usando FX).


El SA1 es otro chip interesante, pero en ese caso habría más dudas. Quizás Alone in the Dark sí, pero no Ultima Underworld. Es una cpu relativamente potente, comparable posiblemente al rendimiento bruto de un 286 a 16-20 MHz (para los que piense que exagero, que recuerden que todas esas cpus usadas por Nintendo de Ricoh están basadas en una arquitectura capaz de ejecutar muchas de sus instrucciones más básicas a ratios de 2-3 ciclos de reloj por instrucción, bastante más rápido que el ratio de un 286 o incluso un 68K). Lands of Lore puede que sí.

Pero vamos, el reto sería mucho mayor en este caso para los juegos "pseudo3D" con uso de texturizado. Potencialmente se podría, pero puede que con algún recorte.

@wwwendigo A mi me gustaría saber ejemplos de juegos basados en engines que requieren de coma flotante para ser procesados.

Para la gente que no tenemos ni idea de estas cosas, intuímos que una capacidad de cálculo para sacar decimales viene bien si necesitas “pasos intermedios” dentro de un frame para añadir precisión a cualquier cosa que quieras representar.

Por ejemplo, wolfenstein 3D podría funcionar a base de enteros porque te mueves sobre dos coordenadas, y la cantidad posible de ellas que determinan tu posición no requiere de tantas variables. Sin embargo doom añade la perspectiva de la altura a la ecuación, y diría que si requiere de coma flotante para poder procesarse mas rápido.


Seguramente sirva para mas cosas.

Señor Ventura escribió:@wwwendigo A mi me gustaría saber ejemplos de juegos basados en engines que requieren de coma flotante para ser procesados.

Para la gente que no tenemos ni idea de estas cosas, intuímos que una capacidad de cálculo para sacar decimales viene bien si necesitas “pasos intermedios” dentro de un frame para añadir precisión a cualquier cosa que quieras representar.

Por ejemplo, wolfenstein 3D podría funcionar a base de enteros porque te mueves sobre dos coordenadas, y la cantidad posible de ellas que determinan tu posición no requiere de tantas variables. Sin embargo doom añade la perspectiva de la altura a la ecuación, y diría que si requiere de coma flotante para poder procesarse mas rápido.


Seguramente sirva para mas cosas.

En realidad no es por eso, es por el proceso de "rasterizado" y de trabajo con las coordenadas 3D. El superFX no trabaja con coma flotante, pero sí puede usar punto fijo (como muchas cpus de esa época, por otro lado), tanto enteros como punto fijo pueden ser válidos para representar gráficos 2D como 3D, pero tienen el problema de una precisión limitada.

Al final, intentando explicarlo de alguna forma, con punto fijo o enteros lo que haces es "cuantizar" cada dimesión por pasos fijos, divides el espacio de juego, bidimensional o tridimensional, en cuadrículas formadas por un "cuanto" mínimo de desplazamiento, digamos que 3 cm reales, siempre es el mismo tamaño, estés cerca o lejos de la cámara. Con coma flotante es distinto, permite definir un rango "variable" y que permite variar esa precisión o "cuanto" mínimo. Es una forma burda de explicarlo. Y eso permite manejar una mayor precisión para "puntos sensibles" y evitar problemas de clipping y errores con la geometría, etc. Esos fallos se hacen más evidentes cuanto más complejo sea el entorno 3D a mostrar. Fuera además que, aún con ya capacidades de coma flotante depende del algoritmo usado para cada tarea, claro. Que las mejoras no vinieron sólo de ser capaz de procesar o no un tipo de datos.

Wolfenstein 3D (y DOOM) tiene la ventaja de trabajar con superficies que siempre están en un ángulo o perpendicular o en paralelo a la superficie del suelo, o si se prefiere respecto al punto de vista de la cámara, están rotando alrrededor de un eje formado por "suelo-cielo" o son parte de estas dos superficies.

Al final esto facilita el trabajo y aumenta mucho la precisión y calidad de las texturas al usar algoritmos de escalado relativamente básicos y fáciles de ejecutar tanto en enteros como con no una carga muy bestia de operaciones. Los sombreados se calculan mucho más fácil en estos casos.

Starfox es un juego plenamente 3D en su engine (bueno, no del todo pero sí en lo básico), pero que no usa coma flotante, y le va bien. Lo que pasa es que es un motor 3D relativamente básico sin sombreados gouraud sino sólidos, etc. Por lo que no le pasa factura la falta de precisión que puede manejar el FX.

Doom no requiere coma flotante, de hecho no mete eso que dices de perspectiva de la altura ¿? (o sea, no hay ningún cambio en cómo funciona el engine en cuanto al uso de la perspectiva y cómo se "calculan" las paredes y objetos, sí existe una mejora clara en el gradiente de sombreados), mete texturizados en suelos/cielos y alguna superficie "escalonada" pero que en realidad se calculan de forma muy similar a cómo se calculan las paredes del "laberinto", o las columnas, etc. Es una vuelta de tuerca de las mismas técnicas que en el Wolf, sólo que más complejas.

De hecho un caso mucho más avanzado que permite usar superficies con ángulos diferentes a perpendiculares/paralelos en superficies, y que el jugador sí se maneja en un entorno pseudo3D de forma más capaz, como Duke Nukem 3d, tampoco necesitaba del uso de coma flotante. Estos juegos eran mucho más exigentes para las cpus pero no exigían coma flotante, por eso iban bastante bien en los 486 de la época y no se hundían si usabas un SX de esta familia.

Sin embargo Quake sí era ya un juego plenamente 3D y que usaba la coma flotante para, por lo menos, el procesado de la geometría (si no me equivoco, no para el texturizado), requería un Pentium para moverse, corría pero era injugable en un 486DX (con una coma flotante mucho más débil, pero mejor que la usada en el combo de 386/387), y directamente ni arrancaba en un 386 (excepto que tuvieras un 387 acoplado, que en dicho caso debería arrancar, aunque para nada funcionar como se espera).

@Señor Ventura Creo que Doom no utilizaba floats en ningún momento (Duke Nukem 3D seguro que no), ID comenzó a usar números de ese tipo en Quake si no recuerdo mal. Usar números en coma flotante es muy lento para un procesador si no tiene coprocesador matemático y por aquella época sólo los 486DX lo tenían si no recuerdo mal.

Lo que usaban eran enteros en coma fija para simular algo parecido a los float.

@Bad Apple ¿Te has mirado los F-Zero de Satellaview? Creo que hay algo interesante por ahí.

eknives escribió:@Bad Apple ¿Te has mirado los F-Zero de Satellaview? Creo que hay algo interesante por ahí.

Esos están bien, pero son muy cortos. A mi también me molaría ver un F-zero 2 completito. Es muy curioso lo que me pasa con ese juego, cuando lo jugué de pequeño no me gustó, lo volví a jugar años después y me enganchó, misterios de la mente humana.

A mí lo qué me mola del chip FX es lo que puede hacer con elementos 2d.
En star Fox en detalles cómo Las partículas y en Yoshi island los sprites enormes y muchos efectos chulos.

Creo que el factor que peor juega en contra de portar juegos como Alone in the Dark, Lands o Lore o el Ultima Underworld son la memoria ram del sistema.

¿qué opináis?

Por cierto, muy bien traido el tema del coma flotante. Estoy ahora mismo con el System Shock de msdos, y ahí recuerdo que mi 486 se hundia, hablamos de un 486sx a 25 mhz.

Otro problema era que la ejecución en modo real de los juegos en msdos estaba muy limitada, la mayoría corrían en modo protegido y eso reducía el rendimiento.

El system shock podría considerarse que ya hablamos de un juego plenamente 32 bits por el uso del extensor dos4gw.

Pero mis sueños húmedos son una snes con todos los chips de apoyo y el soporte cdrom desarrollado por sony, algo así como un amiga 500 con un poco más de músculo, que nos podría haber dado grandes ports.

Si no recuerdo mal tenían pensando un Motorola MC68000 a 10 MHz, por la CPU que finalmente integraron, un Ricoh 5A22 a 3,58 MHz basado en el Motorola WDC65816.

jordigahan escribió:quitando los videos, podria haber salido el resident evil.

Hace unos años hubo un hilo que hablaba justamente de porque no era posible un resident evil en snes tal como salio. Y muchos de los juegos que se mencionan en este mismo hilo van por el mismo lado, si starfox corre como corre, y se ve como se ve, y no tiene poligonos texturizados, a lo mucho algunos modelos con vertex color, como los de final fantasy 7/alone in the dark, pero igual ya es dificil, a lo mas le tiro a juegos como ultima y creo que ya es arriesgarse.


Aqui el hilo

hilo_podria-la-super-nes-o-mega-drive-con-el-resident-evil-1_2073776

NewDump escribió:Si no recuerdo mal tenían pensando un Motorola MC68000 a 10 MHz, por la CPU que finalmente integraron, un Ricoh 5A22 a 3,58 MHz basado en el Motorola WDC65816.

Para nada, de hecho el Ricoh es diametralmente opuesto a lo que es un MC68000 como cpu, no se parecen ni en el color de los ojos, tienen conceptos radicalmente opuestos como cpus CISC. El motorola tiene una arquitectura ortogonal, con una cantidad de registros alta, que tira bastante de microcódigo y demás. El ricoh está basado en una arquitectura centrada en un único registro acumulador genérico (más auxiliares varios), no usa microcódigo para nada, tiene un set de instrucciones más compacto y reducido pero muy rápidas de ejecutar (no usa microcódigo), y es casi como comparar el concepto RISC vs CISC, pero entre dos cpus CISC muy distintas.

El Ricoh 5A22 es una versión del WESTERN DESIGN CENTER WDC65c816, no tiene nada que ver con motorola, de hecho tiene que ver con las cpus de MOS Technology, y que es una evolución de justo el 6502 ya visto en la NES normal (sólo que a mayor frecuencia, en 16 bits nativos, y alguna mejora extra).

Dudo mucho que se plantearan ningún 68K para la SNES cuando el uso del Ricoh está claro que favorece el portado de código de juegos de NES a SNES, facilitando mucho la tarea para los desarrolladores acostumbrados a NES, y la reutilización de código con pocas alteraciones ya existente en las "librerías" de cada desarrolladora. No hay que olvidar que entonces básicamente se escribía todo en ensamblador, y por tanto el código estaba muy unido a la arquitectura de la cpu y sus puntos fuertes. Portar código para la línea de cpus que derivan del MOS 6502 es más o menos fácil, partiendo de él, pero en el caso del 68K de motorola, implica en muchos casos escribir de cero cada rutina, otra vez.

wwwendigo escribió:

NewDump escribió:Si no recuerdo mal tenían pensando un Motorola MC68000 a 10 MHz, por la CPU que finalmente integraron, un Ricoh 5A22 a 3,58 MHz basado en el Motorola WDC65816.

Para nada, de hecho el Ricoh es diametralmente opuesto a lo que es un MC68000 como cpu, no se parecen ni en el color de los ojos, tienen conceptos radicalmente opuestos como cpus CISC. El motorola tiene una arquitectura ortogonal, con una cantidad de registros alta, que tira bastante de microcódigo y demás. El ricoh está basado en una arquitectura centrada en un único registro acumulador genérico (más auxiliares varios), no usa microcódigo para nada, tiene un set de instrucciones más compacto y reducido pero muy rápidas de ejecutar (no usa microcódigo), y es casi como comparar el concepto RISC vs CISC, pero entre dos cpus CISC muy distintas.

El Ricoh 5A22 es una versión del WESTERN DESIGN CENTER WDC65c816, no tiene nada que ver con motorola, de hecho tiene que ver con las cpus de MOS Technology, y que es una evolución de justo el 6502 ya visto en la NES normal (sólo que a mayor frecuencia, en 16 bits nativos, y alguna mejora extra).

Dudo mucho que se plantearan ningún 68K para la SNES cuando el uso del Ricoh está claro que favorece el portado de código de juegos de NES a SNES, facilitando mucho la tarea para los desarrolladores acostumbrados a NES, y la reutilización de código con pocas alteraciones ya existente en las "librerías" de cada desarrolladora. No hay que olvidar que entonces básicamente se escribía todo en ensamblador, y por tanto el código estaba muy unido a la arquitectura de la cpu y sus puntos fuertes. Portar código para la línea de cpus que derivan del MOS 6502 es más o menos fácil, partiendo de él, pero en el caso del 68K de motorola, implica en muchos casos escribir de cero cada rutina, otra vez.

https://retrocomputing.stackexchange.co ... 68000-snes

Del chip FX lo que más miedo me da es que aparezca algún super villano (es super villano porque es un villano que programa para la Super) y castigue al mundo con un Stunt Race 2.

Lo del stunt race fue un insulto, pero con overclock mejora algo, solo un pelín.

Supongo que el modo de trabajo es SA1+FX y dejar al ricoch para temas como IA, porque otra cosa no se me ocurre con el pedazo cuello de botella que podía generar la cpu principal de snes.

NewDump escribió:

wwwendigo escribió:

NewDump escribió:Si no recuerdo mal tenían pensando un Motorola MC68000 a 10 MHz, por la CPU que finalmente integraron, un Ricoh 5A22 a 3,58 MHz basado en el Motorola WDC65816.

Para nada, de hecho el Ricoh es diametralmente opuesto a lo que es un MC68000 como cpu, no se parecen ni en el color de los ojos, tienen conceptos radicalmente opuestos como cpus CISC. El motorola tiene una arquitectura ortogonal, con una cantidad de registros alta, que tira bastante de microcódigo y demás. El ricoh está basado en una arquitectura centrada en un único registro acumulador genérico (más auxiliares varios), no usa microcódigo para nada, tiene un set de instrucciones más compacto y reducido pero muy rápidas de ejecutar (no usa microcódigo), y es casi como comparar el concepto RISC vs CISC, pero entre dos cpus CISC muy distintas.

El Ricoh 5A22 es una versión del WESTERN DESIGN CENTER WDC65c816, no tiene nada que ver con motorola, de hecho tiene que ver con las cpus de MOS Technology, y que es una evolución de justo el 6502 ya visto en la NES normal (sólo que a mayor frecuencia, en 16 bits nativos, y alguna mejora extra).

Dudo mucho que se plantearan ningún 68K para la SNES cuando el uso del Ricoh está claro que favorece el portado de código de juegos de NES a SNES, facilitando mucho la tarea para los desarrolladores acostumbrados a NES, y la reutilización de código con pocas alteraciones ya existente en las "librerías" de cada desarrolladora. No hay que olvidar que entonces básicamente se escribía todo en ensamblador, y por tanto el código estaba muy unido a la arquitectura de la cpu y sus puntos fuertes. Portar código para la línea de cpus que derivan del MOS 6502 es más o menos fácil, partiendo de él, pero en el caso del 68K de motorola, implica en muchos casos escribir de cero cada rutina, otra vez.

https://retrocomputing.stackexchange.co ... 68000-snes

Menuda mierda indocumentada que me has puesto. Lo siento, pero son tonterías (y no hay forma suave de decirlo, en serio que flipo con esa "información"). El Ricoh NO tiene nada que ver con el 68K, y todo el que sepa un POCO a nivel técnico sobre cpus, sabe qué pedazo de mierda es esa "información". Pero vamos a ver, si se basa en una web ya inexistente de segeros, ¿qué me estás contando?

Dice auténticas gansadas, esa cpu era sustancialmente más rápida que la de la NES, y no es esa extraña solución que se inventan no se sabe ni porqué, y en realidad era de similar velocidad a la 68K o incluso más si nos atenemos a la velocidad a la que se ejecutan la mayoría de instrucciones (2-3 ciclos de reloj vs 4-8 en el 68K).

Pero mira, lo tienes fácil. Te coges un manual de ensamblador de ambas cpus, miras un poco su diagrama de su arquitecturas con sus registros y tal, y después coges y borras de tu barra de favoritos ese bodrio que has linkado.

Bad Apple escribió:@eknives Me imagino que ese será uno de los puntos. Pero por otra parte pues extraña que en la época trabajaban más compañías para Nintendo que para cualquier otra y a día de hoy queden tan pocos resquicios de herramientas para hacer algo chulo.

Aunque sea un juego al que no le tengan que meter un SFX o un SA-1, con que vaya a pelo y esté bien diseñado, tendrían aún un público enorme que aseguraría sus ventas.

A este paso sólo veo progreso en plataformas 8 bit y en MD que logran revivir hasta cierto punto esos sistemas. A título personal, me bastaría con un "F-Zero 2" aunque fuese sin licencia y sacando los recursos del primero. Sería suficiente para tirarles los billetes a la cara.

No debería de extrañarte nada, el homebrew al final es gente, la mayoría aficionada, que dedica su tiempo libre a programar juegos, con suerte se junta un par y lanzan un juego bajo el nombre de una desarrolladora indie-pequeña. Si tú quisieras aprender a hacer un juego y lanzarlo al público optarías por una consola cuya documentación existe y cuya programación es más amigable a la hora de conseguir sacarle jugo o irías por el frankestein donde programar para conseguir lo mismo que en otra consola lleva el doble o triple de curro?

La scene al final va a a lo "fácil" salvo por algunos berserkers que van a pecho descubierto por cosas jodidas como Saturn. Pero la mayoría va a ir donde la información o kits de desarrollo están ya listos para aprender y usar y dentro de estos por sistemas populares (NES, MD, Spectrum, etc). Los berserkers suelen conseguir cosas que se menosvaloran porque la gente esperan que, pese al reto que asumen, consigan sacar de la consola virguerías mucho mejores que los mejores juegos del catálogo. Así que la mayoría también queda hasta los huevos del poco apoyo y mérito que reciben y abandonan.

Así tienes que en Saturn se le da poca importancia a los avances el motor gráfico z-treme o sus demos de Sonicy FPS-Quake

Mira los likes que tienen esos vídeos y mira los que reciben cualquier juego homebrew de NES o MD que hacen lo mismo que todos los del catálogo original.

Entonces tienes que consolas como DC tiene más scene que PS2 pese a que esta es más potente. También influye la comunidad de jugadores retro-activos dispuestos a apoyar proyectos claro, cualquier cosa que saquen ahora mismo para NES o MD con que sea algo promedio va a tener suficientes ventas aseguradas en reserva, en cambio un juego nuevo para PS1 o PS2 no. De todas formas va por rachas, hace 10 años cualquier novedad homebrew de DC se celebraba como si SEGA volviese al hardware, en cambio ahora ha recibido bastantes juegos y están pasando todos más desapercibidos, ahora la moda es Megadrive supongo.

Sobre la documentación de SNES, si el "berserker" no se rinde y lo deja a medias, hay pequeña comunidad trabajando en investigarla y publicar documentación para futuros desarrolladores. Pero esto lleva mucho tiempo, piensa que MD se comió los mocos casi sin homebrew durante décadas hasta que hace unos años se publico la documentación tras varios años investigándola y en este caso era una consola con un Z80 y un M68 bien conocidos ya y una arquitectura más simple. Y tras las documentación habría que hacer herramientas, etc. Si no lo abandonan pueden pasar un año o diez hasta que terminen. De todas formas en SNES en el catálogo japonés tienes "homebrew" para aburrir, quieres un beat'm up: Rushing Beat Shura (el japonés, no el americano) o Undercover Cops, quieres un RPG: Rudra no Hihou, Romacing Saga 1 y 3, New Horizons, G-O-D, etc. Run&Gun: The Great Batle IV y V.

gordon81 escribió:Lo del stunt race fue un insulto, pero con overclock mejora algo, solo un pelín.

Supongo que el modo de trabajo es SA1+FX y dejar al ricoch para temas como IA, porque otra cosa no se me ocurre con el pedazo cuello de botella que podía generar la cpu principal de snes.

No se ahora mismo los motivos exactos por los que eso no es posible (los he leído, pero ya se me ha olvidado), aunque si se que no puedes usar el SA-1 con una rom que no sea slow rom porque aunque parezca mentira la frecuencia de trabajo externa del chip causa menos esperas por una mera cuestión de multiplicidad con las frecuencias.

Al super FX sin embargo lo matas si usas una slow rom (y aquí me estoy tirando el pegote porque en realidad no puedo afirmarlo, ni debería haberlo hecho), así que podría decirse que son un poco incompatibles para trabajar juntos. Otra cosa hubiera sido un super FX como PPU3.

10$ le hubiera costado a nintendo meter ese procesador como parte del sistema de vídeo... un puto procesador de proposito general con capacidad para tocar todo lo que haya en la memoria de vídeo. Imagina la cantidad de postprocesamiento que hubiese podido salir de ahí...


P.D: Asumimos que no hubiese tenido acceso a la WRAM, y por lo tanto tampoco hubiera podido operar junto con la cpu, o al menos no directamente...

wwwendigo escribió:

NewDump escribió:Si no recuerdo mal tenían pensando un Motorola MC68000 a 10 MHz, por la CPU que finalmente integraron, un Ricoh 5A22 a 3,58 MHz basado en el Motorola WDC65816.

Para nada, de hecho el Ricoh es diametralmente opuesto a lo que es un MC68000 como cpu, no se parecen ni en el color de los ojos, tienen conceptos radicalmente opuestos como cpus CISC. El motorola tiene una arquitectura ortogonal, con una cantidad de registros alta, que tira bastante de microcódigo y demás. El ricoh está basado en una arquitectura centrada en un único registro acumulador genérico (más auxiliares varios), no usa microcódigo para nada, tiene un set de instrucciones más compacto y reducido pero muy rápidas de ejecutar (no usa microcódigo), y es casi como comparar el concepto RISC vs CISC, pero entre dos cpus CISC muy distintas.

El Ricoh 5A22 es una versión del WESTERN DESIGN CENTER WDC65c816, no tiene nada que ver con motorola, de hecho tiene que ver con las cpus de MOS Technology, y que es una evolución de justo el 6502 ya visto en la NES normal (sólo que a mayor frecuencia, en 16 bits nativos, y alguna mejora extra).

Dudo mucho que se plantearan ningún 68K para la SNES cuando el uso del Ricoh está claro que favorece el portado de código de juegos de NES a SNES, facilitando mucho la tarea para los desarrolladores acostumbrados a NES, y la reutilización de código con pocas alteraciones ya existente en las "librerías" de cada desarrolladora. No hay que olvidar que entonces básicamente se escribía todo en ensamblador, y por tanto el código estaba muy unido a la arquitectura de la cpu y sus puntos fuertes. Portar código para la línea de cpus que derivan del MOS 6502 es más o menos fácil, partiendo de él, pero en el caso del 68K de motorola, implica en muchos casos escribir de cero cada rutina, otra vez.

De hecho, para la profundidad que tenía el software de estas máquinas, un 65816 a 10mhz tiene que rendir mas que un 68000 a 10mhz.

Lo del 68000 para la snes es un bulo, pero me pregunto si no se les pasó poner un 65816 a mas frecuencia... aunque deduzco que siendo tan dependiente de su pipeline, se les tuvo que quitar las ganas al tener que incluir también una WRAM a 10mhz y una ROM a 10mhz para que el esfuerzo de meter semejante procesador tuviese sentido. Gastarse el dinero en meter un 65816 a 10mhz para mantener la WRAM a 2,68mhz, es tirar a la basura los presupuestos ^^u


Lo que hubiera sido una snes con semejante configuración... 65816 a 10mhz, WRAM a 10mhz, ROM a 10mhz, multiplicaciones del PPU1, super FX a 21mhz como PPU3...

¿Hubiera sido contraproducente incrementar el precio final a cambio de esas prestaciones?, ¿cuanto hubiera supuesto para el precio final?. Solo el super fx eran 10$, pero el resto de componente no tengo ni idea de en que precios se movían...

eknives escribió:@Chuss80 GBA es el "Super 32X" de la Super Nintendo, la 32 bits de entrada.

@Bad Apple pero no va a pasar, la clave es la documentación, salen juegos para MD, Amiga, Master System, Spectrum, pero miras los chips y estamos hablando del M68k y el Z80, quizás los dos chips más populares de la historia y perfectamente documentados. Eso ni pasa ni va a pasar con el de la SNES, salvo milagro del destino.

en absoluto,la gba no creo que pueda con un virtua racing deluxe,darxide o star wars arcade

@crazy2k4 tampoco se intentó. Pero si que hizo sus pinitos en 3D y salieron cosas superiores a un super FX.







P.D: No olvides Asterix XXL, Driver 2 o V-Rallly porque ahí si que no he visto nada similar en 32X.

@eknives ostras,pues el hot wheels me ha sorpendido,jaja
igual si que podria mover algo potente en condiciones

crazy2k4 escribió:en absoluto,la gba no creo que pueda con un virtua racing deluxe,darxide o star wars arcade

La cpu de la GBA fué uno de los famosos “chips de apoyo” de la snes.

Estaría bueno que una snes con un chip de apoyo fuese superior a todo un add on. Aún así, no te comas de vista a ese procesador.

@crazy2k4 GBA creo que salió en un mal momento y se pusieron las expectativas muy altas. Hot Wheels es un juego que muestra que se pudo hacer más. Yo sin embargo, cuando la tuve solía estar "frustrado" porque veía los need for speed o Galaxy on fire de j2me y sentía que me habían estafado con la potencia de la consola o que nadie sabía aprovecharla. También el 3D de GBA era muy sucio, siempre en plan sprites en un plano cuando realmente podía usar poligonos, nadie se curró un buen engine.

eknives escribió:@crazy2k4 GBA creo que salió en un mal momento y se pusieron las expectativas muy altas. Hot Wheels es un juego que muestra que se pudo hacer más. Yo sin embargo, cuando la tuve solía estar "frustrado" porque veía los need for speed o Galaxy on fire de j2me y sentía que me habían estafado con la potencia de la consola o que nadie sabía aprovecharla. También el 3D de GBA era muy sucio, siempre en plan sprites en un plano cuando realmente podía usar poligonos, nadie se curró un buen engine.

yo recuerdo el iridion 3d,y se veia muy bien la verdad

Señor Ventura escribió:

crazy2k4 escribió:en absoluto,la gba no creo que pueda con un virtua racing deluxe,darxide o star wars arcade

La cpu de la GBA fué uno de los famosos “chips de apoyo” de la snes.

Estaría bueno que una snes con un chip de apoyo fuese superior a todo un add on. Aún así, no te comas de vista a ese procesador.

El chip de la GBA es de 32bits ¿Que chip de apoyo de snes es de esa arquitectura?

@crazy2k4 precisamente otra muestra de buen hacer, aunque siempre me pareció una demo técnica ¿Ves? Eso es lo que jode, creo que era casi un juego de inicio, ves eso y esperas que los juegos evolucionen, que vayan a más, no a menos, grrrr.

@eknives

ST010 se usa para funciones generales y para manejar la IA de los autos oponentes en F1 ROC II: Race of Champions. Contiene una CPU NEC µPD960507​21​ configurada a una frecuencia de reloj de 10 MHz

ST011 se utiliza para la funcionalidad de IA en el juego de mesa shogi Hayazashi Nidan Morita Shogi. También utiliza un NEC µPD96050.12​ cronometrado a 15Mhz

ST018 se usa para la funcionalidad de IA en Hayazashi Nidan Morita Shogi 2. Es un procesador ARMv3 de 32 bits a 21,47 MHz.


El tercero es el que lleva la cpu de la GBA, pero incluso mas rápido que en esta. 1995.

@Señor Ventura es un ARMv3, aún siendo un ARM6, está por debajo de un ARM7. Igualmente, estás especulando sobre un chip sin toda la documentación.

Señor Ventura escribió:Estaría bueno que una snes con un chip de apoyo fuese superior a todo un add on. Aún así, no te comas de vista a ese procesador.

Pues viendo el chip de apoyo puedes incluso quitar a la snes de la frase De todas formas, eso solo muestra una cosa en caso de que sea el mismo procesador pero a más mhz, el "chip de apoyo" no es apoyo un carajo, es toda una GBA que por si misma ya es una consola. Y la GBA es mucho más potente que la snes.

Edit: acabo de leer la wiki ¿De donde coño sacas que sea el mismo chip?

no se donde le ve la gente el merito a juegos como final fantasy 7 o resident evil, si le quitas los videos solo tienes que poner una foto de fondo en pantalla y cuatro poiigons con forma de personaje que se mueve....

sobre stunt race, creoq ue es un juego incomprendido que salio con prisas para intentar para a virtua racing, creo que con mas tiempo hubiera salido algo mucho mejor, no hay mas que ver esta demo en una gameboy !
https://www.youtube.com/watch?v=SRey8TvbFiA

@jordigahan me hace acordar a éste: que por cierto lo prefiero al Stunt Race FX.

jordigahan escribió:no se donde le ve la gente el merito a juegos como final fantasy 7 o resident evil, si le quitas los videos solo tienes que poner una foto de fondo en pantalla y cuatro poiigons con forma de personaje que se mueve....

Pues la propia PSX no podía del todo bien con esos cuatro polígonos sobre la foto, sin los conocidos errores de cálculo del posicionamiento 3D:



Aunque parezca 3D sobre 2D, es al revés. Lo que pasa es que el escenario 3D no lo han creado, y en su lugar han puesto esa textura de fondo. Los personajes se mueven en 3D (se acercan, se alejan, rotan...), como si hubiera un entorno 3D ahí, y ya te digo la PSX en algunos casos no podía calcular esos polígonos, causando deformaciones.

Teniendo eso en cuenta, si ya era más complicadete de lo que parece para PSX, para SNES+SFX es fácil vislumbrar el posible bodrio visual que saldría de ahí.

Me encantan estas pajas mentales en general.

eknives escribió:@Señor Ventura es un ARMv3, aún siendo un ARM6, está por debajo de un ARM7. Igualmente, estás especulando sobre un chip sin toda la documentación.

ARM7 no es ARMv7.

ARM7TDMI:
Instruction set ARM (32-bit) (ARMv3)
https://en.m.wikipedia.org/wiki/ARM7

eknives escribió:Pues viendo el chip de apoyo puedes incluso quitar a la snes de la frase

Peeeeeeero, luego los juegos del 32x son juegos de megadrive. No solo juegos de su catálogo, sino también de la consola.

xD

eknives escribió:De todas formas, eso solo muestra una cosa en caso de que sea el mismo procesador pero a más mhz, el "chip de apoyo" no es apoyo un carajo, es toda una GBA que por si misma ya es una consola. Y la GBA es mucho más potente que la snes.

El super fx también es mas potente.

Ahora si un chip es demasiado potente no debe considerarse... ¿hacemos como si no existiese?.

Se usan solo para gestionar la IA, ¿hacemos como si todo lo demás del juego, que es casi todo, y está procesado por la snes, no existiese tampoco?.

¡Viva el virtua fighter de megadrive!... no, pero esto no, que ya es mas potente que una super nintendo (aunque no se use para procesar el propio juego en si).

@Señor Ventura gracias por la aclaración del set de instrucciones del núcleo, aún así ¿Sabes si lo usan íntegro o parcialmente? ¿Usaron en Nintendo (se supone que ellos diseñaron el chip de gba o es otra mentira de la gran N) el diseño que creó SETA? Valoraremos tu experiencia como ingeniero en aquel momento de la industria. Seguimos sin ver la misma nomenclatura en ambos chips aún estando basados supuestamente en el mismo set.

Respecto a los juegos de 32X, yo siempre he dicho que necesitas una mega para acceder al catálogo del 32X y que dicho artefacto no es una consola por si misma (no está completa) es un add on, la md es un ecosistema en ese sentido. Y respecto a considerar si es un juego o no del sistema, creo que no he dicho nada, si le hacen bypass a la consola, eso lo dijo Argonaut, ya ves tú.

Para seguir, has venido a buscar la polémica de siempre, pero en realidad no podías haber sido más torpe, te explico porqué. Nunca he visto a nadie embarrar más a dos consolas de Nintendo. Las conclusiones que se pueden extraer:

1. La snes vino tan mal diseñada y tan corta de potencia que había que meter una consola en el cartucho para mover juegos un poquito mejores. Y no metes una consola en el cartucho para no usarla y menos en esa época que era "tecnología punta" ¿No es la snes tan perfecta? ¿Para qué coño necesita tanto chip adicional?

2. La gba es tan mierder que hasta los "chips con consola integrada" de los cartuchos de snes eran un 33% más potentes. Ese dato lo has sacado tú a relucir al hablar de los mhz. Lo has rematado con que el super fx también es más potente que la gba de tu post anterior.

En fin, Nintendo vendiendo mierda a precio de oro. Gracias por la aclaración Señor Ventura. Nintendo agradece que dejes tu puesto de policía.

eknives escribió:@Señor Ventura gracias por la aclaración del set de instrucciones del núcleo, aún así ¿Sabes si lo usan íntegro o parcialmente? ¿Usaron en Nintendo (se supone que ellos diseñaron el chip de gba o es otra mentira de la gran N) el diseño que creó SETA? Valoraremos tu experiencia como ingeniero en aquel momento de la industria. Seguimos sin ver la misma nomenclatura en ambos chips aún estando basados supuestamente en el mismo set.

Respecto a los juegos de 32X, yo siempre he dicho que necesitas una mega para acceder al catálogo del 32X y que dicho artefacto no es una consola por si misma (no está completa) es un add on, la md es un ecosistema en ese sentido. Y respecto a considerar si es un juego o no del sistema, creo que no he dicho nada, si le hacen bypass a la consola, eso lo dijo Argonaut, ya ves tú.

Para seguir, has venido a buscar la polémica de siempre, pero en realidad no podías haber sido más torpe, te explico porqué. Nunca he visto a nadie embarrar más a dos consolas de Nintendo. Las conclusiones que se pueden extraer:

1. La snes vino tan mal diseñada y tan corta de potencia que había que meter una consola en el cartucho para mover juegos un poquito mejores. Y no metes una consola en el cartucho para no usarla y menos en esa época que era "tecnología punta" ¿No es la snes tan perfecta? ¿Para qué coño necesita tanto chip adicional?

2. La gba es tan mierder que hasta los "chips con consola integrada" de los cartuchos de snes eran un 33% más potentes.

En fin, Nintendo vendiendo mierda a precio de oro. Gracias por la aclaración Señor Ventura. Nintendo agradece que dejes tu puesto de policía.

Lo siento y sin pretender de hacer de moderador, este mensaje se sale de la temática del hilo que es puramente técnica.

Aquí no se debate el doping ni actual ni futuro, es un topic técnico y las pasiones y sentires es mejor dejarlas de lado.

Ya me cerraron otro topic por estas cosas que se salen de madre y me jodió bastante, porque era técnico y siempre lo mismo que si guerra etc.

Centrémonos en discutir lo que podía o no podía hacer el FX, si quieres el SVP, el SA1, pero pontificar, descalificar comentarios sin aportar nada técnico y virar el topic a una discusión harto estéril ya se ha hecho en miles de topics.

@gordon81 el post anterior del Sr. Ventura se pasa más tiempo hablando de Sega y el 32X que el mío, ya estaba desvirtuado ahí. Pero aquí es donde se abandona la temática:

Señor Ventura escribió:

crazy2k4 escribió:en absoluto,la gba no creo que pueda con un virtua racing deluxe,darxide o star wars arcade

La cpu de la GBA fué uno de los famosos “chips de apoyo” de la snes.

Estaría bueno que una snes con un chip de apoyo fuese superior a todo un add on. Aún así, no te comas de vista a ese procesador.

Que es ganas de buscar flamming.

Yo saqué a colación la gba como supuesto de posibilidad real de "32 bits" para snes y hasta donde se podría llegar. Incluso en primera instancia yo estaba defendiendo que la gba no es necesariamente inferior a un 32X.

Piensas que una gba es más potente que una snes?

@NewDump sí.

@eknives Ninguna gana de buscar flame. Es una respuesta obligada a tu comentario porque realmente existe ese pensamiento, y antes de que pueda decirse nada mas al respecto de la cpu de la gba en un cartucho de la snes, creo que viene bien recordar el caso de una 32x para que no se enrede con eso, ya que efectivamente hay quien lo considera legítimamente una megadrive.

Y si esto es así, entonces sobran las palabras. Sigamos con el hilo.



Sobre esa cpu, como mínimo tiene similitudes sospechosas. Tampoco parecen haber vertientes de ese chip derivados en mas productos, mas allá de la frencuencia, así que en un principio sería como mínimo bastante parecido a la cpu de la gba.

@eknives

La mayoria de los juegos de GBA está programados usando el modo THUMB del ARM (juego instrucciones reducido de 16bit).. solo maneja unos pocos registros de 32bits.
El bus a RAM y OAM son de 32bits pero el de los cartuchos ROM es de 16 bits. Aun asi, el ARM no puede trabajar en modo ARM 32bit y THUB simultaneamente.

@beertop