Iniciandome en el mundo del romhacking y las traducciones

Es algo que siempre me ha llamado la atención y pese a que mis conocimientos son prácticamente nulos, siempre es un buen momento para aprender...como reza el refrán: "El saber no ocupa lugar".

Debido al resurgir en mi vida de snes gracias al superufo finalmente me he puesto manos a la obra con la intención de aprender y de que en caso de duda y si podéis, absorber vuestros conocimientos. :p

Se que el romhacking es tedioso y requiere de tiempo y paciencia (cosas que por desgracia tengo en lo primero y por suerte también lo tengo en lo segundo)...aun quedan muchas joyitas por traducir y la scene en español de snes es escasa...quién sabe si el que se inicie un novato ayuda a que otros se le sumen para aprender juntos...por eso y para preguntar dudas y recomendaciones para manuales, tutoriales, programas, desencriptar textos, etc es por lo que abro el hilo.

De momento empiezo trasteando con uno sencillito de poco texto:

Imagen
Tienes la página del gran MAGNO al que siempre agradecerá sus traducciones de Chrono Trigger y Secret of Mana 2 [tadoramo]
http://magno.romhackhispano.org/
Forma parte de este foro, por lo que quizá pueda orientarte algo ;)
m4x1m0 escribió:y la scene en español de snes es escasa...

Imagen
A mi tambien me interesa mucho, si no fuese porque no se sacar los textos habria hecho alguna tradu ya... Programa muy bueno para traducir los textos es el notepad++ que fue lo que me recomendaron los de vagrant para hacer una parte del valkyria de la DS, y venia hasta donde podias meter texto y no... Pero claro el texto del juego lo extrajeron ellos, no yo. [buuuaaaa]

un saludo.
Cuando pase por casa veo si os puedo subir un rar con todo lo que tengo de movidas de romhacking sacadas de varias páginas de romhack españolas de hace un tiempo
thafestco escribió:
m4x1m0 escribió:y la scene en español de snes es escasa...

Imagen

Magno es junto con sayans traducciones de los pocos q a dia de hoy siguen traduciendo y sayans no recuerdo haber visto nada desde hace tiempo...

Tambien hay mas vida ademas de los rpgs
Para mi lo que merece ser traducido son los RPG (y de snes los importantes ya están) que para eso hay texto y más texto y gente que no tiene el suficiente nivel para entenderlo.

Traducir otros juegos que tienen 4 palabras en inglés es un poco tontería (salvo un par contados que no son RPG pero tienen suficiente texto para que merezca la pena)

Para terminar, si lo más atractivo ya está traducido no se por qué te extraña que hoy en día poca gente siga
thafestco escribió:Cuando pase por casa veo si os puedo subir un rar con todo lo que tengo de movidas de romhacking sacadas de varias páginas de romhack españolas de hace un tiempo


Se agradece... ;)
m4x1m0 escribió:Tambien hay mas vida ademas de los rpgs

Pero a diferencia de estos, son perfectamente jugables sin entender ni papa
El romhacking es un mundo emocionante, sin duda, porque te permite "crear" en cierto modo la historia, modelar la personalidad de los personajes a través de lo que dicen, etc... Lo que pasa es que es también un camino difícil, porque yo llevo casi 15 años y se puede decir que es desde los últimos 8 años que de verdad he dominado la SNES para poder hacer virguerías.

Desde mmi punto de vista, m4x1m0, esto te lo puedes plantear de dos formas:
* aprendes lo básico de cómo modificar las ROMs y con herramientas ya creadas vas modificando juegos poco a poco, sin prisa y siguiendo unas pautas mecánicas. Así la curva de aprendizaje es muy "empinada" porque aprendes mucho rápidamente y en seguida tienes resultados visibles. Esos conocimientos de cada herramienta además se puede trasladar a otras consolas si conoces las heramientas para hackear con ellas.

* o te especializas en una máquina en concreto y aprendes cómo funciona exactamente por dentro. Cuando esto lo tienes claro, entonces tienes que "estudiar" un poco de lenguaje ensamblador y aprender a manejar utilidades que te ayuden a ver/ejecutar el código fuente de un juego. Luego tienes que aprender cómo buscar lo que quieres modificar exactamente, y por último, te creas tus propias utilidades para editar el juego en cuestión. Así es como trabajamos la mayoría de los veteranos de la escena, porque realmente así cuesta muchísimo tiempo ver resultados y solo merece la pena para gente que tenga mucho tiempo, ganas y entusiasmo.

Lo bueno de la segunda forma es que puedes terminar por dominar por completo un juego y hacer lo que quieras con él, consiguiendo acabados fantásticos. La mejor comparación es el Romancing Saga 3 en inglés, que fue realizado sin ningún hack, todo con herramientas tradicionales y el acabo es bueno. Pero cuando lo destripas, puedes meter compresión, nuevas fuentes, nuevos gráficos y demás, y la apariencia, los diálogos y todo es mucho más agradable. Te permite además contar la historia como quieras porque no tienes limitaciones de espacio para que los personajes digan exactamente lo que tú quieres que digan.
La pregunta es: ¿se puede hackear cualquier juego?.

No se por qué me da, que si eso fuera posible la scene de estas maquinas estaría viviendo ahora una segunda juventud. Si por mi fuera, elegiría el camino mas largo y difícil para meterle mano a títulos que piden a gritos ser pulidos para terminar de rematar su calidad.

Seguro que todos tenemos algún título en mente para hacer algo así.
Ralph escribió:La pregunta es: ¿se puede hackear cualquier juego?.


Por supuesto que sí, TODO es hackeable, y más de la época de SNES, que prácticamente todas las técnicas "anti-hackeo" se conocen bien. Accediendo al código máquina (ensamblador) del juego, TODO, ABSOLUTAMENTE TODO, es posible.
Entiendo, así que acceder al código del juego siempre es posible, e imagino entonces que acceder a los gráficos y sonidos tambien. ¿Dónde está la dificultad?, es decir, ¿cual sería mas o menos el proceso de acceder a todo el contenido de un cartucho, código incluído?.
thafestco escribió:Para mi lo que merece ser traducido son los RPG (y de snes los importantes ya están) que para eso hay texto y más texto y gente que no tiene el suficiente nivel para entenderlo.

Traducir otros juegos que tienen 4 palabras en inglés es un poco tontería (salvo un par contados que no son RPG pero tienen suficiente texto para que merezca la pena)

Para terminar, si lo más atractivo ya está traducido no se por qué te extraña que hoy en día poca gente siga


a ver...no he traducido un juego en mi vida (de echo, no tengo ni puta idea de informática a nivel de programación, pero si muchas ganas y tiempo libre para aprender)...es lógico que me meta si quiero aprender con juegos de 4 palabras mal contadas, digo yo...no me voy a meter con un clock tower (el cual el parche en español según tengo entendido por la web del autor está mal y el juego se jode a la mitad...haciendo que a día de hoy no haya parche funcional)...digo de meterle mano a snes por el gusto del superufo y porque siempre me ha gustado esta consola...pero eso no quiere decir que no haya otros títulos de otras plataformas que sean interesante meterle mano y nadie lo haga sean o no rpg.

Si miro el catálogo de snes traducido, hay cosas del tipo, final fight 1 y 3 (el dos no lo recuerdo), butoden 3, street fighter, super mario world...merecen ser traducidos???...pues quizás no (que para mi si pese a que entiendo el inglés sin problema)...pero son juegos cojonudos para empezar a manejar editores hexadecimales, editores de tiles, etc...
La putada en casi todas las traducciones, no sólo en las españolas, son los caracteres especiales.

Los juegos que comentas están traducidos sí, pero al estilo SNK, sin tildes ni símbolos de exclamación ni ñ.

Ánimo, toca leer muuuucho...
josete2k escribió:La putada en casi todas las traducciones, no sólo en las españolas, son los caracteres especiales.

Los juegos que comentas están traducidos sí, pero al estilo SNK, sin tildes ni símbolos de exclamación ni ñ.

Ánimo, toca leer muuuucho...


Gracias Josete!!! en ello estoy, editando sprites con el tile monster...de momento he conseguido modificar para que esté la Ñ

Imagen

el sprite es mejorable, lo se...pero para ser el primero y hacerlo en 5 minutos no está mal [ayay]

En este caso,todas las "contracciones" del tipo 't,'s van todas el la tabla de caracteres de manera conjunta...no hay un espacio para la apostrofe y otro para la letra, por lo que los signos de abrir interrogación y abrir exclamación se puedes sacar de ahí (como he hecho con la Ñ)... así que mientras voy haciendo la tabla iré editando sprites
Ralph escribió:Entiendo, así que acceder al código del juego siempre es posible, e imagino entonces que acceder a los gráficos y sonidos tambien. ¿Dónde está la dificultad?, es decir, ¿cual sería mas o menos el proceso de acceder a todo el contenido de un cartucho, código incluído?.


La dificultad está en dumpear todo el texto en ensamblador e imaginarte qué hace cada rutina y cada variable, localizar la rutina correcta, de dónde se llama, qué hace... etc, etc... Vamos, que con tiempo todo sale, pero en principio es complicado. Luego lo siguiente difícil es saber desde qué partes del juego se llama cada cosa, de modo que si quieres cambiar esa rutina has de tener en cuenta que se puede usar con distintos parámetros de entrada y la que tu re-escribas ha de ser compatible con todos.
El mejor ejemplo de esto son las rutinas de descompresión para gráficos. El Trearuse Hunter G tiene TODOS los gráficos comprimidos para que quepa el juego en 24 megas y hay varias rutinas de compresión diferentes para sacar tiles 2BPP, 3BPP y sprites 4BPP. Yo he llegado a extraer todos los gráficos del juego y podría optimizar todos los bloques comprimidos para que ocupen menos (de hecho, lo llegué a hacer) pero claro, no sé si eso va a funcionar en TODAS las situaciones a las que se llame esas rutinas de descompresión.

El proceso para llegar a acceder a ese contenido se basa en abrir el juego con un debugger como el SNES9x, dumpear el código, la VRAM y la RAM, analizar la VRAM para saber dónde está el gráfico que quieres editar, buscarlo en qué dirección de RAM está (o si no lo está, trazar el código para ver cuándo y cómo se escribió en RAM o si se metió directametne de ROM a VRAM), y luego decidir: si se envió de ROM a VRAM es que no está comprimido y se puede editar directamente en ROM; si el gráfico/texto pasó por RAM, quizá se descomprimió y entonces tendrás que analizar el código que dumpeaste para ver qué instrucciones fueron las que volcaron el gráfico/texto a RAM.
magno escribió:...

Desde mmi punto de vista, m4x1m0, esto te lo puedes plantear de dos formas:
* aprendes lo básico de cómo modificar las ROMs y con herramientas ya creadas vas modificando juegos poco a poco, sin prisa y siguiendo unas pautas mecánicas. Así la curva de aprendizaje es muy "empinada" porque aprendes mucho rápidamente y en seguida tienes resultados visibles. Esos conocimientos de cada herramienta además se puede trasladar a otras consolas si conoces las heramientas para hackear con ellas.

...


Yo desde mi posicion de traductor aficionado te recomiendo el primer método de Magno para iniciarte y si te llama el tema y quieres ir a más, pues ya sabes.

Este método tiene sus pegas, la principal puede ser la de localizar algunos elementos a traducir y luego la limitacion de espacio en la traduccion (al menos yo me adapto al espacio que ocupaba el texto original, ya que modificar el juego para añadir espacios ya es demasiado para mí)

En mi caso, me he metido en el mundo de Megadrive (que ese sí que tiene poca scene comparada con SNES) y estoy con juegos "sencillitos". Y remarco lo de sencillitos porque tienen poco texto, no por otra cosa, ya que me he encontrado con graficos comprimidos, texto comprimidos, diferentes tablas para el texto dentro del mismo juego y otras curisidades que me han dado más de un dolor de cabeza.

Y todo esto para traducir Castle Of Illusion (Traducción 100%) y ahora estoy sacando a ratos el Quackshot (que llevaré un 75 %, a ojo de buen cubero), asi que no me plateo meterme con según que juegos...

Imagen
gracias magno y jhon...de momento creo que me acogeré al primer punto de magno. Para empezar es creo yo lo mejor...a medida que me vaya familiarizando con las aplicaciones, pruebe diferentes sistemas, ya iré viendo en qué evoluciona la cosa ;)
el terry escribió:
m4x1m0 escribió:Tambien hay mas vida ademas de los rpgs

Pero a diferencia de estos, son perfectamente jugables sin entender ni papa


Claro, como los juegos de estrategia, ponte un romance de los tres reinos o algo similar en japo, verás, verás :D
m4x1m0 escribió:...

bienvenido amijo, te esperan horas de probar y probar y probar [fumando]

Maduin escribió:A mi tambien me interesa mucho, si no fuese porque no se sacar los textos habria hecho alguna tradu ya... Programa muy bueno para traducir los textos es el notepad++ que fue lo que me recomendaron los de vagrant para hacer una parte del valkyria de la DS, y venia hasta donde podias meter texto y no... Pero claro el texto del juego lo extrajeron ellos, no yo. [buuuaaaa]

un saludo.

los textos del valkyrie profile de ds los extrajo skybladecloud, que el suele extraer los textos en formato xml por comodidad (que se pueden abrir y traducir los textos con notepad++ este formato)
pero vamos es solo un editor de texto
magno escribió:La dificultad está en dumpear todo el texto en ensamblador e imaginarte qué hace cada rutina y cada variable, localizar la rutina correcta, de dónde se llama, qué hace... etc, etc... Vamos, que con tiempo todo sale, pero en principio es complicado. Luego lo siguiente difícil es saber desde qué partes del juego se llama cada cosa, de modo que si quieres cambiar esa rutina has de tener en cuenta que se puede usar con distintos parámetros de entrada y la que tu re-escribas ha de ser compatible con todos.
El mejor ejemplo de esto son las rutinas de descompresión para gráficos. El Trearuse Hunter G tiene TODOS los gráficos comprimidos para que quepa el juego en 24 megas y hay varias rutinas de compresión diferentes para sacar tiles 2BPP, 3BPP y sprites 4BPP. Yo he llegado a extraer todos los gráficos del juego y podría optimizar todos los bloques comprimidos para que ocupen menos (de hecho, lo llegué a hacer) pero claro, no sé si eso va a funcionar en TODAS las situaciones a las que se llame esas rutinas de descompresión.

El proceso para llegar a acceder a ese contenido se basa en abrir el juego con un debugger como el SNES9x, dumpear el código, la VRAM y la RAM, analizar la VRAM para saber dónde está el gráfico que quieres editar, buscarlo en qué dirección de RAM está (o si no lo está, trazar el código para ver cuándo y cómo se escribió en RAM o si se metió directametne de ROM a VRAM), y luego decidir: si se envió de ROM a VRAM es que no está comprimido y se puede editar directamente en ROM; si el gráfico/texto pasó por RAM, quizá se descomprimió y entonces tendrás que analizar el código que dumpeaste para ver qué instrucciones fueron las que volcaron el gráfico/texto a RAM.


Lo interesante es conseguir el código del juego para modificar el comportamiento, jugabilidad, etc... tenía entendido que descifrar el código obtenido era lo realmente difícil imposible, y que sólo con los que han sido liberados (como el del B.O.B) se podría trastear a fondo.

La idea que tenía es que con cualquiera se podrían cambiar gráficos, pero debido a que el código no se podía modificar, no se podrían añadir por ejemplo mas frames de animación. Ahora veo que estoy bastante equivocado (que uno puede liarse a modificar código, y sacar otra cosa totalmente diferente con otro juego como base, e incluso añadiendo cosas nuevas).


Observo un comportamiento del software en cuanto a las limitaciones de traducción (sin toquetear códigos), y es que cada carácter tiene que tener un tamaño y ser identificado de igual forma, que el sustituído... por esto, si yo quisiera sustituir el fondo plano de un juego, ¿sólo sería posible si lo adapto desde el código?.
Ralph escribió:Lo interesante es conseguir el código del juego para modificar el comportamiento, jugabilidad, etc... tenía entendido que descifrar el código obtenido era lo realmente difícil imposible, y que sólo con los que han sido liberados (como el del B.O.B) se podría trastear a fondo.

La idea que tenía es que con cualquiera se podrían cambiar gráficos, pero debido a que el código no se podía modificar, no se podrían añadir por ejemplo mas frames de animación. Ahora veo que estoy bastante equivocado (que uno puede liarse a modificar código, y sacar otra cosa totalmente diferente con otro juego como base, e incluso añadiendo cosas nuevas).

Observo un comportamiento del software en cuanto a las limitaciones de traducción (sin toquetear códigos), y es que cada carácter tiene que tener un tamaño y ser identificado de igual forma, que el sustituído... por esto, si yo quisiera sustituir el fondo plano de un juego, ¿sólo sería posible si lo adapto desde el código?.


Hay dos códigos a diferenciar, que realmente es el mismo:

* Uno es el código fuente a alto nivel que programaban los programadores de los juegos; en la última época de la SNES ya empezaban a usar lenguajes como C, que no estaba tan optimizado a bajo nivel y que por tanto puede dar problemas con los cuellos de botella que forma la CPU a veces. Conseguir ese código es imposible a menos de que los desarrolladores lo liberen y eso te permitiría hacer muchísimas cosas porque el código es más legible y entendible.

* Otro es el código ensamblador que se compila a partir del código a alto nivel, digamos que el de alto nivel es el que entiendes tú y el de bajo nivel el que entiende el procesador. Ese código siempre está accesible porque es la ROM en sí: la traducción de cada instrucción de ensamblador en un byte es lo que se llama "código máquina", y esa amalgama de bytes que ves en una ROM es el código máquina, más los bytes que representan las tiles, los bytes que representan la música, los bytes que representan las paletas, etc...

El problema es que acceder al código ensamblador implica que cada variable que hace una cosa en concreto se representa por una posición de memoria y vete tú a saber qué significa el valor ahí guardado. Digamos que si en C++ t eencuentras con el código:

X_Cord++


Puedes saber más o menos por el nombre que lo que se ha incrementado es una coordenada X de algo. Pero cuando se compila y se transforma en:

LDA.b $1450
INC A
STA.b $1450


¿Cómo sabes lo que se está incrementando? Con mucho esfuerzo e intuición podrías llegar a saber que es una coordenada X de algo, pero solo tras seguir la pista de la variable $1450 y comprobando qué hace en cada uno de los sitios donde se usa.

Por eso, tener el código siempre lo tienes, pero saber lo que hace ya es otro cantar...
magno escribió:Hay dos códigos a diferenciar, que realmente es el mismo:

* Uno es el código fuente a alto nivel que programaban los programadores de los juegos; en la última época de la SNES ya empezaban a usar lenguajes como C, que no estaba tan optimizado a bajo nivel y que por tanto puede dar problemas con los cuellos de botella que forma la CPU a veces. Conseguir ese código es imposible a menos de que los desarrolladores lo liberen y eso te permitiría hacer muchísimas cosas porque el código es más legible y entendible.


La gracia de usar C es que permite automatismos para añadir funciones al programa, pero yo me pregunto, ¿esos automatismos no se podrían agregar en ensamblador para evitar esos cuellos de botella? (para no matar moscas a cañonazos, tu ya me entiendes... partes en C, y partes en ASM).

De todos modos, al grano, ¿estás diciendo que los códigos que no han sido programados en ASM pueden toquetearse sin límites?, o al compilar de C, todo lo que hay en la rom es ASM.
Ralph escribió:La gracia de usar C es que permite automatismos para añadir funciones al programa, pero yo me pregunto, ¿esos automatismos no se podrían agregar en ensamblador para evitar esos cuellos de botella? (para no matar moscas a cañonazos, tu ya me entiendes... partes en C, y partes en ASM).


No entiendo muy bien a qué te refieres con "automatismos"; la diferencia de programar en C u otro lenguaje de alto nivel y programar en cualquier ensamblador específico de una plataforma es que el lenguaje de alto nivel se parece más a "cómo dirías las cosas que quieres que el programa algo" y entonces no te preocupas de asignar variables locales, globales, arrays, controlar la pila... Si te refieres a eso con lo de "automatismos", sí, efectivamente es más óptimo hacerlo en ASM, aunque más complejo porque realmente te quitas la potencia del lenguaje de alto nivel. Si por automatismos te refieres a rutinas, macros o cosas así, en ASM también existen.

Ralph escribió:De todos modos, al grano, ¿estás diciendo que los códigos que no han sido programados en ASM pueden toquetearse sin límites?, o al compilar de C, todo lo que hay en la rom es ASM.


No, no, creo que estás liado... Como dije antes TODO LO QUE HAY EN LA ROM ES CÓDIGO MÁQUINA, y no hay forma de saber en qué lenguaje se programaó originalmente, porque sea cual sea el lenguaje que uses, siempre se acaba compilando en lenguaje máquina. Así cuando hackeas un juego, el primer paso es convertir ese código máquina en algo legible, que es el código ensamblador: cada byte de la ROM es una instrucción acompañada de su dato inmediato o dirección de memoria. Si te estudias bien ese código, podrás hacer lo que quieras con el juego, independientemente de que alguien programara ese código así, directamente en ensamblador, o bien que lo programara en C y eso que estarías viendo entonces sería el resultado de la compilación.

Para verlo más claro: después de mucho analizar el código ensamblador de Treasure Hunter G llegué a la conclusión de que fue programado en un lenguaje de más alto nivel porque todo la rutina principal era un bucle infinito (toda la pinta deser un while(1) en C) y luego cada rutina usaba estructuras comunes (toda la pinta de ser un struct) y punteros a funciones. Si no fue C, sería Pascal o algo así. Sin embargo, yo de ese juego solo tenía el código ensamblador, nunca el código fuente original en C (o Pascal) y sí que pude modificar cosas del juego a mi antojo.
Otro ejemplo: para programar Secret of Evermore, el equipo de programación se creó un lenguaje de "scripting" es decir, que ellos crean unas rutinas en ensamblador que ejecutan ciertas acciones; la rutina main del juego va leyendo comandos de ese script (que está guardado en la ROM) y va ejecutando acciones a través de esas rutinas; es algo muy parecido al HTML: el script para el Secret of Evermore contenía cosas como:
<TEXT>Esto es texto de los diálogos</TEXT>

que mostraba texto en pantalla o cosas como:
<EVENT>16</EVENT>
para ejecutar ciertos eventos de una lista.
Hola comunidad, antes que nada me disculpo si este post no esta en el lugar corrspondiente, les comento, somos un par de amigos que no encanta la Sega Saturn y todo a lo que sega se reiere, estamos empezando la traduccion de Shining The Holy Ark del ingles al Español, no estamos poniendo al tanto con toda la info que vamos recopilando, ya hemos descubierto que archivos son los que tienen los textos, son los *.MDX , estos en su cabecera tienen todo el abecedario, lo podemos apreciar con el tile molester en 2bpp planar, Tambien nos llama la atencion que hay un archivo que se llama DEBUG.FNT, ahi esta todo el abecedario junto con los simbolos y se puede ver configurando a 8bpp liniar, estamos un tanto trabados por que no entendemos que tenemos que hacer para darnos cuenta en donde estan los textos ya que no somos capaces de encontrarlos, nos podrian echar una mano de como seguir de aqui en adelante?

http://img827.imageshack.us/img827/5008 ... lester.jpg

Tambien necesitamos saber si el unico modo de saber en donde estan los textos del juego es ejecutando el emulador yabause y cuando aparezca el subtitulo en modo debug ver el vdp1/2 y ver de donde se estan cargando los subtitulos y como, si alguien nos puede explicar de como hacer esto serial de gran ayuda...

Desde ya muchas gracias por todo...
Me ofrezco a ayudar con las traducciones a cualquiera que lo necesite, tengo tiempo de sobra..
dejo aquí un rar con bastante material antiguo del mundo del romhacking, hay tutoriales y programas varios que juraría que son todos de libre distribución, si hay algo irregular avisadme y resubo todo correctamente

os encontraréis explicaciones de conocidos romhackers que os sonarán porque seguramente habréis jugado con sus traducciones, los creditos a ellos
http://www5.zippyshare.com/v/42981993/file.html
magno escribió:No entiendo muy bien a qué te refieres con "automatismos"; la diferencia de programar en C u otro lenguaje de alto nivel y programar en cualquier ensamblador específico de una plataforma es que el lenguaje de alto nivel se parece más a "cómo dirías las cosas que quieres que el programa algo" y entonces no te preocupas de asignar variables locales, globales, arrays, controlar la pila... Si te refieres a eso con lo de "automatismos", sí, efectivamente es más óptimo hacerlo en ASM, aunque más complejo porque realmente te quitas la potencia del lenguaje de alto nivel. Si por automatismos te refieres a rutinas, macros o cosas así, en ASM también existen.


Ok, eso preguntaba.

Vamos, que no es que una rutina que añada una función por software no pueda ser implementada en ensamblador de forma automatizada, en el código del hilo, sino que la dificultad en si está en interpretar el lenguaje (en todo caso me refiero a funciones que hay que programar para que funcionen, no a hacer llamamientos a funciones que están implementadas por hardware).

Es que existe un poco el mito de que C te lo soluciona todo, como si en ensamblador no fuese posible automatizar el proceso (de programación) con rutinas que añaden funciones al código de un programa. Ahora, la cuestión es, ¿existen SDK's así?... se han programado muchas cosas por software, y es una lástima que se hayan perdido.


magno escribió:No, no, creo que estás liado... Como dije antes TODO LO QUE HAY EN LA ROM ES CÓDIGO MÁQUINA, y no hay forma de saber en qué lenguaje se programaó originalmente, porque sea cual sea el lenguaje que uses, siempre se acaba compilando en lenguaje máquina. Así cuando hackeas un juego, el primer paso es convertir ese código máquina en algo legible, que es el código ensamblador: cada byte de la ROM es una instrucción acompañada de su dato inmediato o dirección de memoria. Si te estudias bien ese código, podrás hacer lo que quieras con el juego, independientemente de que alguien programara ese código así, directamente en ensamblador, o bien que lo programara en C y eso que estarías viendo entonces sería el resultado de la compilación.


Si, eso es básico. Todo código compilado desemboca en código en asm... mi duda era sobre la posibilidad de invertir el proceso, o si defintivamente permanece cifrado sin remisión.

O sea, que trastear se puede trastear igual, pero lo que es saber que hace lo que tocas...

¿Que es lo que imposibilita añadir cosas en ASM, en el código compilado resultante?. En los basic de msx, cada rutina tiene un "nombre" en el código, determinado por un número de línea... imagino que una vez compilado, esa característica haría casi imposible añadir algo en ASM (una vez compilado el programa). En estas roms compiladas en C, ¿ocurre algo parecido?, o es otro tipo de imposibilidad técnica el que limita añadir mas código extra en el código compilado, por supuesto en ASM.


magno escribió:Otro ejemplo: para programar Secret of Evermore, el equipo de programación se creó un lenguaje de "scripting" es decir, que ellos crean unas rutinas en ensamblador que ejecutan ciertas acciones; la rutina main del juego va leyendo comandos de ese script (que está guardado en la ROM) y va ejecutando acciones a través de esas rutinas; es algo muy parecido al HTML: el script para el Secret of Evermore contenía cosas como:
<TEXT>Esto es texto de los diálogos</TEXT>

que mostraba texto en pantalla o cosas como:
<EVENT>16</EVENT>
para ejecutar ciertos eventos de una lista.


Algo parecido a eso es a lo que me refiero, solo que en mi ejemplo hablo de añadir un comportamiento a la manera en que el hardware gestiona técnicamente un programa (como manejar por software unas rutinas parecidas al modo 7, cuando un sistema de vídeo no las tiene implementadas por hardware).

Es decir, crear unas rutinas en ensamblador que implementen esta función (modo 7), de manera que puedan ser metidas en el código principal del programa, con la ventaja de que la naturaleza del lenguaje ASM lo deja hecho mejor optimizado que si lo hicieras en C.
En C tienes el handicap de una menor optimización, así que supngo que mi pregunta es, ¿ese proceso de automatizado, bajo asm implicaría una mayor optimización que en C?.


Necesito dormir xD
28 respuestas