Un programador de Rare desvela por qué Donkey Kong 64 necesitaba el Expansion Pak

Archivado
1, 2, 3
Un programador de Rare desvela por qué Donkey Kong 64 necesitaba el Expansion Pak: Evitaba un error aleatorio que no se pudo solucionar.

Donkey Kong 64 es conocido por ser el primer juego de Nintendo 64 en necesitar el Expansion Pak, un accesorio que aumentaba la memoria del sistema 4MB a 8MB. Según se decía en la publicidad -y en el caso concreto de Donkey Kong 64-, permitía mejores gráficos y escenarios más grandes con el lema "tan grande que hemos tenido que incluir el Expansion Pak para que quepa en él".

Chris Marlow, uno de los programadores del juego, ha desvelado en unos comentarios del director de Conker's Bad Fur Day que la razón real de esta media fue evitar un "error aleatorio que colgaba el juego sólo en la versión de 4MB", que aparentemente no ocurría con el Expansion Pak conectado.

Tras no poder localizar la causa del fallo, Rare estuvo forzada a incluir la expansión de memoria de manera gratuita con el juego "lo que costaba -a Rare- una fortuna". Chris Seaver explica que se pudo amortizar al año siguiente con Perfect Dark, un juego que "definitivamente lo necesitaba" para funcionar la mayoría de sus modos; gracias en parte al accidente de Donkey Kong 64, muchos usuarios ya no necesitaban adquirir el accesorio por separado -aumentando el número de posibles compradores del juego-.
Pues me parece que ya que no pudieron solucionarlo y obligaron a tener que usarlo, el hecho de incluirlo junto con el juego y el precio recuerdo que era competitivo no como las thirds, me parece que les honra y bastante.
El hambre despierta el ingenio.

Lo bueno esque el expansion venia gratis con el juego,a si que... perfecto.
en su tiempo yo me pregunte por que el ocarina no lo llevaba y este si, por que para mi, este ultimo es bastante mas inferior y no le hacia falta mas potencia que al ocarina,, es solo mi reflexion
Mirad quien iba a imaginar eso , bien por rare que asumió el coste y siguió adelante con éxito ... :)
El resident evil 2, no lo necesitaba ?
NewDump escribió:El resident evil 2, no lo necesitaba ?

No es obligatorio pero con el expansion juegas en "HD", y se nota bastante.
gaula88 está baneado por "saltarse baneo temporal con clon"
¿Un error aleatorio?. No tiene puto sentido. Los juegos no son magia, son programas normales y corrientes.

Se sabe que los juegos de N64 se compilaban con el GCC, así que por supuesto tenían un gran debugger: el GDB. Se puede poner el programa a correr en una máquina (estación SGI, con IRIX, que es donde se programaban estas cosas) y debugearlo por SSH al mismo tiempo, con el "attach" del GDB. Cuando el juego peta, miras en qué línea estaba (porque lo has compilado con debugging symbols) y el estado de los registros de la CPU, y a poco que sepas lo que estás haciendo o alguien sepa lo que está haciendo la librería que estás usando, supongo que proporcionada por Nintendo, no es tan difícil saber por qué se cuelga.

La explicación que se da en el artículo es absurda y me parece insultante que esperen que nos creamos semejante mierdaca.
gaula88 escribió:¿Un error aleatorio?. No tiene puto sentido. Los juegos no son magia, son programas normales y corrientes.
Eres programador? si me dices que no, ok entiendo el porque de la respuesta, si me dices que si...joder que suerte has tenido hasta el momento.

Edit: Veo que comentas lo del debugger. Me he leido varias entrevistas de programadores famosos o que han formado parte de estudios de renombre y la mayoria coinciden en que las herramientas de debugeo de tal o pascual hard eran una mierda, en algunos casos o inexistentes directamente o como si lo fueran pues no servian para nada y despues hay que tener en cuenta que tanto las librerias que ofrezcan de la propia consola como motores de terceros o motores propios, no esta todo ello exento de fallos, bugs, incompatibilidades etc etc.. no seria el primer proyecto que se ha ido entero a la mierda, tal cual, por no ser capaces de dar con un error y no estamos hablando de pringandillos casualmente (en relacion a rare).

Edit2: En tu perfil veo que eres informatico, programador, pues no va a malas pero sobre todo en este mundillo he aprendido a no dar las cosas por sentado y mucho menos menospreciar u obviar el esfuerzo de terceros porque luego casualmente suele ocurrir que el tiempo te planta delante de una situacion similar y hostie!...pues no era tan facil xD
gaula88 escribió:¿Un error aleatorio?. No tiene puto sentido. Los juegos no son magia, son programas normales y corrientes.

Se sabe que los juegos de N64 se compilaban con el GCC, así que por supuesto tenían un gran debugger: el GDB. Se puede poner el programa a correr en una máquina (estación SGI, con IRIX, que es donde se programaban estas cosas) y debugearlo por SSH al mismo tiempo, con el "attach" del GDB. Cuando el juego peta, miras en qué línea estaba (porque lo has compilado con debugging symbols) y el estado de los registros de la CPU, y a poco que sepas lo que estás haciendo o alguien sepa lo que está haciendo la librería que estás usando, supongo que proporcionada por Nintendo, no es tan difícil saber por qué se cuelga.

La explicación que se da en el artículo es absurda y me parece insultante que esperen que nos creamos semejante mierdaca.


Si quieres te puedo pasar alguna práctica antigua mia con errores de ese tipo que fallaban cuando mejor les parecia.

La historia me parece curiosa, aunque me sorprende teniendo en cuenta que eran una empresa tan grande.
Hay veces que no es facil dar con una solución... los programas que creas no se ejecutan con rutinas que son exclusivamente de tu creación... usas librerías que ni tienes el código fuente, ni tienes posibilidad de modificar, sobre procesadores que funcionan de forma que generalmente desconoces...

puedes mirar TU codigo chorrocientas vences y no ver ningún problema. Es posible que si le hechas horas y tiras dinero como si no tuviera fin puedieras arreglar el problema, pero la mayoria de las veces eso no es posible... y algunas veces, que tu programa casque escapa de tu control... no todos los errores se pueden corregir fácilmente... y algunas soluciones son directamente inviables...

Asi que si la solución fue añadir el expansion pack gratis y se lo pudieron permitir, pues es una solución tan válida como retocar el código de tu programa...
Curioso al menos. De lo que se entera uno al tiempo.
Baek escribió:
NewDump escribió:El resident evil 2, no lo necesitaba ?

No es obligatorio pero con el expansion juegas en "HD", y se nota bastante.


No es mas bestia Re2 que P. Dark ?
NewDump escribió:
Baek escribió:
NewDump escribió:El resident evil 2, no lo necesitaba ?

No es obligatorio pero con el expansion juegas en "HD", y se nota bastante.


No es mas bestia Re2 que P. Dark ?

¿Pre-renders vs 3D en tiempo real?, no, para nada, aunque sí es cierto que lo que se ve en pantalla da esa impresión, es el motivo de que los RE hayan envejecido tan bien.
Voy a echarme un vicio al Remake, de la GCube, me dio gusanillo :D
gaula88 escribió:¿Un error aleatorio?. No tiene puto sentido. Los juegos no son magia, son programas normales y corrientes.


Ufff, creo que te has "columpiado" un poquillo; se nota que sabes de lo que hablas pero no al 100%, porque quizá no has programado nunca firmware, código que maneja directamente el hardware. Te aseguro que el problema del que están hablando no será un puntero desbordado ni memoria desalineada ni nada de lo que te encuentras al programar software sobre un sistema operativo. Cuando estás peleando con IRQs que saltan esporádicamente o bien requieres llenar los buffer de video en cada NMI, te puedes encontrar con cosas surrealistas. Si luego además te metes con cosas como DMAs, HDMAs y demás, el resultado de ciertas combinaciones puede ser catastrófico. Te lo aseguro por experiencia, no solo de trabajar como profesional en el mundo del diseño hardware+firmware sino como aficionado que programa en SNES.

gaula88 escribió:La explicación que se da en el artículo es absurda y me parece insultante que esperen que nos creamos semejante mierdaca.


Yo sí me la creo, y más aún conociendo bugs de la SNES como el de los ciclos muertos del DMA, el bug de los 32 sprites por scanline y algún otro famoso con el SuperFX...
También te digo que con tiempo seguro que lo hubieran descubierto, pero como en estos casos ya se sabe que los plazos son vitales, pues supongo que prefirieron tirar por la calle de enmedio y lo que se ahorraron en seguir investigando el origen del error lo gastaron en poner el Expansion Pak.
Cuantos juegos sacó Rare en los años de vida de 64?

Yo creo que iban a "marchas forzadas" asi que si se soluciona el problema con el expansion, para que vamos a seguir buscandole los 3 pies al gato ¡Que hay cosas por hacer! XD
pero sin saber de nada, yo no me explico como aumentando la memoria con un expansion pack de 4 a 8 se puede dar solución a un problema para mi de tanta magnitud, como que se te vaya a la mierda un proyecto tan importante para la empresa,,,,

me imagino que compilando el juego otra vez o usando otro programa yo que se, lo puedas arreglar, pero poniéndole un expansión pack lo arregles,,, ojala muchas cosas se arreglaran de la misma manera

salu2
pues si el problema era de corrupcion de memoria, cuanta más memoria tienes, más dificil es machacarla sin darte cuenta, asi que no es tan raro que la expansion de memoria solucionase el problema.

gaula88 escribió: :¿Un error aleatorio?. No tiene puto sentido. Los juegos no son magia, son programas normales y corrientes.


no voy a repetir lo que ya han dicho otros, pero tela con el comentario incluso siendo programador de software que se ejecuta sobre un sistema operativo...
Es imposible programar, y no cometer errores
Es casi imposible programar, cometer errores, y solucionarlos todos

Lo normal es programar, ir solucionando fallos, y al final, tener un codigo pulido, limpio y lo mas libre de fallos posible


El problema es cuando el codigo crece, y crece, y para poder revisar un simple error, tienes que ir aislando partes del codigo, especialmente, si programas en assembler


Ahora mismo, estoy haciendo un pequeño motor 2D para megadrive en codigo de assembler , llevo unas 2mil lineas de codigo, no mucho, y tengo un problema, que cada tanto, el personaje no hace bien las coliciones...

Pues llevo como una semana intentando encontrar el problema, y no puedo.... [+furioso] y aqui no hay debuger ni leches, no queda otra que aislar codigo, y hacer pruebas


Ni hablar de un codigo tan extenso como un juego comercial...
¿Quiere decir esto que el juego fue programado con la idea de que funcionara sin el Expansion Pak?
Banjo Tooie y Conker's Bad Fur Day no tienen mucho que envidiarle a nivel gráfico y funcionana sin él, así que sí que me creo que Rare dejase de lado el accesorio. Mismamente, los escenarios de Perfect Dark pueden correr en el engine de GE (la variedad de enemigos y objetos por nivel ya es otro cantar).

Recuerdo que el juego se veía muy nítido, así que es posible que corriese en alta resolución. Seguramente el juego iba a ser compatible con el Expansion Pak y dejarían elegir la resolución; o aprovecharon que tenía que funcionar por narices con el periférico para aumentarle la resolución.

Curioso, porque el otro juego que requiere obligatoriamente el Expansion Pak para funcionar, el Majora's Mask, no lo utiliza para mejoras gráficas (funciona a resolución normal y 20fps, como el Ocarina of Time) sino para poder manejar todas las acciones de los personajes secundarios.
gaula88 escribió:¿Un error aleatorio?. No tiene puto sentido. Los juegos no son magia, son programas normales y corrientes.

Se sabe que los juegos de N64 se compilaban con el GCC, así que por supuesto tenían un gran debugger: el GDB. Se puede poner el programa a correr en una máquina (estación SGI, con IRIX, que es donde se programaban estas cosas) y debugearlo por SSH al mismo tiempo, con el "attach" del GDB. Cuando el juego peta, miras en qué línea estaba (porque lo has compilado con debugging symbols) y el estado de los registros de la CPU, y a poco que sepas lo que estás haciendo o alguien sepa lo que está haciendo la librería que estás usando, supongo que proporcionada por Nintendo, no es tan difícil saber por qué se cuelga.

La explicación que se da en el artículo es absurda y me parece insultante que esperen que nos creamos semejante mierdaca.


Je hemos empezado a entrar todos los programadores del foro, pero debo decir que doy la razón a los compañeros :) . Qué más quisiéramos que todo fuera tan perfectamente acotado en esto de la programación, pero a veces se produce un fallo aleatorio nos guste o no (especialmente usando librerías externas) el llamado "Random Crash".

No tengo que ir más lejos, a mi mismo me ha ocurrido. Soy programador amateur de videojuegos y en su momento le pegué bastante al Blitz Basic (lo adoro). En un juego almacenaba una serie de valores en un array y había un bucle que la recorría. Pues bien, aleatoriamente me daba un fallo "Array index out of bound", ¡cuando era imposible, el bucle que la recorría era un for de 0 a 359 (360 posiciones)!!. ¿Cómo demonios podía tomar un valor que no debería iterar? El fallo no se resolvía ni aumentando el tamaño del array, desconozco lo que intentaba hacer y nunca di con el error, se producía aleatoriamente.
Curiosa la historia y me había extrañado que este lo trajese y en cambio el majoras mask no, sobre todo al ser este último de nintendo.
Me ha gustado el artículo. Creo que lo que se explica en el tiene sentido.
gaula88 escribió:¿Un error aleatorio?. No tiene puto sentido. [...] parece insultante que esperen que nos creamos semejante mierdaca.

A mi me parece mas insultante tu manera de escribir en el foro y se te permite :)

Lo bueno de ese fallo es que regalaron el Expansion Pak, mereció la pena XD
Eh! gente no sus paseis hostieu cawento que un comentario desafortunado hemos tenido todos y de ello se aprende...sesq...estos abuelos retro que se pican con nada [poraki]
KFR escribió:Eh! gente no sus paseis hostieu cawento que un comentario desafortunado hemos tenido todos y de ello se aprende...sesq...estos abuelos retro que se pican con nada [poraki]


Abuelo y cascarrabias serás tu viejales!!!!!!

PD: :P
Imagen
Reeeepi...huaggg....temeeee eeeee...fuagh hof hof...soooo insooooleeeeente criajo
Abulete "El Maquinitas", los demás nos sentimos jóvenes aun XD
Para que RARE llegase a ese extremo de pringar pasta, es que la cosa era irremediable...
Puede que el codigo de programa fuese correcto y el problema fuese mas a bajo nivel en la arquitectura del hardware de la N64, su fw, BIOS, timing de los componentes, etc... y que al usar una RAM externa ese problema no se presentara, de hecho en la WIKIPEDIA se hace mucha referencia a la mala arquitectura de la memoria de sistema, a los elevados tiempos de latencia de la RAM que traian de cabeza a los desarrolladores...

Memory

The final major component in the system is the memory, also known as RAM. The Nintendo 64 was one of the first modern consoles to implement a unified memory subsystem, instead of having separate banks of memory for CPU, audio, and video, for example. The memory itself consists of 4 megabytes of Rambus RDRAM (expandable to 8 MB with the Expansion Pak) with a 9-bit data bus at 500 MHz providing the system with 562.5 MB/s peak bandwidth. Rambus was quite new at the time and offered Nintendo a way to provide a large amount of bandwidth for a relatively low cost. The narrow bus makes board design easier and cheaper than the higher width data buses required for high bandwidth out of slower-clocked RAM types (such as VRAM or EDO DRAM); however, RDRAM, at the time, came with a very high access latency, and this caused grief for the game developers because of limited hardware performance.[44]


The unified memory subsystem of Nintendo 64 was another critical weakness for the machine. The RDRAM had very high access latency,[35] which nearly negated its high bandwidth advantage. In addition, game developers commented that the Nintendo 64's memory controller setup was poor. The R4300 CPU was severely limited at memory access since it had to go through the RCP to access main memory,[36] and could not use DMA to do so.
la verdad la N64 fue una castaña en diseño, salio tarde y mal diseñada, con muchos cuellos de botella que desaprobechaban por mucho la real potencia de la consola y la hacian un infierno para programar, eso sin contar el limitado espacio de los cartuchos. amen por esos desarrolladores que hacian de la programacion un verdadero arte para sacar verdaderas joyas graficas para esa consola.
Y parece que los devkits y la documentacion de la maquina para las third parties no tenian que ser muy alla ^^U
MyoCid escribió:
gaula88 escribió:¿Un error aleatorio?. No tiene puto sentido. [...] parece insultante que esperen que nos creamos semejante mierdaca.

A mi me parece mas insultante tu manera de escribir en el foro y se te permite :)

Lo bueno de ese fallo es que regalaron el Expansion Pak, mereció la pena XD


Parece que a algunos os importan mas las formas que el contenido, no me parece nada justo lo que dices. gaula88 es uno de los foreros con los aportes mas interesantes y que mas controla del foro en temas de unix y open source (lo se porque yo también me dedico a unix y huelo a estos cretinos a kilómetros [+risas]).

Si no te mola su forma de escribir lo ignoras y punto. Aunque te perderás de comentarios interesantes. ;)

Por cierto, yo en parte estoy de acuerdo con lo dicho por gaula88, los errores mágicos no existen, eso es un mito que suelen repetir los desarrolladores del mundo closed source que están acostumbrados a lidiar con la "magia" pero técnicamente es una tontería grande como un pino. Si un programa deja de petar cuándo amplias la memoria pues seguramente se deba a que algun puntero se está yendo a tomar por culo y la ampliación de memoria no soluciona el problema sino que hace que la condición de error suceda mas tarde (ese "mas tarde" pueden ser años, a fines prácticos, nunca).

Con GDB e infinito tiempo puedes encontrar y solucionar cualquier bug como bien dice gaula88, pero el "detalle" que NO está teniendo en cuenta gaula88 en su comentario es que en el software comercial closed-source el enemigo número uno del programador es el tiempo y no la dificultad técnica (tampoco la corrección técnica les preocupa).

Los desarrolladores van a contra reloj y seguramente era mas rentable pagar el expansion pack que perder tiempo tratando de solucionar el bug con los retrasos en el lanzamiento que podría causar. En el mundo comercial lo único que importa es la pasta y las decisiones siempre son económicas. (lo cual es radicalmente diferente al mundo open source, por eso los desarrolladores open source piensan como gaula88 y los comerciales no)
AntoniousBlock, yo llevo muchos años en el open source, y aunque hace una temporada que dejé de postear ahí, por falta de tiempo e interés más que nada, puedes hacer búsqueda con mi nick dentro del subforo de software libre para comprobar que tengo un montón de mensajes, y no precisamente pidiendo ayudas.

Dicho ésto, estoy de acuerdo con kaiser, magno, bertobp y demás, vosotros tenéis razón en una cosa, aquí no hay magia, si da un error es por algo, pero os olvidais de que el error puede venir provocado por muchos factores, no sólo por un despiste tonto en el código, hablamos de rare en los 90, tienen la suficiente categoría como para asumir que no meterían un expansion en cada juego si no vieran que era realmente necesario. No sabemos qué fallo daba, sólo que deja de darlo duplicando la RAM, tampoco sabemos si era realmente un error o se trataba de ralentizaciones o parones esporádicos, que también puede ser.
El error no solo podia ser del código (podría ser por ejemplo que desbordaba la pila de memoria con la ampliación de 8 megas ya no se producía) sino del propio compilador (cuando utilizaba en mis años mozos turbo C tenia un error en un bucle while se salia sin haberse producido la condición, corte el código lo pegue y ya funciono).
Por cierto la n64 tenia de serie 4 megas, el cacharro este llevaba otros 4 y así hacia 8 o llevaba 8 y los cuatro de la consola se anulaban o llevaba 8 y con los 4 de la consola hacia 12 (esta posibilidad no creo que sea)
Tiene 4 que se unen a los 4 de la placa y hacen 8.
Gracias, y vete a la cama que mañana trabajas
Imagen
que estafado me sentiría.Aqui la revista club nintendo se llenaba la boca diciendo que donkey kong 64 es tan bestia que necesita el expansion pack para ser jugado.
Para mi no es tan bestia me parece mejor el mario 64 y el expansion pack un artilugio desaprovechado.
Karaculo escribió:Para mi no es tan bestia me parece mejor el mario 64 y el expansion pack un artilugio desaprovechado.


Voy a darte la razon, porque ni es bestia, ni es buen juego, es aburrido , pesado, y creo que el unico donkey que jamas termine.
Y tambien recalco que no todo tiene logica, y un simple mal entendido matematico puede provocar un desastre.
Quiero compartir una idea de lo que mi abuelo español me enseño cuando yo era chico :
Todos sabemos que en la mano hay 5 dedos, por dos manos que tienen los seres humanos promedio XD XD XD XD son 10 dedos! EUREKA.
Pero el viejo zorro me hacia contar los dedos de una mano de esta forma:
10, 9, 8 ,7 , 6 y ahi me decia "mas los cinco en la otra mano , tu tienes 11 dedos hijo" XD XD XD XD XD XD XD XD
Me llevo años darme cuenta en donde estaba la trampa,en algo tan simple, me imagino revisar todo un codigo de millones de lineas para encontrar el "malentendido" que comete una maquina XD XD XD XD XD XD
Es asi, sin mas.
AntoniousBlock escribió:
MyoCid escribió:
gaula88 escribió:¿Un error aleatorio?. No tiene puto sentido. [...] parece insultante que esperen que nos creamos semejante mierdaca.

A mi me parece mas insultante tu manera de escribir en el foro y se te permite :)

Lo bueno de ese fallo es que regalaron el Expansion Pak, mereció la pena XD


Parece que a algunos os importan mas las formas que el contenido, no me parece nada justo lo que dices. gaula88 es uno de los foreros con los aportes mas interesantes y que mas controla del foro en temas de unix y open source (lo se porque yo también me dedico a unix y huelo a estos cretinos a kilómetros [+risas]).

Si no te mola su forma de escribir lo ignoras y punto. Aunque te perderás de comentarios interesantes. ;)

Por cierto, yo en parte estoy de acuerdo con lo dicho por gaula88, los errores mágicos no existen, eso es un mito que suelen repetir los desarrolladores del mundo closed source que están acostumbrados a lidiar con la "magia" pero técnicamente es una tontería grande como un pino. Si un programa deja de petar cuándo amplias la memoria pues seguramente se deba a que algun puntero se está yendo a tomar por culo y la ampliación de memoria no soluciona el problema sino que hace que la condición de error suceda mas tarde (ese "mas tarde" pueden ser años, a fines prácticos, nunca).

Con GDB e infinito tiempo puedes encontrar y solucionar cualquier bug como bien dice gaula88, pero el "detalle" que NO está teniendo en cuenta gaula88 en su comentario es que en el software comercial closed-source el enemigo número uno del programador es el tiempo y no la dificultad técnica (tampoco la corrección técnica les preocupa).

Los desarrolladores van a contra reloj y seguramente era mas rentable pagar el expansion pack que perder tiempo tratando de solucionar el bug con los retrasos en el lanzamiento que podría causar. En el mundo comercial lo único que importa es la pasta y las decisiones siempre son económicas. (lo cual es radicalmente diferente al mundo open source, por eso los desarrolladores open source piensan como gaula88 y los comerciales no)

Es lo que tiene ser nuevo, que no sabes como es la gente y las veces que ha sido baneado.
Que te aproveche XD
gaula88 está baneado por "saltarse baneo temporal con clon"
Ufff, creo que te has "columpiado" un poquillo; se nota que sabes de lo que hablas pero no al 100%, porque quizá no has programado nunca firmware, código que maneja directamente el hardware. Te aseguro que el problema del que están hablando no será un puntero desbordado ni memoria desalineada ni nada de lo que te encuentras al programar software sobre un sistema operativo. Cuando estás peleando con IRQs que saltan esporádicamente o bien requieres llenar los buffer de video en cada NMI, te puedes encontrar con cosas surrealistas. Si luego además te metes con cosas como DMAs, HDMAs y demás, el resultado de ciertas combinaciones puede ser catastrófico.


Me extrañaría mucho que una second party tuviese que lidiar con problemas a tan bajo nivel, porque estas casas tiran de librerías y se dejan de historias. Al menos en los ámbitos en que yo he trabajado es así. Y también me extrañaría que las librerías oficiales de Nintendo tuviesen bichos de ese calibre y si los tenían me extraña que no se manifestasen en otros juegos, ya que N64 tiene un engine 3D oficial completo (fast3D o algo así, no recuerdo), con lo que no es sólo que diesen un interface tipo subconjunto de OpenGL, sino que daban ya hasta el motor (de ahí que todos los juegos de N64 de Nintendo y RARE tengan el mismo aspecto, cámaras y demás).
También es cierto que yo siempre he programado siempre con librerías de las que tenía el código fuente y se podían debugear también. Quizá he asumido cosas basándome en mi experiencia parcial, porque esto que cito a continuación es igual de cierto:

Con GDB e infinito tiempo puedes encontrar y solucionar cualquier bug como bien dice gaula88, pero el "detalle" que NO está teniendo en cuenta gaula88 en su comentario es que en el software comercial closed-source el enemigo número uno del programador es el tiempo y no la dificultad técnica (tampoco la corrección técnica les preocupa).


Tras leeros a todos he reflexionado y me he dado cuenta de que si esta historia tan fea es cierta (a mi lo de necesitar multiplicar la memoria de la máquina por un error que no se logra solucionar me parece sucio y cochino, nada elegante) probablemente pasó una de estas cosas o ambas a la vez:

-Nintendo no les daba las librerías y/o el engine ese suyo compiladp en modo debug. Ya ni hablamos de los fuentes. Tratándose de Nintendo y sus asquerosamente exageradas políticas de protección de IP en muchos ámbitos, no me extrañaría en absoluto. Han hecho cosas peores.

-Les faltaba tiempo y no daban con el error, el juego tenía que estar para ayer, etc.

Así que reconozco que mi perspectiva es la de un humilde programador de open source que no tiene licencia y no tiene seguro, y no lleva luz de atrás. Mi aseveración fue exagerada.

Es lo que tiene ser nuevo, que no sabes como es la gente y las veces que ha sido baneado.


Soy un bocazas, no tengo ningún problema en reconocerlo, MyoCid. Y claro que he sido baneado. Y volveré a serlo, supongo, qué le vamos a hacer. Es lo que tiene usar la corrección política para limpiarse el ojete cuando no queda papel.

A mi me parece mas insultante tu manera de escribir en el foro y se te permite


¿Has probado a incluir más fibra en tu dieta? Tomar muchos líquidos y hacer ejercicio también ayuda. [sonrisa]
El caso es que fast3d las "gordas" no lo usaron salvo en algun juego primerizo o directamente ni lo usaron porque comentaban que si, mucho "fast" pero la calidad que se podia conseguir ni de lejos era la que equipos como (la antigua) rare, iguana etc.. buscaban. Por eso mismo rare se creo su propio motor para 64 y contando que estaban trabajando a bajo nivel pues los problemas podrian ser de todo tipo y no es lo mismo explotar un hard como lo hizo dicha empresa que como se hizo para robotron 64 xD por citar algun ejemplo de juego "sin mas...". Es como comparar la posibilidad de errores y problemas con el hard en un shadow of colossus contra un fifa..

PD: El admitir errores es de sabios y aprender de ellos lo logico y util que no perseverar en ellos pues por hacer una cosa mal 500 veces no pasa a estar menos mal, vamos que ole por tu respuesta ;)
gaula88 está baneado por "saltarse baneo temporal con clon"
Por eso mismo rare se creo su propio motor para 64


Ahí "mas matao", macho. No sabía que RARE se metía en esos campos de minas. Yo pensaba que hasta el Mario64 y el Zelda eran fast3D por ser el motor oficial, y que RARE lo usaría por ser una 2nd party. Asumir cosas no es buena costumbre. :o
gaula88 escribió:
-Les faltaba tiempo y no daban con el error, el juego tenía que estar para ayer, etc.



Estoy totalmente convencido que era esto, Rare sacó muchisimos juegos de 64 y todos de buen nivel, iban a mas de 1 juego por año, no creo que pudieran perder mucho tiempo en lidiar con problemas que "se arreglaban facilmente" de otra manera.

Ademas el tema de incluir el Expansion de Regalo no era un problema, otros juegos de 64 lo iban a necesitar obligatoriamente, asi que ya se quitaron el problema de una vez por todas regalandolo.
Skullomartin escribió:Ademas el tema de incluir el Expansion de Regalo no era un problema, otros juegos de 64 lo iban a necesitar obligatoriamente, asi que ya se quitaron el problema de una vez por todas regalandolo.


No es un regalo si te tenías que comprar un juego feo.
FFantasy6 escribió:
Skullomartin escribió:Ademas el tema de incluir el Expansion de Regalo no era un problema, otros juegos de 64 lo iban a necesitar obligatoriamente, asi que ya se quitaron el problema de una vez por todas regalandolo.


No es un regalo si te tenías que comprar un juego feo.


Es un regalo para la gente como yo, a la que les gustan los juegos "feos".

También merecemos cariño de vez en cuando.
Skullomartin escribió:Es un regalo para la gente como yo, a la que les gustan los juegos "feos".

También merecemos cariño de vez en cuando.


Por eso hago yo repros [+risas]
Extraido de un blog con un articulo interesante que ya lei hace tiempo...
Una de las características de N64 consistía en que su microprocesador de gráficos y sonido (el famoso Reality Co-Processor o RCP) era micropogramable, lo cual le ofrecía un nivel de versatilidad bastante alto, aunque claro, esto hacía que para conseguir sacar partido al RCP hacían falta unas herramientas buenas y sobre todo un nivel de programación bastante mas acusado (sin llegar a los extremos de Saturn y su pesadilla multihilo).

Al ser el RCP desarrollado por Silicon Graphics (SGI) el primer microcódigo que se facilitó para los programadores estaba claramente basado en las herramientas que se utilizaban en las estaciones de trabajo que ellos desarrollaban, lo que en un principio podría sugerir que este era una garantía de calidad, pero la verdad esque con el tiempo resultó ser bastante decepcionante, aparte de que la documentación que se facilitó a los programadores sobre como programar el RCP fue practicamente nula.

Este primer microcódigo se llamaba "Fast 3D" y no estaba especialmente pensado para la programación de videojuegos.Por ello, varias compañías recurrieron a la creación de sus propios microcódigos, que les permitieron obtener mejores resultados y que permitieron hacer cosas impensables para la época.

Ejemplos de esto son como siempre Rare, demostrando el poderío de la máquina con apartados técnicos sobresalientes para su tiempo, que hacian palidecer a las tristes conversiones multiplataforma de algunas third que nunca tomaron en serio a N64 o bien (lo mas probable) no les salia rentable dedicar tanto tiempo y dinero a desarrollar para la máquina de Nintendo.

Otro grán ejemplo de la utilización de microcódigo casero son Factor 5 (creadores de Rogue Squadron y Battle For Naboo) y Boss Games (World Driver Championship).
En el caso de Factor 5 se debe destacar el hecho de que lograron crear un micrócodigo que permitió un nivel de iluminación muy superior al de la versión de PC, y mediante diversas técnicas basadas en el streaming directo del cartucho como memoria para texturas se logro conseguir un nivel de poligonización bastante superior a los simples
100.000 polígonos que se destacan siempre en los datos técnicos de cada máquina.

Por otra parte exisie otro microcódigo bastante más avanzado denominado "Turbo3D" y que permitía a la N64 mostrar cerca de 600.000 polígonos de una calidad similar a los que mostraba PSX (es decir, sin muchos de los efectos que N64 usaba por defecto) pero desgraciadamente Nintendo nunca permitió que se utilizase en juegos comerciales, por lo que no hay ejemplos posibles de su utilización real en la consola.
En cuanto a turbo3d y los "muchos efectos" habria que indicar que las perdidas mas reseñables serian la correccion de perspectiva y una menor precision a la hora de calcular y filtrar los texturizados.
El Expansion Pak no era un regalo cuando el juego costaba 12.500 ptas y los juegos de Nintendo y Rare por esa época no superaban las 10.000 ptas. Jet Force Gemini salió para las mismas Navidades y me costó 10.000 ptas, y en esa época el juego estrella de Nintendo era Super Smash BROS que costaría un poquito menos.
El periférico costaba 5.000 ptas suelto, así que se podría decir que te lo vendían a mitad de precio.

Y sí, todo el tema de arquitectura de la consola y herramientas de desarrollo de la Nintendo 64 dan auténtico miedo. Era justo lo contrario de lo que pasó con PSX y aún así se podría decir que no le fueron mal las cosas.
115 respuestas
Archivado
1, 2, 3
Volver a Consolas clásicas