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 (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. (http://emoticonhq.com/images/ICQ/thumbsup.jpg)
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 (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.
Vale, ahora al fin no se me ralentiza el juego si destruyo un enemigo gigante. ;D
Por cierto, jefferson940 menciono sobre "almacenar en carpetas" gráficos y música.
¿A que se refería y como lo hago? Recuerdo que en C y en Java puedes tener sprites y canciones en ficheros separados de la aplicación y luego los convocabas buscándolos entre las carpetas y cargándolos en la memoria del juego. ¿Es eso posible en Game Maker?
Cita de: Marth en Abril 19, 2015, 06:19:04 PM
Por cierto, jefferson940 menciono sobre "almacenar en carpetas" gráficos y música.
¿A que se refería y como lo hago?
Eso no es recomendable en GMS (para gráficos), a menos que quieras terminar con un juego en donde cada sprite y gráfico, por más pequeño que sea, ocupará una página de textura él solo, lo cual es un desperdicio enorme de espacio y es horrible desde el punto de vista de la optimización.
Para el audio, meparece recordar que desde hace unos meses en YoYo quitaron el soporte para cargar audio desde un archivo (creo que la función la habían marcado como deprecated, aunque no estoy seguro). Quizás necesites recurrir a una extensión o dll para poder cargar audio de manera externa.
Normalmente se usan páginas de gráficos para almacenar todo junto, sin desperdiciar el espacio. Es como en los sprite sheets, que van todos juntos. Para los tiles y gráficos en general igual, se deben poner lo más juntos posible para ahorrar espacio. Otra forma de optimizar memoria, es crear páginas de texturas personalizadas. Por ejemplo si tienes un fondo de 1024x1024 no lo guardes en una página normal, sinó en un grupo de texturas personalizado de ese tamaño. Los sprite sheets, si ocupan 256 pues lo mismo. Lo máximo que permite creo que son 2048x2048. Si pones un fondo más largo de ese tamaño, GMS hará un scale-down (x2) y se verá mal.
saludos
El más grande tiene talla 1000*608, por lo que no es ningún problema el fondo del escenario, shaq145.
Cita de: shaq145 en Abril 20, 2015, 10:52:32 AM
Normalmente se usan páginas de gráficos para almacenar todo junto, sin desperdiciar el espacio. Es como en los sprite sheets, que van todos juntos.
Cuando se agregan gráficos desde una carpeta, No. Todo lo contrario.
De este post:
http://gmc.yoyogames.com/index.php?showtopic=569121 (http://gmc.yoyogames.com/index.php?showtopic=569121)
CitarWith GM:S it is really not advisable to use external files for graphics... When you add a sprite from an external resource, you are basically creating an extra texture page for use, and this requires an extra texture swap. So if you load 50 sprites, you are adding in an extra 50 texture swaps and texture pages to your game! This is VERY inefficient..
"Con GM:S, realmente no es recomendable usar ARCHIVOS EXTERNOS para gráficos... Cuando agregas un sprite desde UN RECURSO EXTERNO, básicamente estás creando una página de textura extra, y esto requiere un intercambio de textura extra. De modo que si cargas 50 sprites (EXTERNAMENTE), estás agregando un extra de 50 páginas de textura al juego. Esto es
MUY ineficiente"
Así que
cargar sprites desde una carpeta definitivamente no es una buena idea cuando se quiere optmizar un juego.