› Foros › Retro y descatalogado › Consolas clásicas
thafestco escribió:m4x1m0 escribió:y la scene en español de snes es escasa...
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
m4x1m0 escribió:Tambien hay mas vida ademas de los rpgs
Ralph escribió:La pregunta es: ¿se puede hackear cualquier juego?.
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
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...
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?.
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.
...
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
m4x1m0 escribió:...
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.
un saludo.
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.
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 realmentedifícilimposible, 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?.
X_Cord++
LDA.b $1450
INC A
STA.b $1450
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.
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).
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.
<TEXT>Esto es texto de los diálogos</TEXT>
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.
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.
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.