Tan dificil es programar para SNES?

No hace mucho me preguntaba lo mismo, seguiré este hilo con atencion

No soy ningun guru, pero esta clarisimo que actualmente existe una scene muchisimo mayor de otras consolas, en especial Megadrive

A mi gusto, y es mi opinion, en parte es devido a la dificultad de programar, la falta de buenas herramientas, y la complejidad del sistema.

En todo caso, existe un SDK bastante simple, snesc, y no es dificil de hacer cosas simples para snes.

Hace un tiempo, creo q habia programado un ejemplo cutrisimo de un sprite, el problema radicaba en la dificultad de hacer graficos, devido a la falta de buenas herramientas

http://www.dream-comics.jazztel.es/Dream/Megadrive/Ejemplos/SNES/sonic.zip


Como dije, no tengo mucha idea de SNES, asi q seguro cualquier otra persona, te dara una contestacion mejor

Pero por ejemplo me pregunto.Las desarrolladoras oficiales no tenian un sdk o en aquellos tiempos se programaba a pelo sin ayuda,cada una con sus propias herramientas y con las specificaciones tecnicas de la maquina y ya?.No hay ninguna herramienta por ahi de alguna desarrolladora que se haya filtrado o liberado algun engine?

No hay nada de nintendo como tal filtrado o desarrolladora pasa SNES que yo sepa, si en cambio hay software de SN para N64

Veamos, la SNES es infinitamente más compleja que cualquiera de sus competidoras contemporáneas, incluso que la NeoGeo, a nivel de programación

Primero, tienes que tener en cuenta que hay tres buses distintos, cada uno a una velocidad distinta, con lo que ya sólo por eso la dificultad es mucho mayor

Segundo, hay ocho modos distintos de gráficos, con lo que tienen que documentar una mayor cantidad de información, y la dificultad aumenta para poder trabajar con cada modo completamente distinto y con distintas capacidades. En la MD hay sólo cuatro modos: modo 4 (usado en retrocompatibilidad por la SMS, nunca en modo MD, aunque sí es accesible) y modo 5 (modo nativo de la MD), pudiéndose configurar a progresivo o entrelazado, con el único cambio de la resolución, estando además basados en el TMS9918A, por lo que se conocía bastante bien su funcionamiento

Tercero, la CPU de la SNES es mediocre tirando por lo alto. Es muy lento (3,6MHz), y además es de 16 bits frente a los 32 bits y los 7,6MHz de la MD, por ejemplo, y además ten en cuenta que un 68000 tal cual es mucho más sencillo de gastar que un ASIC especial de Nintendo

Cuarto: como la CPU es más lenta, muchas veces se necesita un coprocesador de apoyo (como el chips de descompresión o mappers, o incluso el famoso Super FX), con lo que además tienes que aprender a manejar estos addons

Quinto: el audio está controlado por un ASIC especial también, en lugar de por un procesador normal y corriente (el Z80 en la MD, aunque el 68k también tiene acceso directo al audio)

Sexto: hace falta un chip de CIC, lo que requiere usar un PIC, encareciendo el coste de la producción del cartucho, o modificar la consola internamente, difícil para quien no sabe de esto. En la MD sólo hay que realizar una simple escritura ("SEGA" al registro $A10000, conocido como TMSS), y además hay un registro que indica el tipo de consola, por lo que el programa se puede adaptar automáticamente a la versión de la consola, con lo que sólo hay que fabricar un tipo de cartucho para todas las consolas

Y vamos, sólo tienes que ver la potencia que requiere un emulador de SNES comparado con uno de MD (que se puede poner en un sólo chip, un GOAC, cosa que con la SNES no es posible), cuando la potencia a nivel técnico es similar

theelf podrias animarte ha hacer un cursillo de programacion basica, yo estaria muy interesado.

socram8888 escribió:Y vamos, sólo tienes que ver la potencia que requiere un emulador de SNES comparado con uno de MD (que se puede poner en un sólo chip, un GOAC, cosa que con la SNES no es posible), cuando la potencia a nivel técnico es similar

Esto me interesa xD. Llegué a ver un emulador que pedía un core 2 duo, pero ni idea xD. Realmente cuánto se requiere para jugar a la snes? ._.

Lo cierto es que la SNES es bastante compleja, pero eso debido a su potencia, ya que permite hacer muchas virguerías si la conoces bien a fondo. Siempre podrás hacer un juego con los gráficos al estilo de la NES sin mucha complicación (de hecho, tan fácil como hacer juegos para la NES, ya que son "casi" compatibles), pero no tiene mucho sentido hacerlo así teniendo la NES. Si vas a programar en la SNES, lo suyo es aprovecharla todo lo que se pueda.

Que yo sepa, no había ningún kit de desarrollo para third-parties, pero creo que Nintendo proporcionaba unas librerías para funciones repetitivas (acceso a VRAM, DMA, audio) que podían usar como apoyo. Y me parece raro que el apoyo de Nintendo se limitara a esto porque buena parte de las posibilidades de éxito de una consola nueva el día de su nacimiento pasan porque los programadores puedan hacer juegos fácilmente, sin tener que hacer todo desde cero cada vez que se enfrentan a un nuevo diseño. Hay que recordar el caso de la Saturn, que parece que era una auténtica locura programar para ella con esa arquitectura de dos micros...

socram8888 escribió:Tercero, la CPU de la SNES es mediocre tirando por lo alto. Es muy lento (3,6MHz), y además es de 16 bits frente a los 32 bits y los 7,6MHz de la MD, por ejemplo, y además ten en cuenta que un 68000 tal cual es mucho más sencillo de gastar que un ASIC especial de Nintendo

Hombre, que sea lenta no la convierte en más difícil de programar, pero sí es verdad que es un handicap importante.
Por cierto, que el 68000 no es de 32 bits, no confundamos que sus ALGUNOS de sus registros internos sean de 32 bits con que sea un micro de 32 bits: el bus externo, la arquitectura de las instrucciones y la ALU son de 16.
Y el ASIC no es especial para Nintendo ni mucho menos... de hecho el micro es un 65C816 de Western Digital, pero está insertado como un core en la CPU ya que los decodificadores de los buses están también metidos en el mismo chip, pero el micro que ejecuta las instrucciones es el mismo que un Apple II GIS estándar, no propietario de Nintendo.

socram8888 escribió:Cuarto: como la CPU es más lenta, muchas veces se necesita un coprocesador de apoyo (como el chips de descompresión o mappers, o incluso el famoso Super FX), con lo que además tienes que aprender a manejar estos addons

La SNES no tiene "mappers"; y sí, aprender a programar en los chips de apoyo es una locura... por eso casi siempre se usaban en juegos de la propia Nintendo que tenía mucha más experiencia con ellos.

socram8888 escribió:Quinto: el audio está controlado por un ASIC especial también, en lugar de por un procesador normal y corriente (el Z80 en la MD, aunque el 68k también tiene acceso directo al audio)

Lo mismo que para el caso del micro: no es especial de Nintendo, es de Sony y es genérico, se usaba en muchos otros sitios.

socram8888 escribió:Sexto: hace falta un chip de CIC, lo que requiere usar un PIC, encareciendo el coste de la producción del cartucho, o modificar la consola internamente, difícil para quien no sabe de esto. En la MD sólo hay que realizar una simple escritura ("SEGA" al registro $A10000, conocido como TMSS), y además hay un registro que indica el tipo de consola, por lo que el programa se puede adaptar automáticamente a la versión de la consola, con lo que sólo hay que fabricar un tipo de cartucho para todas las consolas

Bueno, esto es cierto pero el CIC ni se programa ni influye en la complejidad de la programación para la consola; es cierto que dificulta mucho hacer cartuchos "pirata", pero no interviene para programar.

socram8888 escribió:Y vamos, sólo tienes que ver la potencia que requiere un emulador de SNES comparado con uno de MD (que se puede poner en un sólo chip, un GOAC, cosa que con la SNES no es posible), cuando la potencia a nivel técnico es similar

Esto es curioso, sí, pero eso se debe a que si quieres emular con perfección 100% el hardware, necesitas tener muchas cosas en cuenta, sobre todo lo de las diferentes velocidades de los buses. Para programar eso hace falta tener sincronizado los tres buses y eso gasta tiempo de emulación. Luego además está el tema de la generación de las imágenes en pantalla, que es un auténtico coñazo en la SNES: enventanado de capas, suma de capas, substracción de capas, transparencias, HDMA....

Juas desde luego viendo los inconvenientes me parece alucinante que salieran tan buenos juegos.Desde luego que nintendo arraso porque eran los reyes del mercado del mismo modo que las desarrolladoras se pelearon con la ps2 que tambien se lo puso dificil para sacarle el jugo.Menudo infierno!!

jordigahan escribió:theelf podrias animarte ha hacer un cursillo de programacion basica, yo estaria muy interesado.

+1.

Yo ahora ando liado con java que es bastante sencillo en comparación con otros lenguajes.

En esta wiki hay mucha documentación y muchos tutoriales:
http://wiki.superfamicom.org/snes/show/HomePage
Si le echas dedicación y ganas puedes hacer cosas potables.

El 68000 es de 32 bits, todos sus registros, la ALU, el PC, las instrucciones, etc... son todas compatibles con 32 bits (sólo hay que poner el opcode .l, es decir, en lugar de "ADD D0, D1" que haría una suma del registro 1 al registro 0 de 16 bits, pones "ADD.L D0,D1" y ya es de 32 bits, y es más, el 68030 (creo que era ese) es un 68000 tal cual y completamente compatible, con la unica diferencia de que tiene un bus externo de 32 bits

El audio, no puedes comparar un chip normal y corriente de FM como es el de Yamaha de la MD, que era propio de multitud de recreativas, sintetizadores, pianos, ordenadores, etc... con el SPC700 cuyo uso fuera de la SNES fue más bien escaso

En cuanto a la CPU, si se que es uno "esrándar", pero desde luego el de WD no tiene dos bus como el 5A22 tenía xD. Y además el 68C816 no es que sea tan fácil de usar como un 68000 el cual mucha más gente conoce, porque recuerda que se uso en el Amiga y en varios Macintosh, con lo que la cantidad de utilidades y compiladores es mayor

Y en cuanto al CIC: no, no es complicación a la hora de programar, pero sí a la hora de fabricar juegos físicos, por lo que hay menos gente interesada a nivel profesional (personalmente no le vería la gracia a pagar por un juego limitado a un emulador )

este hilo conduce a Matrix

socram8888 escribió:El 68000 es de 32 bits, todos sus registros, la ALU, el PC, las instrucciones, etc... son todas compatibles con 32 bits (sólo hay que poner el opcode .l, es decir, en lugar de "ADD D0, D1" que haría una suma del registro 1 al registro 0 de 16 bits, pones "ADD.L D0,D1" y ya es de 32 bits, y es más, el 68030 (creo que era ese) es un 68000 tal cual y completamente compatible, con la unica diferencia de que tiene un bus externo de 32 bits

Bueno, tampoco nos vamos a poner a discutir por esto, pero el 68000 es de 16 bits, a pesar de que tenga registros de 32. La ALU es de 16 bits, a pesar de que haga las operaciones de 32 bits en dos ciclos (un ciclo con 16 bits y otro con los siguientes 16 bits y una demostración clara son las multiplicaciones, que sólo pueden ser de 16 bits) y el bus de datos y la organización de la memoria externa es de 16 bits... Todos los que hemos programado en el 68000 lo hemos considerado siempre de 16 bits.
Aunque no me gusta la wikipedia para estas cosas, puedes ver en su versión inglesa que dice claramente que hay muy pocas instrucciones que se ejecuten en 32 bits, y si miras la página del MC68020, verás que comenta que mejora al anterior por tener una ALU de 32 bits. De hecho, ése se considera el primero de la familia 68000 en ser de 32 bits.

socram8888 escribió:El audio, no puedes comparar un chip normal y corriente de FM como es el de Yamaha de la MD, que era propio de multitud de recreativas, sintetizadores, pianos, ordenadores, etc... con el SPC700 cuyo uso fuera de la SNES fue más bien escaso

Hombre, tuvo diferentes usos, sobre todo porque el SPC700 era un DSP, por lo que su aplicación era bastante específica. Pero no es más difícil programar para él que para cualquier otro DSP.

socram8888 escribió:En cuanto a la CPU, si se que es uno "esrándar", pero desde luego el de WD no tiene dos bus como el 5A22 tenía xD. Y además el 68C816 no es que sea tan fácil de usar como un 68000 el cual mucha más gente conoce

Yo he programado en los dos y no sabría decirte si hay alguno más difícil que otro... normalmente los RISC (como el 65C816) son más "complicados" porque el juego de instrucciones es más básico, y para hacer una operación más simple tienes que escribir muchas instrucciones que en un CISC. Eso si, más gente conoce el 68000 porque es el que se usa en muchas universidades (en la mía, por ejemplo) ya que el juego de instrucciones es bastante claro y "limpio", y los kits de desarrollo están tirados de precio.

¿Sería posible desarrollar un SDK que haga posible recopilar de forma automatica todas las funciones de SNES?... aunque de esta manera no se arañe toda la potencia que pueda llegar a dar la maquina, pondría mucho mas sencillas las cosas a la hora de programar cosillas.

Freestate escribió:Juas desde luego viendo los inconvenientes me parece alucinante que salieran tan buenos juegos.Desde luego que nintendo arraso porque eran los reyes del mercado del mismo modo que las desarrolladoras se pelearon con la ps2 que tambien se lo puso dificil para sacarle el jugo.Menudo infierno!!

Sip, yo creo que fue bastante difícil...por algo muchos de los juegos de SNES lanzados al principio de vida se ralentizaban con 4 sprites en pantalla...véase por ejemplo Super Ghouls N Ghosts

magno escribió:

socram8888 escribió:El 68000 es de 32 bits, todos sus registros, la ALU, el PC, las instrucciones, etc... son todas compatibles con 32 bits (sólo hay que poner el opcode .l, es decir, en lugar de "ADD D0, D1" que haría una suma del registro 1 al registro 0 de 16 bits, pones "ADD.L D0,D1" y ya es de 32 bits, y es más, el 68030 (creo que era ese) es un 68000 tal cual y completamente compatible, con la unica diferencia de que tiene un bus externo de 32 bits

Bueno, tampoco nos vamos a poner a discutir por esto, pero el 68000 es de 16 bits, a pesar de que tenga registros de 32. La ALU es de 16 bits, a pesar de que haga las operaciones de 32 bits en dos ciclos (un ciclo con 16 bits y otro con los siguientes 16 bits y una demostración clara son las multiplicaciones, que sólo pueden ser de 16 bits) y el bus de datos y la organización de la memoria externa es de 16 bits... Todos los que hemos programado en el 68000 lo hemos considerado siempre de 16 bits.

es que discutirlo es estupido porque es que en cualquier sitio te lo presentan como un procesador de 16 bits, algo logico por eso mismo que tu dices: externamente no puede trabajar directamente con más de 16 bits de datos.... sin contar que si de verdad fuese de 32 bits, sega lo habria usado en su publicidad.

Despues de verme tres temporadas de The Big Bang Theory ya os empiezo a entender...

MyoCid escribió:Despues de verme tres temporadas de The Big Bang Theory ya os empiezo a entender...

Sheldon style

Ralph escribió:¿Sería posible desarrollar un SDK que haga posible recopilar de forma automatica todas las funciones de SNES?... aunque de esta manera no se arañe toda la potencia que pueda llegar a dar la maquina, pondría mucho mas sencillas las cosas a la hora de programar cosillas.

Sí sería posible, aunque para ello habría que tener muy claro qué necesidades habituales se necesitan al programar para crear las librerías... vamos, que sería como crear el API de un sistema operativo: hay que saber muy bien qué funciones se le dan a los programas y cómo las van a necesitar (parámetros y demás).

Además, creo que sería muy interesante como proyecto para alguien que conociera muy bien la máquina...

O un interprete tipo tipo BASIC (o cualquier otro)

magno escribió:

Ralph escribió:¿Sería posible desarrollar un SDK que haga posible recopilar de forma automatica todas las funciones de SNES?... aunque de esta manera no se arañe toda la potencia que pueda llegar a dar la maquina, pondría mucho mas sencillas las cosas a la hora de programar cosillas.

Sí sería posible, aunque para ello habría que tener muy claro qué necesidades habituales se necesitan al programar para crear las librerías... vamos, que sería como crear el API de un sistema operativo: hay que saber muy bien qué funciones se le dan a los programas y cómo las van a necesitar (parámetros y demás).

Además, creo que sería muy interesante como proyecto para alguien que conociera muy bien la máquina...

Por ejemplo... ¿sabes el efecto zoom del art of fighting?, el pitote que han tenido que armar ahí involucrando al modo 7 para los escenarios, y el zoom por software para todo lo demás, tiene que ser bastante guapo. Tener algo así automatizado, con la ventajilla de poder trastear para modificarlo, pondría las cosas mucho mas fáciles (por ejemplo, que no de todo el zoom de golpe, sino poco a poco, como en el last blade... o simplemente darle mas rango para que abarque mas... e incluso adaptarlo para usarse en otro tipo de juegos que no sean 1 vs 1).


Sería algo así como una recopilación de los truquitos ingeniosos que alguien se saca de la manga en algún título, y que nadie mas parece saber imitar(o tarda demasiado). De esta manera, con un motor así, se le otorga mas importancia a la capacidad para diseñar e imaginar, que a la paciencia del que se pone a ello
...y luego está el tiempo que ganas, claro.