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