Buenas! Estoy en GM Studio, y no tengo claro el tema eficiencia. Tenía pensado usar sprites 120x120, pero ahora surge la necesidad de subir a 150x150. Habrá MUCHOS personajes y enemigos, y cada uno tendrá muchas animaciones con, seguramente, muchos frames, sobretodo el prota, y dudo que pueda ir muy lento con la subida a 150x150. Recuerdo que en GM8 podías... guardar los sprites en una carpeta a parte, cargarlos por código y borrarlos cuando no fueran necesarios, pero ahora, con el tema de que GM studio crea un exe para instalar.. no sé si es automático, se puede hacer o no... así que
1- El tema este de peso-ralentización por tener demasiados sprites, sigue en GM studio? Cómo? Debo preocuparme por el peso de mis recursos, o ahora que hay un instalador es automático y te lo guarda fuera en carpetas?
2- Debo preocuparme por subir de 120x120 a 150x150 (pensando que habra MUUUUUUCHOS sprites) o es sufrir innecesariamente, pues sigue siendo un tamaño pequeño?
Por la manera en que GMS trabaja, cargar sprites de manera externa no se me hace una opción recomendada a la hora de hablar de optimización, por este motivo:
http://www.comunidadgm.org/preguntas-y-respuestas/trucos-para-optimizar-la-velocidad-del-juego-(solucionado)/msg113700/#msg113700
Sobre lo otro, que si el cambio afectará el rendimiento. Eso es fácil de saberlo. Utiliza el profiler del depurador de GMS, y ahí podrás saber si la diferencia de tamaño sumado al número de sprites impacta el desempeñodel juego o no lo hace.
https://www.yoyogames.com/tech_blog/56
Si tienes la versión Pro de GMS y tu juego utiliza el CPU de manera intensiva, probablemente sea conveniente compilar el juego con el YoYo compiler. Recientemente probé un proyecto mque realizaba muchos cálculos matemáticos, y la velocidad bajaba hasta 22 fps, luego al compilar con el YYC, subió a más de 60 fps. El cambio de rendimiento se notará mas a medida de que el juego sea más demandante. EN proyectos pequeños el cambio será mínimo.
Dios! Eso no lo hacía GM8, cierto? Cargar sprites externamente siempre fue la máxima eficiencia!...
Entonces, carga externa descartada. ¿Eso también pasa con los sonidos y músicas? ¿Es mejor cargarlas en el propio juego y NO externamente? La música siempre la hice externa en GM8...
No tengo pro, así que el yoyo compiler queda descartado. Tampoco creo que use el cpu extensivamente, no será 3D tampoco.
No he entendido del todo lo del depurador, pero viendo que no tengo ninguna forma de aumentar la eficiencia, realmente daría igual... sería ir a 150x150 y esperar que todo vaya bien, objetivamente no es taaaanto tamaño. Programando eficientemente en todos los sentidos (desactivo lo que está fuera de la view, etc), el tamaño de los recursos afecta a la eficiencia, o sólo hace más pesado el archivo?
Cita de: DarkKRuleR en Agosto 01, 2015, 08:37:27 PM
Entonces, carga externa descartada. ¿Eso también pasa con los sonidos y músicas? ¿Es mejor cargarlas en el propio juego y NO externamente? La música siempre la hice externa en GM8...
SI no recuerdo mal, YA NO SE PUEDE cargar audio externamente en GMS, porque eliminaron esa función XD
La única manera de cargar audio externo sería usando una dll para manejar el audio, pero yo prefiero usar el sistema de audio de GMS, que para mi tiene características interesantes, además de que incluye la opción de usar grupos de audio, entonces puedes controlar que conjunto de sonidos se cargan en la memoria y también te permite liberar audio de la memoria, para mi esto es mejor que cargar audio externamente.
Determinar el grado de impacto a priori por pasar de 120px a 150px sería especular. Yo insisto en que uses el profiler y ahí se sabrá exactamente que pasa, porque ningún proyecto es igual a otro, la sola diferencia entre el número de subimágenes para las animaciones puede provocar diferencias imprtantes de un proyecto a otro. La diferencia suena pequeña, no creo el cambio en el rendimiento vaya a ser dramático, quizás afecte más el número de objetos activos en una habitación. No olvidar la organización de los sprites en las paginas de texturas (grupos de texturas) si se quiere optimizar el proceso de dibujo en pantalla.
Muchas gracias. Ahora tengo varias dudas, pero lo estoy viendo todo más claro...
1- Añadir los sprites, backgrounds y sonidos al propio proyecto es lo más eficiente y no debo hacer nada más, cierto? Aunque le echaré un ojo a eso de usar grupos de audio, suena interesantemente eficiente
2- Has nombrado el organizar los sprites en las páginas de texturas. Ahora mismo tenía pensado tener, por ejemplo, un sprite para la animación de caminar, y dentro tener 10 subimágenes, una por frame. Sería mucho más conveniente tener un sprite con UNA única subimagen, en ella tener los 10 sprites, y hacer un draw_sprite_part para dibujar una sola parte? Tenía eso en mente pero lo quité porque era más complicado, pero si gano mucho en eficiencia lo añadiré de nuevo. En ese caso, *el que un sprite pueda tener más de una subimagen* sería una opción que nunca usaría, si hago un sprite por cada animación, y que sólo tenga UNA subimagen con todos los frames. NO HARÉ un sprite para todo, sino uno por animación, o saldría enorme. Sólo ahora saldría con una altura de 750, y un ancho de 150x(numeroDeFrames)...
3- Aún si la diferencia afecta... tengo claro que en una misma pantalla (view) no habrá más de... 5 personajes a la vez. Clarísimo, realmente, según cómo serán mis escenarios, cuyas rooms serán pequeñas incluso. Si me dices que el tamaño total de los sprites no afecta tanto a la eficiencia, sinó el cómo los uses, yo lo doy por bueno.
Sí, cargar los recursos de la manera tradicional es por ahora lo "menos ineficiente". Cargar gráficos externamente no digo que no se pueda, pero para proyectos grandes con muchos sprites y fondos no se me hace "sano".
Sobre lo que quieres hacer con draw_sprite_part(). Yo no he hecho pruebas al respecto, pero hasta donde alcanzo a ver, no le veo mucho caso, es decir, yo no lo haría (a menos que alguien me convenciera con datos duros de que sí hay beneficio). Me explico:
Cuando agregas tu sprite animado de 10 subimágenes a GMS, al compilar el proyecto GMS crea las páginas de textura, y lo que hace GMS es que esas 10 subimágenes las acomoda en la página de textura como si fuera una tira o sprite_sheet, es decir, GMS ya hace automáticamente lo que quieres hacer, descomponer el sprite en subimágenes y acomodarlas juntas. Al final en una página de texturas, todo son sprites o "frames sencillos" apilados, y eso es lo que usa GMS para dibujar. Esto lo hace GMS automáticamente y sería esencialmente lo mismo que quieres hacer, pero acomodar manualmente cada frame de cada animación y juntar varias animaciones y cuidar que el tamaño de toda la hoja encaje en el tamaño de la página de textura es un trabajo enorme que al final no tiene caso (creo yo, si es que estoy en lo correcto)
Igual se puede probar (de nuevo, con el profiler)a ver si el dibujo es más rápido usando draw_sprite_part() que el método normal de dibujo, pero no creo que valga la pena.
Si hay pocos objetos en una vista y lo demás que está fuera queda inactivo, creo que sería poco probable que hubiera problemas de rendimiento. También ten en cuenta que tu PC puede ser más potente que las PCs de otros usuarios, o al revés. Nunca se sabe :-[
NOTA: En la carpeta "Assets cache" (la ruta se configura en las preferencias generales) puedes ver el contenido de las páginas de textura de los proyectos. En mi caso:
nombre_del_proyecto\Default\TextureGroups\2048
yo creo que sigue siendo eficiente
usar los archivos necesarios
que no tengan espacios con canal alfa, mas que lo que sea necesario como sprites de personajes con el fondo invisible
que sean de tamanos de 32x32,64x64, 512x512, etc...
usar archivos PNG ya que tienen mejor calidad que los JPG para juegos
cosas asi
Uh, lo del tamaño sería complicado. No hay ninguna potencia de 2 que me sirva... y antes que tirar a 256, sería mejor quedarse en 150.
Muchas gracias! Así que no es necesario tener todas las subimágenes en una misma textura. Pues visto todo lo planteado, sin duda no habrá problemas. Sé que mi PC será más potente, desde el primer segundo siempre veo todo lo que programo y procuro añadirle opciones más ligeras para pcs lentos. Pues dicho todo esto puedo ir sin preocuparme, quién lo diría que GMS te lo facilita todo... más o menos.
Aunque lo que dice somnus aún me deja pensando, sobre qué tanto mejora que el tamaño sea potencia de 2. En mi caso, teniendo 150x150, buscar una potencia sería irse a 256x256, y quizás no sería eficiente. No entiendo la parte de usar archivos png, yo los añado al editor de imagen de game maker, ahí no hay extensión, él mismo lo hace, ya que no cargaré externamente
Pues creo que tengo bastante info y me lanzaré sin problemas, aunque lo dejaré "sin resolver" por lo que pueda surgir. Gracias a los dos!