Comunidad Game Maker

Estoy en medio de un proyectillo; ahora mismo tengo en mente c?mo voy a programar algunos sistemillas. La cuesti?n es...

A como tengo planeado programarlo, necesito utilizar continuamente las funciones object_event_add();, object_event_clear();, script_get_text(); y execute_string();, que b?sicamente realizan operaciones sobre los recursos del juego y sobre el lenguaje.

Algunos me dijeron que esta clase de funciones afectan al rendimiento del juego, y aunque no he hecho todav?a ning?n test para corroborarlo, ?alguien sabe si esto es cierto?

Saludos :).

Citarexecute_string()

Esta funcion es el terror de los terrores para los juegos de gamemaker  XD si la vas a usar, que sea muy poco frecuente (como guardar partida, exportar un mapa, cosas asi)
Sobre las demas...

Citarobject_event_add();, object_event_clear();

Para que usar esas? a?ade los eventos en el editor y ya esta... luego por ej en cada pieza de codigo pones un if al principio y una variable o algo, asi no tienes que ir borrando y creando eventos, ademas que esas funciones solo sirven si creas objetos en el aire.

Citarscript_get_text()

Esta es para exportar los script no? usala tranquilamente, ya que todas las funciones de exportar cosas deben ser lentas, pero como son cosas que se hacen poco frecuentes no pasa nada

En general todas las funciones get (exceptuando draw_get_pixel) son muy r?pidas. Entonces script_get_text es inofensiva.. xD.
Execute string... mh.. es lenta, pero tampoco mucho... mientras no la uses en step o en draw est? todo bien, para eso usa object_event_add, que creo que ser?a como un execute string pero por unica vez... asi puedes crear facilmente eventos step y draw, colisiones, o alarmas constantes...

Habr?a que hacer pruebas, yo he trabajado con todas esas funciones pero no tanto como para decirte que tan r?pidas son... si las usas con moderaci?n pueden ser muy ?tiles.

en cuanto a object_event_clear(), tampoco me preocupar?a ya que borrar cosas siempre es mucho m?s r?pido que agregarlas no??

siempre se dice que la funcion execute_string es lenta, y si es comprobable pero tampoco es para tenerle miedo...facilmente la he usado algunas veces en eventos como draw(se vuevle muy muy util para dibujar textos comoplejos). y no es lenta...pero cuando ya la usas en 2 o 3 veces en eventos draw se siente la diferencia...
en cuanto a las funciones objects que mencionas nunca las he notado nada lentas

puede que sea lenta al momento de leerlo secuencialmente a los string por lo cual se puede evitar haciendo oraciones mas cortas

No se ustedes pero execute_string() es una de las funciones mas lentas de gm ademas de que no funcionara en gm studio, no funciona en gm html5 y de echo no hay funci?n como esa para ning?n lenguaje de programaci?n compilado, lo que la hace una mala practica para principiantes, de echo la mayor?a de las funciones que usen strigs para obtener informaci?n del juego son muy lentas como:

Citarvariable_global_get()
variable_global_array_get()
variable_local_get()
variable_global_set()
ETC.

Todas las funciones que involucren evaluaci?n en tiempo real son lentas porque deben ser interpretadas dos veces para funcionar.
Pod?s hacer la prueba. En un juego con un solo room, en el creation code:
[gml]best_time = -1;
repeat (100000) {
    start_time = current_time;
    // Inicio de c?digo a testear.
    execute_string("a = 1 + 2;");
    // Fin de c?digo a testear.
    if (best_time == -1) {
        best_time = current_time - start_time;
    } else {
        best_time = min(best_time, current_time - start_time);
    }
}
show_message("El tiempo es de " + string(best_time) + " milisegundos.");[/gml]
N?tese que al final se muestra el mejor tiempo, y no el promedio o similar. As? es m?s preciso.

Cita de: Wadk en Enero 02, 2012, 11:00:08 AM
N?tese que al final se muestra el mejor tiempo, y no el promedio o similar. As? es m?s preciso.

Hola, para fines estadisticos yo recomendaria usar "el peor tiempo" en lugar de "el mejor tiempo", es una recomendacion como Atcuario. Saludos.

Cita de: Zeit en Enero 02, 2012, 05:04:27 PM

Cita de: Wadk en Enero 02, 2012, 11:00:08 AM
N?tese que al final se muestra el mejor tiempo, y no el promedio o similar. As? es m?s preciso.

Hola, para fines estadisticos yo recomendaria usar "el peor tiempo" en lugar de "el mejor tiempo", es una recomendacion como Atcuario. Saludos.

Mala idea. La raz?n por la que el tiempo no es siempre exactamente igual es porque otros procesos consumen cantidades variables de poder de procesamiento. Los tiempos m?s lentos ocurren cuando esos otros procesos consumen m?s. Es posible que durante la prueba alg?n proceso intente realizar una tarea compleja y haga que el c?digo tarde m?s de lo normal en ejecutarse.

Cita de: Wadk en Enero 02, 2012, 07:41:13 PM
La raz?n por la que el tiempo no es siempre exactamente igual es porque otros procesos consumen cantidades variables de poder de procesamiento. Los tiempos m?s lentos ocurren cuando esos otros procesos consumen m?s. Es posible que durante la prueba alg?n proceso intente realizar una tarea compleja y haga que el c?digo tarde m?s de lo normal en ejecutarse.

Exactamente por esa razon se debe considerar "el peor tiempo", pues lo que es seguro es que hayan mas procesos al mismo tiempo (en mi caso utorren, jdownloader, etc. cuando estoy jugando) y esto siempre va a afectar el rendimiento.

Cuando las cosas andan tranquilas en cuanto programas abiertos no hay problema, el juego va a ir fluido, pero si se te ocurre abrir mas programas se vera afectado, entonces tu medida de "el mejor tiempo" es insuficiente y cuando tomas "el peor tiempo", no importa si abres pocos o muchos programas simultaneamente, en general va a tener el mismo rendimiento.

De hecho, estoy exagerando al decir "el peor tiempo", en realidad debes hacer un intervalo de confianza o maxima probabilidad (dependiendo de tu orientacion estadistica) para dar "un peor tiempo promedio".

Saludos.

Genial, pues muchas gracias a todos por los datos, har? un par de pruebas. El test me servir? mucho Wadk. Pueden dar el tema por resuelto.

En todo caso, si execute_string va a ser excluida de GMStudio, creo que optar? por otras soluciones :). Saludos.

Me alegro de que te sirva, henkuu.

Cita de: Zeit en Enero 02, 2012, 08:14:58 PM

Cita de: Wadk en Enero 02, 2012, 07:41:13 PM
La raz?n por la que el tiempo no es siempre exactamente igual es porque otros procesos consumen cantidades variables de poder de procesamiento. Los tiempos m?s lentos ocurren cuando esos otros procesos consumen m?s. Es posible que durante la prueba alg?n proceso intente realizar una tarea compleja y haga que el c?digo tarde m?s de lo normal en ejecutarse.

Exactamente por esa razon se debe considerar "el peor tiempo", pues lo que es seguro es que hayan mas procesos al mismo tiempo (en mi caso utorren, jdownloader, etc. cuando estoy jugando) y esto siempre va a afectar el rendimiento.

Cuando las cosas andan tranquilas en cuanto programas abiertos no hay problema, el juego va a ir fluido, pero si se te ocurre abrir mas programas se vera afectado, entonces tu medida de "el mejor tiempo" es insuficiente y cuando tomas "el peor tiempo", no importa si abres pocos o muchos programas simultaneamente, en general va a tener el mismo rendimiento.

De hecho, estoy exagerando al decir "el peor tiempo", en realidad debes hacer un intervalo de confianza o maxima probabilidad (dependiendo de tu orientacion estadistica) para dar "un peor tiempo promedio".

Saludos.

No. Est?s asumiendo que es ?til saber un tiempo por s? solo, que no lo es. Saber el peor tiempo al tener varios procesos es in?til, porque ese tiempo depende de los procesos que se est?n ejecutando, y esos procesos dependen del usuario. Adem?s, el tiempo resultante tambi?n depende de las caracter?sticas de la computadora, lo cual tambi?n depende del usuario.
En fin, que tener solo un tiempo no sirve de nada en absoluto.
Por eso la idea es, dados varios c?digos que logran el mismo resultado, averiguar cu?l es el m?s r?pido para usarlo. Con este fin en mente, si tom?s el tiempo peor de cada c?digo, es posible que un c?digo m?s eficiente que otro reporte un peor resultado por culpa de un proceso externo. Si se toma el tiempo m?nimo el riesgo tambi?n existe, pero es much?simo menor.

Mir?, en la documentaci?n del m?dulo timeit del lenguaje de programaci?n Python (que justamente sirve para calcular la velocidad de distintos c?digos) tambi?n se recomienda tomar en cuenta el menor tiempo, y se explica por qu?: http://docs.python.org/library/timeit.html#timeit.Timer.repeat (fijate en la nota).