...y mis homebrews están bien disponibles aquí y en otras páginas.

Por ejemplo, busca qué homebrew ganó el concurso de esta página, el Scenery Beta, en sección de juegos de PC.

Pero vaya, lo que importa no es "cuántos homebrews has hecho", sino si tengo o no razón cuando digo que los vuestros son un tanto engañifa, y que prometen cosas que no son útiles (y vas diciendo que "son el mejor de su categoría y tal y cual").

Y tú aún tienes que responder para qué sirve esto de "limpiar la RAM" de tu homebrew, que vas dejando a la gente colgada.

Pero vaya, esto es lo que hacéis. Intentáis darla con queso con "alternates recoverys M33 in the night", y cuando alguien demuestra que no son así las cosas, vais al ataque personal.

Pues vaya. Pues seré un hijo de la grandísima, pero eso ni me da ni me quita razón.

Bueno, me gusta ser pesimista... no veas los alegrones que me llevo XD

Tienes toda la razón en lo de que al apagar la máquina, la RAM se limpia (y más que eso). Es que, incluso, al abrir un programa, lo más normal del mundo es que la RAM se "limpie". Ejemplo, el mismo LuaPlayer, que llevan todos los programas de Lua. Cuando inicia, considera que toda la RAM útil está libre. Ocupa una parte y deja el resto para el programa. Etc.

De hecho, si nos ponemos puristas, muy puristas, la RAM se "limpia" continuamente, en cuanto a hardware se refiere. Las memorias actuales pierden la energía muy rápidamente (unas más que otras), y por eso hay que "refrescarlas", reescribir continuamente los datos que habían. Para hacernos una idea de la velocidad de pérdida... la de refresco se mide en Megahertz, que significa "millones de veces por segundo". Las de PC de ahora van a 800 o más, no sé cuánto será la de PSP, pero dudo que baje mucho de los 100... más bien para arriba.

Intentando responder a lo de para qué limpiar la RAM... bueno, eso es útil para que el programador gestione bien la ejecución del programa, y además... ya tiene que ser un programa de, digamos, "cierta envergadura".

Intentaré explicarlo con un símil que usa pspgorrister en su (buenísimo) tutorial, sección de PC, sobre punteros y demás. Pongamos que la RAM útil es como uno de esos muros de cajas de seguridad de los bancos o casinos, que ves en las películas. Hay de todos los tamaños, y contienen cosas distintas (una imagen, un texto, un número, una hoja de datos). Cada caja tiene una llave, y en la llave hay un código que indica qué caja abre, y/o un número de referencia; quizá alguna información más. Esta "llave" es lo que se llama un puntero, porque apunta a un dato concreto.

Insisto en que esto es una aproximación y adaptación del símil de pspgorrister; en este caso, en realidad, no sólo estaríamos hablando de punteros (hay también las llamadas a función y un largo etcétera, pero intento simplificar... y es lo mejor que se me ha ocurrido XD).

Bueno, ahora viene el meollo. Resulta que ese "muro de cajas de seguridad" no es fijo, sino modular y además está cambiando continuamente. Se añaden cajas nuevas, se quitan viejas, se añaden llaves nuevas, y hay llaves que abren cajas que ya no existen. Puedes acabar con un enorme montón de llaves. Y las llaves ocupan espacio.

Esto te pasa cuando cambias mucho "las cajas", claro. Que no tiene que ver con si hay "muchos o pocos datos", sino con factores distintos. Más bien el tipo de datos y operaciones (han hecho un buen trabajo documentando las maneras de mejorar la recogida de basura). (De hecho, también pasa que cuando "destruyes la llave", el espacio que ocupaba esa caja pasa a considerarse disponible y puedes meter otra nueva ahí, porque el muro no es infinito. Dicho "en tésnico", la recolección de basura funciona tanto para los objetos de recolección que ya no tengan valor -variables globales=nil- como para los objetos no referenciados).

Y en un programa de estas características, la "generación de basura" es mínima. Es que no da apenas trabajo al intérprete. ¿Qué podría generar mucha basura, cuándo sería útil?

Bueno, por ejemplo:

• Creas un mapa de casillas en que tanto el mapa, como las casillas, como datos adicionales, son "clases" (o como quieran llamarse en Lua) con sus metatablas y sus métodos, e invocas como seis o siete métodos por cada una de las, pongamos, 100 casillas, al crearlas. (Muchas llamadas a funciones)
• Revisar cada turno todas esas casillas con sus métodos, y crear cada turno una tabla global nueva con los enemigos (callers y tablas globales huérfanas, que son las bestias pardas del garbage)

Pero en cambio, ojo con lo de los "datos no usados". Si cargas una imagen, la asignas a una variable, y no la presentas en todo el programa... eso es un dato "usado". Así que lo que importa, como siempre, es que el programador gestione los recursos disponibles.

Aún así, no estoy seguro que con sólo 100 casillas la creación de "basura" fuera muy significativa. Es para large numbers of objects (10.000 tablas de cuatro dimensiones, por ejemplo...)

La razón básica para forzar una recogida de basura, muchas veces, no es porque se necesite (o no se necesita mucho, o "aún no la necesitas del todo", o...), sino para evitar que el programa la haga automáticamente en el peor momento. Y como ya la ibas a hacer, pues lo adelantas, y un problema menos. Repasar toda la RAM a ver dónde están las "llaves inútiles" y cómo volver a montar el mueble de IKEA, quieras que no, cuesta su tiempo y recursos. Y puede pasar, si no lo controlas, que el programa se "congele" un instante cuando estás esquivando una bala enemiga, etc. Eso queda feo. Así que, por ejemplo, fuerzas la recogida de basura al principio de cada turno o "bucle principal" (antes de mover las balas, naves, etc.) y así te aseguras que lo que vea el jugador sea "como debe ser", y el programa se ejecute con estabilidad, sin saltos ni botes ni congelaciones instantáneas.

Así que bueno, en resumiendo: a un usuario no le sirve de nada relevante forzar que este programa limpie la RAM que haya ensuciado él (algo que, insisto, Lua ya hace automáticamente cada X tiempo). Y dudo seriamente que sirva de algo en y para este programa. No parece generar cantidades significativas de garbage por lo simple, y ya se hace solo...