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

En algunos de esos juegos es necesrio también para desbloquear partes del juego. De hecho creo que está mejor la lista de la wikipedia pero en inglés, aunque también hay algún error.
http://en.wikipedia.org/wiki/Nintendo_6 ... ansion_Pak

Solieyu escribió:te has olvidado del perfect dark.Me imagino a los que se lo compraron sin tener el expansion pack... xD

Igual molaba un huevo, juegalo sin expasion pak y vas a flipar con los "Simuladores" y los "Retos" son fabulosos. Yo tiré horas y horas jugando con 15 (Creo) simuladores. Era lo más cercano a "Multiplayer Online" por eso de muchos en una partida, pero cuando conocí Quake III... pero ya es otro cantar.

Perfect Dark mola aún sin Expansion Pak.

El Donkey Kong costó 12,490 pesetas cuando salio, tengo la etiqueta del precio pegada en el armario de mi habitación todavia... xD

Yo no soy programador (que mas quisiera) y no entiendo eso de que un error salte de forma aleatoria. No se supone que todo es causa-efecto? Ojo hablo desde la puta ignorancia xD. Sea como fuere Rare hizo lo correcto.

Akiles_X escribió:Yo no soy programador (que mas quisiera) y no entiendo eso de que un error salte de forma aleatoria. No se supone que todo es causa-efecto? Ojo hablo desde la puta ignorancia xD. Sea como fuere Rare hizo lo correcto.

Una máquina no actua por si sola, solo va a hacer lo que tu le digas que haga, el problema está cuando Nintendo de ha dicho que haga una cosa, tu desconoces que Nintendo ha hecho eso, y tu estás intentando hacer otra...

Akiles_X escribió:Yo no soy programador (que mas quisiera) y no entiendo eso de que un error salte de forma aleatoria. No se supone que todo es causa-efecto? Ojo hablo desde la puta ignorancia xD. Sea como fuere Rare hizo lo correcto.

A nivel teorico 1+1=2, y una máquina cuando suma hace eso. No hay error posible.

El problema hay cuando se ejecuta un programa de 12783621897362136218 líneas con librerías de su madre y de su padre, en un hardware que vete tu a saber como es, con un sdk que a saber si funciona y siendo de nintendo capado seguro, usando firmware que estara programado deprisa y corriendo, y encima con una arquitectura hecha a conciencia y con muchos errores de diseño (o en su defecto con muchas mejoras posibles). El caos es enorme, y en consolas (y más antiguas) pues estos casos son normales.

Yo nunca he programado para videojuegos, pero he programado prácticas donde SIEMPRE la tercera vez que se ejecutaba fallaba (en laboratorio de programación 2 con C++ y windows 98), y donde cada X tiempo salían como datos del programa la canción del winamp que tenía en ese momento (en laboratorio de programación 1 con pascal y windows 98). La razón... pues algo que hacia alguna cosa que no debía, y que nadie sabía. El coste de investigarlo era tan grande que no podía parar por lo que se tira para delante y ya hablaremos.

Trabajando pues tuve algún marrón, aunque el que más recuerdo era un fallo de un servidor, tenía frito al programador que lo llevaba (era externo), y después de 2 semanas día y noche, resulto que era de una librería del java que cuando recibía X datos reventaba y sacaba lo que le daba la gana SIN FALLAR. La solución fue facil cuando lo vío, cuando venían esos datos se sacaba un valor fijo y fuera. La verdad que acabe quemado muy pronto.

Por mi experiencia, digo yo que sería algo (texturas seguramente) que hacia que un puntero se le fuera la olla, y quedaba frita la maquina. Es una jodienda cuando pasa esto, porque curras para nada, pero aquí se vió algo fácil, se mete un hardware y a correr.

Como se suele decir, en el papel todo cabe, en la vida real... lo normal es que no.


PD: Y esto por no hablar de las colisiones, que es otro mundo en errores... y en 3D mejor ni hablamos.
PD2: Muchos errores de estos ahora son conocidos como trucos o ayudas, recuerda a Glitch de Rompe Ralph

Yo nunca he programado para videojuegos, pero he programado prácticas donde SIEMPRE la tercera vez que se ejecutaba fallaba (en laboratorio de programación 2 con C++ y windows 98), y donde cada X tiempo salían como datos del programa la canción del winamp que tenía en ese momento (en laboratorio de programación 1 con pascal y windows 98). La razón... pues algo que hacia alguna cosa que no debía, y que nadie sabía. El coste de investigarlo era tan grande que no podía parar por lo que se tira para delante y ya hablaremos.

Tu error era que no reservabas bien la memoria y accedías a una zona de memoria que no estaba libre, era tipico en mi caso que como datos de programa apareciera "borland c......." y es que yo programaba en turbo c, la unica forma de detectarlo y corregirlo era mirando el valor de las variables con el debbuger

Compañeros,
La gente que programa en serio se supone que tiene y sabe utilizar herramientas "de verdad" como gdb (debugger) y valgrind (profiler).
Con ésto no quiero decir que detectar errores sea pan comido, pero no lo comparen con una practica en turbo C o visualstudio.

puch666 escribió:Compañeros,
La gente que programa en serio se supone que tiene y sabe utilizar herramientas "de verdad" como gdb (debugger) y valgrind (profiler).
Con ésto no quiero decir que detectar errores sea pan comido, pero no lo comparen con una practica en turbo C o visualstudio.

¿Qué entiendes por "programar de verdad"?, hay infinidad de proyectos caseros mucho mejor hechos que grandes programas millonarios.

Si se pudiese ver el código de todo, más de uno se iba a llevar las manos a la cabeza viendo como están hechos muchos programas famosos e importantes.

puch666 escribió:programa en serio

ains..

Baek escribió:¿Qué entiendes por "programar de verdad"?

Baek, me refiero a alguien que tiene una muy buena formación y mucha experiencia.
Mi comentario iba dirigido a lo que se dijo un poco mas arriba, que en clase habían tenido problemas utilizando turbo C.

O sea, me parece un poco extremo comparar lo que le puede pasar a un alumno en una clase, con lo que tiene que enfrentar un programador de RARE, que suponemos no debe ser un improvisado o al menos tener algo mas de conocimiento que un alumno promedio.

Baek escribió:hay infinidad de proyectos caseros mucho mejor hechos que grandes programas millonarios.

Estoy completamente de acuerdo con eso. De hecho, hay muchos ejemplos que lo demuestran

Baek escribió:Si se pudiese ver el código de todo, más de uno se iba a llevar las manos a la cabeza viendo como están hechos muchos programas famosos e importantes.

Y hay ocasiones en las que eso pasa. Como lo que descubrió el team fail0verfl0w con respecto al cifrado de la PS3

Por cierto, KFR, gracias por los aplausos

puch666 escribió:Compañeros,
La gente que programa en serio se supone que tiene y sabe utilizar herramientas "de verdad" como gdb (debugger) y valgrind (profiler).
Con ésto no quiero decir que detectar errores sea pan comido, pero no lo comparen con una practica en turbo C o visualstudio.

Yo no digo que sea lo mismo una practica de 4000 lineas que un juego, pero desde luego la base en ambos casos es igual.

Karaculo escribió:Tu error era que no reservabas bien la memoria y accedías a una zona de memoria que no estaba libre, era tipico en mi caso que como datos de programa apareciera "borland c......." y es que yo programaba en turbo c, la unica forma de detectarlo y corregirlo era mirando el valor de las variables con el debbuger

Yo usaba el borland C++ sino recuerdo mal, y puede que fuera eso, a todos nos pasaba lo mismo más o menos. De hecho lo primero que se hacia cuando se sacaba laboratorio 2, era formatear el pc xD

Mi comentario iba dirigido a lo que se dijo un poco mas arriba, que en clase habían tenido problemas utilizando turbo C

Yo era el de turbo C y kaiser el de la duda, que es posible que fuera lo que yo dije, la dificulta no esta en las lineas de código (depende del programador y su habilidad o ganas) sino en la resolución del problema, te pongo unos ejemplos de cuando yo utilizaba C (hoy en dia en aspecto profesional no se utiliza, os imaginais un CRM,B2B,B2C,DMR, realizados en C o C++ al programador se le va la olla). Ejemplos así me recuerda cuando tenia que programar un software que resolviera una gramatica de Greibach y hamming estos si eran jodidos, donde residia su dificulta justamente donde franqueaba el c en lo jodido que era la reserva de memoria (no la linea en si sino su gestion).
Nada comparable a la realizar el arkanoid en c, muchisssimo mas facil (que tambien era una practica), la dificultad era el rebote de la puta pelota (para el que no lo sepa se utilizan transformaciones) pero si tenias ya las ideas claras no había problemas. Tambien desarrolle en otra practica un paint para msdos, este era mas facil que el arkanoid, la dificultad en este caso es que tenias que dividir la pantalla en marcos porque el turbo c (y supongo que las versiones de c viejunas) no podias almacenar de golpe ni siquiera una pantalla de 640x480.

Y todo esto ha cambiado a mejor (desde que sali de la uni no volvi a utilizar C), los lenguajes de programacion tienen 100000 librerías distintas que te hacen de todo, con unos entornos de desarrollo que hace de todo y con unos debugger impresionantes.


gdb es un debugger creo recordar por linea de comandos, con esta herramienta te mueres imaginate que te da 200 errores con el numero de linea y el posible error, tienes que ir a tu editor de texto ir mirando en que linea buscarla y repararla, buscar la siguiente linea y así hasta que termines, guadar ir otro vez a la linea de comandos y así hasta que termines, en los entornos de desarrollo "modernos o para windows" todo se hace desde el propio entorno de desarrollo.

Baek, me refiero a alguien que tiene una muy buena formación y mucha experiencia.

Soy ingeniero tecnico en informatica de sistemas por si sirve de algo

Siguiendo con el tema supongo (yo) que lo que le paso a rare es en la optimización del código consumia mas memoria que la disponible del sistema (imaginaros que fuera 2 kByte), una posible solución seria mirar porque ocurría eso (imaginaros que podia ser por sus propias variables o dentro de las librerías que utilizaban), para ellos era mas facil aumentar la memoria que actualizar el código (comprobar que tienes el Expansion pak son 2 lineas de codigo), hoy en dia ocurre esto siempre si se viera el código de cada programas os reiríais mucho, he visto bbdd de programas gestionadas coon arrays (se podia utilizar un sgbd)...
Y por eso tenéis que cambiar de ordenador cada cierto tiempo (sin contar la ley de moore) aunque sigais utilizando para lo mismo

gdb es un debugger creo recordar por linea de comandos, con esta herramienta te mueres imaginate que te da 200 errores con el numero de linea y el posible error, tienes que ir a tu editor de texto ir mirando en que linea buscarla y repararla, buscar la siguiente linea y así hasta que termines, guadar ir otro vez a la linea de comandos y así hasta que termines, en los entornos de desarrollo "modernos o para windows" todo se hace desde el propio entorno de desarrollo.

Hey hey hey, el GDB es la polla. En primer lugar, es EL debugger. Es standard, corre en todos los sistemas Unix y derivados, y es el que usa Apple en Xcode. Eso de que es "por línea de comandos" es una simplificación: nada impide integrarlo en IDEs de todo tipo. Aunque el mejor IDE es saber usar Linux de verdad. Una ventana con vim (con sus funciones de autocompletado para cualquier lenguaje que te puedas imaginar), otra con GDB y otra para compilar y ejecutar el programa. ¿Proyecto grande? Pues te haces un Makefile.

Lo demás son, cómo dedirlo finamente...mariconadas

PD: Es coña, cada cual que programe como le salga del pijo, pero personalmente prefiero aprender a usar herramientas de verdad, en entornos estandarizados como Unix, que excrecencias propietarias que te hacen prisionero de un sistema cerrado para el resto de tu vida porque lo que aprendes sólo te vale para seguir adicto a ese sistema. Odio esa sensación. Además, GDB está chupado, muy bien documentado y tiene funciones acojonantes para debugear en remoto, correr en una máquina y debugear en otra... Es la hostia. No me lo toqueis, que me pongo "tó loco".

Yo no digo nada, sino que para mi es mas engorroso que con un entorno, si te digo que he visto gente desarrollando con el notepad de windows una pagina web (en entorno profesional) y a gente desarrollando una consulta con el analizador de consultas de sql server mientras que yo lo hacia en vista diseño (mucho mas rápido y los nombres de los campos de las distintas tablas los tienes en vertical y no te equivocas al escribir el nombre de los campos lo mas gracioso es que ellos no se apañaban con mi método y yo me perdía con el suyo). A mi me gusta mas los entornos de desarrollo sera porque cuando trabajaba programando siempre me pedían algo era con prioridad "para ayer".

Yo usaba el borland C++ sino recuerdo mal, y puede que fuera eso, a todos nos pasaba lo mismo más o menos. De hecho lo primero que se hacia cuando se sacaba laboratorio 2, era formatear el pc xD

Pero lo de formatear seguramente seria por los virus, lo raro es que vuestro profe no lo detectase el fallo (seguramente antes impartía otra asignatura y lo cambiaron perdiéndose por el camino), por que era típico y una de las cosas mas feas de c e importante (para mi).

Y de la de cosas de estas que no nos enteraremos nunca... Lo peor es que acabamos tragando siempre con lo que nos echen...
Ala, me voy a seguir jugando al Zelda con mi Motion Plus.