Hoy en la mañana me he levantado con ganas de continuar mi más reciente proyecto, ese proyecto al que le he invertido un par de horas y que, hasta el momento, me he asegurado de que hasta el más mínimo detalle goze de una gran calidad.
Ya tenía tiempo de no continuarlo, así que lo primero que hice fue examinar el entorno, ver que era lo que había dejado pendiente, y tratar de seguir desarrollandolo con el nivel de calidad promedio. En este caso presté especial atención a la forma en que se van a gestionar los elementos gráficos en pantalla.El lenguaje de programación que estos usando, GML, es interpretado a travéz de unrunner programado enteramente en Delphi, por lo tanto el rendimiento es claramente inferior respecto a otros lenguajes que se ejecutan directamente como el lenguaje C.
Es ahí donde entra la cuestión: ¿Cuál es el método más optimizado para lograr lo que me propongo? . Mientras me iba a hacer mi rutina de ejercicio mi mente se abrió para darme a la mano múltiples opciones:
— Dibujado en tiempo real: Esto no requiere mucho razonamiento, simplemente sugiere que cualquier gráfico que se tenga que mostrar, va a ser dibujado el número de veces a la cantidad de fotogramas que la aplicación está coriendo por segundo. El problema con éste método es que una de las características escenciales de la aplicación es la de dibujar a mano libre sobre la pantalla, y tener que dibujar todos los pixeles que han sido marcados en pantalla multiplicado por los fotogramas a los que se ejecuta la aplicación, supone una inmensa carga que no todos los ordenadores pudieran sobrellevar.
— Cantidad de superficies = Número de cuadros: La aplicación que estoy desarrollando maneja cuadros de dibujado independientes, prácticamente no existe límite alguno que suponga un acotamiento para una implementación más perfecta de éste método. Actualmente los cuadros pueden viajar de los 550x100 hasta los 550x600 pixeles y manejar una superficie limpia con dimensiones definidas, a nivel de programación, es relativamente flexible. El problema reside en la memoria de vídeo, la creación de cada superficie consume cierta cantidad de memoria de vídeo, y si no se cuenta con memoria suficiente el resultado sería un error que impediría la correcta ejecución de la aplicación.
— Superficies maestras: Tengo la ligera sencación de que las aplicaciones profesionales de escritorio de empresas cual Microsoft o Apple utilizan este tipo de método, claro, ésto lo deduzco a travéz de ingeniería inversa realizada en mi mente, no puedo asegurar nada. Consiste en definir 2 superficies base del tamaño de la ventana de la aplicación y que se apoyen para dibujar prácticamente todo, a partir de una variable definida que sería la posición vertical, la superficie actual va a dibujar todo desde ese punto hasta el límite definido por el alto de la ventana; Si la variable definida de posición cambia entonces la superficie principal se mantendrá activa pero el resto de contenido que se tiene que mostrar, debería ser generado gracias al apoyo de la otra superficie, sin importar si el valor de la posición crece o viceversa. El posible problema podría encontrarse, una vez más, en la memoría de vídeo, pero frente a la opción anterior es infinitamente más viable.
— Conversión de formatos: Ante el dibujado en tiempo real, el verdadero problema vendría siendo el seguimiento de cada pixel del dibujado a mano libre, éste método consiste más bien en una revisión de aquél, para hacerlo más viable. Digamos que se ha entrado al modo de dibujado a mano libre y se ha hecho lo justo para la ocasión, entonces el usuario se dispone a finalizar el modo de dibujado, y aquí es donde inicia el proceso de conversión; Con una sóla ejecución bastaría para almacenar en un sprite todos los pixeles que se han pintado en tal modo, el resultado sería una imagen de mapa de bits sin compresión, pero internamente gracias a la herramienta ImageMagick se conseguiría un formato de compresión compatible con el lenguaje GML para inmediatamente volver a cargar el contenido a la aplicación, el resultado sería un increíble ahorro en el rendimiento. Por ahora no he encontrado un problema en éste método que se merezca mención alguna.
Y tú, ¿Te complicas tanto las cosas como yo con el objetivo de conseguir lo mejor?
— Eduardo Ibarra
