Comunidad Game Maker

Verán, necesito conocer trucos para hacer que el exceso de objetos en pantalla no ralentice el juego.
Ya conozco lo de desactivar las instancias que no aparezcan en pantalla, pero eso no evita que el juego se me ralentice, sobre todo al avanzar varios rooms. ???
¿Que me puede estar pasando?

Que resolucion gastas?, es para movil o para windows o etc...

La pantalla tiene talla 800x600.
Lo curioso es que al principio no da mucho problema, pero al avanzar varios rooms si que empiezan las ralentizaciones.

si tienes archivos muy pesados es mejor guardarlos en carpetas y llamarlos con codigos.
si tienes muchos sonidos, aunque no pesen mucho, es mejor no cargarlos al inicio.

si no te funciona con cambios como lo que menciono anteriormente, ya te toca revisar el codigo de las instancias a ver si hay algo que lo ralentice

Cita de: jefferson940 en Abril 13, 2015, 09:24:55 PM
si tienes archivos muy pesados es mejor guardarlos en carpetas y llamarlos con códigos.
si tienes muchos sonidos, aunque no pesen mucho, es mejor no cargarlos al inicio.

si no te funciona con cambios como lo que menciono anteriormente, ya te toca revisar el código de las instancias a ver si hay algo que lo ralentice

¿Y como hago esas cosas que dices? ???

Además de todo ello, debes destruir los objetos que no esten en pantalla, y no abusar de los eventos draw, utilizar los objetops parent, etc...

Aqui tienes más info: http://gmc.yoyogames.com/index.php?showtopic=512603

saludos

Destruyo los objetos que se salen de la pantalla y uso todo lo posible los objetos parent.
Pero con los draw si que se me va la mano, lo cual me lleva una cuestión: ¿Que tipo de animación de muerte resulta poco costoso?
En mi juego (un mata-marcianos) al morir los personajes empiezan a perder su alfa al mismo tiempo que por toda la caja del sprite salen "explosiones" creadas con el evento draw (que debe ser eso lo que ralentiza). Originalmente usaba un efecto de desintegración, pero hacia que el juego fuese exageradamente lento.

La mejor forma de saber qué es lo que está afectando el rendimiento es correr el juego en modo de depuración y hacer un "Profile", ahí puedes ver qué parte es la que gasta más tiempo; por lo general es el evento Draw de alguna instancia.

Algo que a veces ralentiza es el uso de la "application surface", usa la función application_surface_enable para desactivarla.

Sólo hay que notar que el deshabilitar la application surface inhabilita la opción "Keep aspect ratio" de las opciones globales.

La opción profile del debugger es una de razones por las que decidí portar mi juego de GM8 a GMS, ayuda mucho a identificar problemas de rendimiento.

Por ahora, me encuentro que no puedo usar "deshabilitar superficie" porque lo necesito para el efecto de pausa del juego.
Pero al revisar el código me encontré con un bug de la pausa que la hacia funcionar de forma errorea, la cual ya he corregido.
No esta todo arreglado, pero vamos avanzando. ¿A alguien se le ocurre algo más?
¡Todavía espero consejo para las animaciones de muerte, que es lo que más me ralentiza!

Bueno se me ocurre que al momento de pasar a otro nivel utilices room_instance_clear() en medio del paréntesis pon la room de atrás para que el juego por así decirlo no  guarde el cache de la otra room y asi vaya mas rápido.

Hablando de cache, puede ser que en tu juego se acumulen varias páginas de textura en la memoria de gráficos. Lo primero sería ordenar los gráficos para que se usen la menor cantidad de páginas de textura por nivel y después llamar a la función draw_texture_flush() al inicio de cada nivel.

Si las explosiones se dibujan sólo con draw_sprite, no debería haber problemas de rendimiento. Si quieres muestra el código para analizarlo.

Aquí hay otros "trucos": http://help.yoyogames.com/entries/27617403

Cita de: quiero aprender en Abril 17, 2015, 05:43:40 AM
Bueno se me ocurre que al momento de pasar a otro nivel utilices room_instance_clear() en medio del paréntesis pon la room de atrás para que el juego por así decirlo no  guarde el cache de la otra room y asi vaya mas rápido.

Así he hecho y ya va un poco mejor ;), aunque me resulta algo extraño esto, pues se supone que son rooms no persistentes, no debería memorizarse nada sobre ellas al terminar cada fase. ???

Paso el código que uso en el objeto del enemigo destruido. Solo existe este código, ubicando obviamente en draw:

draw_self()

for(a=bbox_left a<=bbox_right a++) // Coge sin más los extremos del sprite.
for(b=bbox_top b<=bbox_bottom b++)
if(!irandom(300-image_alpha*200))
draw_circle_color(a,b,8,c_purple,c_white,false)
image_alpha-=0.01
if(image_alpha==0) instance_destroy()

Bien, el rendimiento del código depende mucho del tamaño de la máscara de colisión.
    Hice un "profile" y lo que consume más tiempo es la ejecución de irandom, eso es por la cantidad de iteraciones que se hacen con los ciclos for. Por ejemplo una instancia con una máscara de colisión de 32x32 hace 1024 repeticiones del ciclo en cada evento Draw y en todos esas repeticiones la función irandom tiene una probabilidad que va de 1% a 0.3% de dibujar un círculo, por lo que como mucho se dibujan 10 círculos en cada Step (en algunos casos si se dibujan más). Se debe programar un ciclo que haga menos repeticiones.
    Otra cosa que se puede optimizar es usar draw_sprite en vez de draw_circle, por lo general los sprites se dibujan más rápido que las primitivas.

He optimizado el código de esta forma
[gml]
draw_self();

repeat( 5 )
draw_sprite( sp1,0,
irandom_range( bbox_left, bbox_right ),
irandom_range( bbox_top, bbox_bottom ) );

image_alpha -= 0.01;
if(image_alpha==0) instance_destroy();
[/gml]
Se ejecuta 33 veces más rápido y la diferencia con el anterior es imperceptible.