Comunidad Game Maker

Citar{
instance_activate_all();
instance_deactivate_region(view_xview[0],view_yview[0],view_wview[0],view_hview[0],false,true);
}

Para no tener que estar revisando instancia por instancia, activa todo, pero para que no gasten recursos, al instante desactiva las que estan fuera, con solo revisar su x e y es suficiente.

Conocía ese trocito de codigo, pero si bien en 2 lineas activas y desactivas instancias, interiormente si igual es un gasto considerable de procesamiento al estar evaluando cada instancia individualmente.

CitarComo ya te dije, me gustaria hacer pruebas sobre esto, ya que para hablar de optimizacion, no estoy de lo mas seguro de mis conocimientos ya que nunca pude hacer pruebas concretas, por eso nunca quise meter en discusion esto.

Claro, se que el tema era otro y salio esto de la optimización, pero es que yo lo agregé por ser una consecuencia positiva de usar el método. es más, es la única justificación posible para usar este método (no te voy a negar que el otro es más cómodo y rápido).

CitarEsta bien, pero como tu dijiste que el proyecto lo entregabas como vos querias, y te queria hacer acordar que no siempre vamos a tener la suerte (o la no suerte, depende de quien sea) de trabajar solo y poder hacer las cosas como nos gusta.

De acuerdo, pero como estaba solo lo quise hacer así. Conozco ambos métodos en caso de hacer equipo.

CitarAdmito que te quedo muy bien, y que me gusta como te las arreglaste para esto, felicitaciones por ese trabajo.
Pero te pusiste a pensar que si quieres hacer alguna modificacion minima en el room, o algo asi vas a tener que cambiar CADA step y CADA funcion?
Seria un total desastre y, ademas de llevarte muchisimo tiempo, quizas ni siquiera quede bien.

Gracias, el esfuerzo valió la pena (obtuve un 85/100 como nota :)).
  Y bueno, Texic ya te respondió lo siguiente. Simplemente le haces un SHIFT a los steps y listo, todo se corre mágicamente. 

  Para terminar, si es más engorroso programar un juego de esta manera, es más, para ejemplos de juegos cortos ni vale la pena hacer ese esfuerzo extra porque lo que ganas es bastante poco. Pero en la universidad me taladraron el cerebro con el tema de dar prioridad a la optimizacion de recursos, y bueno, siempre mi norte es apuntar en ese estilo. Aunque cueste más trabajo.

Modificacion:

CitarAhi modificarias solo los steps y cada vez lo estas dejando menos exacto. Cuando nombre cambios en el room, me referia a por ejemplo, un cambio de tamaño. Deberias crear una variable global de referencia, pero que igualmente vas a tener que ir cambiando todos los argumentos.

No hay cambio de tamaño en este método, la pantalla siempre tiene la misma forma. Todo se basa en los timelines, mientras mas acciones y pasos le des más largo y variado seran los ataques enemigos. Por ejemplo:

1.-Si crees que la primera etapa te quedo muy corta y sencilla, agregas mas enemigos aumentando el timeline.
2.- Si crees que te quedo muy larga, eliges el rango de steps que quieres borrar y listo.
3.- Si crees que en la mitad del recorrido faltan cosas, haces un shift, corres todos los steps el tiempo que quieras (piensa que lo que haces es demorar lo que corres, por lo tanto, tienes espacio para colocar más cosas).

Ahora, lo mismo te pregunto a ti: En tu metodo cuando quieres agregar algo en la mitad debes correr objetos, tiles, etc de manera manual e individualmente, porque GM no tiene selección grupal de objetos. Yo lo considero aun mas engorroso.

Citar

Citar
{
instance_activate_all();
instance_deactivate_region(view_xview[0],view_yview[0],view_wview[0],view_hview[0],false,true);
}

Para no tener que estar revisando instancia por instancia, activa todo, pero para que no gasten recursos, al instante desactiva las que estan fuera, con solo revisar su x e y es suficiente.

Conocía ese trocito de codigo, pero si bien en 2 lineas activas y desactivas instancias, interiormente si igual es un gasto considerable de procesamiento al estar evaluando cada instancia individualmente.

A que le llamas considerable? Porque la verdad que yo jamas tuve problemas de FPS con esto.

Citar

CitarComo ya te dije, me gustaria hacer pruebas sobre esto, ya que para hablar de optimizacion, no estoy de lo mas seguro de mis conocimientos ya que nunca pude hacer pruebas concretas, por eso nunca quise meter en discusion esto.

Claro, se que el tema era otro y salio esto de la optimización, pero es que yo lo agregé por ser una consecuencia positiva de usar el método. es más, es la única justificación posible para usar este método (no te voy a negar que el otro es más cómodo y rápido).

Como dijimos que estamos hablando de un juego shooter, tu dices que tu forma de hacerlo es mucho mas optima que la mia. De verdad se justifica en un juego de estas caracteristicas?
Osea, tu puedes hacer un juego de "la forma tradicional" que baje considerablemente los FPS, y que al pasarlo a tu modo ya no tenga ese problema?
No te lo quiero pedir como prueba, sino que me encantaria ver eso, porque ademas es algo realmente interesante que sucediera.

Citar

CitarEsta bien, pero como tu dijiste que el proyecto lo entregabas como vos querias, y te queria hacer acordar que no siempre vamos a tener la suerte (o la no suerte, depende de quien sea) de trabajar solo y poder hacer las cosas como nos gusta.

De acuerdo, pero como estaba solo lo quise hacer así. Conozco ambos métodos en caso de hacer equipo.

Estando solo nadie te puede decir nada, y es bueno que conozcamos mas metodos, aunque yo siempre prefiero el que menos bugs puede crear, ya que si surje algun problema de optimizacion, quizas se pueda arreglar mas facil que uno de bugs (No llevo ni un año en esto, pero en el transcurso de tiempo lo he usado MUCHISIMO, y muchas veces tuve bugs que los veia irreparables, pero nunca tuve un problema de optimizacion que no pudiera arreglar. Lo que no quiere decir que en un futuro no los tenga, ni que soy un crack arreglando esto, sino que no me surgieron, y que por eso es mi forma de pensar asi).

Citar

CitarAdmito que te quedo muy bien, y que me gusta como te las arreglaste para esto, felicitaciones por ese trabajo.
Pero te pusiste a pensar que si quieres hacer alguna modificacion minima en el room, o algo asi vas a tener que cambiar CADA step y CADA funcion?
Seria un total desastre y, ademas de llevarte muchisimo tiempo, quizas ni siquiera quede bien.

Gracias, el esfuerzo valió la pena (obtuve un 85/100 como nota :)).

Te lo merecias, me gustaron mucho los sprites tambien!
Otra cosa, en tu carrera diste GM? O como fue esto del proyecto? (Si no te importa contar, si es un problema o no te gusta contar, no hay problema xD)

CitarY bueno, Texic ya te respondió lo siguiente. Simplemente le haces un SHIFT a los steps y listo, todo se corre mágicamente. 

Aqui el mismo mal entendido que le explique a él.

CitarPara terminar, si es más engorroso programar un juego de esta manera, es más, para ejemplos de juegos cortos ni vale la pena hacer ese esfuerzo extra porque lo que ganas es bastante poco. Pero en la universidad me taladraron el cerebro con el tema de dar prioridad a la optimizacion de recursos, y bueno, siempre mi norte es apuntar en ese estilo. Aunque cueste más trabajo.

Creo que deberia haber un equilibrio, entre no hacer el Crysis que era muy complicado de levantar con buenos FPS, y hacer una programacion tan complicada que al minimo bug que te salga, no lo puedas arreglar, o ni siquiera puedas trabajar tranquilo.

CitarModificacion:

CitarAhi modificarias solo los steps y cada vez lo estas dejando menos exacto. Cuando nombre cambios en el room, me referia a por ejemplo, un cambio de tamaño. Deberias crear una variable global de referencia, pero que igualmente vas a tener que ir cambiando todos los argumentos.

No hay cambio de tamaño en este método, la pantalla siempre tiene la misma forma. Todo se basa en los timelines, mientras mas acciones y pasos le des más largo y variado seran los ataques enemigos. Por ejemplo:

1.-Si crees que la primera etapa te quedo muy corta y sencilla, agregas mas enemigos aumentando el timeline.
2.- Si crees que te quedo muy larga, eliges el rango de steps que quieres borrar y listo.
3.- Si crees que en la mitad del recorrido faltan cosas, haces un shift, corres todos los steps el tiempo que quieras (piensa que lo que haces es demorar lo que corres, por lo tanto, tienes espacio para colocar más cosas).

Como puedes estar tan seguro que nunca te surgira cambiar el tamaño del room? O cambiar un sprite? O algo asi, juegas demasiado con las cosas numericas, cuando lo mejor, me parece a mi, es usar funciones genericas, para que cualquier cambio no te afecte.

CitarAhora, lo mismo te pregunto a ti: En tu metodo cuando quieres agregar algo en la mitad debes correr objetos, tiles, etc de manera manual e individualmente, porque GM no tiene selección grupal de objetos. Yo lo considero aun mas engorroso.

Si, en eso tambien tienes razon, lleva su debido tiempo armar un room manualmente, ademas que el GM no tiene el mejor editor de niveles que todos. Pero creo que con practica y buena predisposicion, se te hace bastante facil.
Que a la hora de hacer cambios va a ser tedioso, es cierto, pero creo que de eso no hay ninguna forma de esquivarlo.

CitarA que le llamas considerable? Porque la verdad que yo jamas tuve problemas de FPS con esto

Considerable en relacion a la cantidad de información procesada. Si tienes un room  de 1500 de largo, no se nota la sobrecarga, pero vamonos a los extremos. Tu conoces las pruebas de stress? esas que se hacen para probar la optimizacion de CPUs, Sistemas operativos, Rams, Bases de datos, etc? Se basan en llevar al limite lo que se prueba, procesando cantidades gigantes de datos. Créeme, te lo doy por seguro, si tienes 1 room de 150.000 pixeles de largo y 1500 instancias en el cuarto se notará el bajón si o si. 

CitarComo dijimos que estamos hablando de un juego shooter, tu dices que tu forma de hacerlo es mucho mas optima que la mia. De verdad se justifica en un juego de estas caracteristicas?

Posiblemente no, eso ya te lo había dicho. Pero tampoco esta malo, como le dijiste a Sobaco, y ese fue el punto inicial de este debate.

CitarOsea, tu puedes hacer un juego de "la forma tradicional" que baje considerablemente los FPS, y que al pasarlo a tu modo ya no tenga ese problema?
No te lo quiero pedir como prueba, sino que me encantaria ver eso, porque ademas es algo realmente interesante que sucediera.

Suponiendo que estamos hablando de un shooter de naves del estilo del ejemplo que te adjunte, si. Si tienes uno que sea lento enviamelo.

CitarEstando solo nadie te puede decir nada, y es bueno que conozcamos mas metodos, aunque yo siempre prefiero el que menos bugs puede crear, ya que si surje algun problema de optimizacion, quizas se pueda arreglar mas facil que uno de bugs

Estoy de acuerdo. Depende del proyecto y complejidad de este es que decides que método tomas.

CitarOtra cosa, en tu carrera diste GM? O como fue esto del proyecto? (Si no te importa contar, si es un problema o no te gusta contar, no hay problema xD)

Era un curso (no recuerdo el nombre) semestral donde se enseñaba y evaluaba los rpincipios de las conexiones en red. Como trabajo semestral el profe nos pidió (como buenos informaticos jaja) un juego diseñado en cualquier lenguaje que se jugara en red. Hubieron juegos en java, Visual Basic, Python, Flash y como no, aportando por aca con GML :) Fue una muy buena asignatura (Nostalgia Mode ON)

CitarCreo que deberia haber un equilibrio, entre no hacer el Crysis que era muy complicado de levantar con buenos FPS, y hacer una programacion tan complicada que al minimo bug que te salga, no lo puedas arreglar, o ni siquiera puedas trabajar tranquilo.

100% de acuerdo.

CitarComo puedes estar tan seguro que nunca te surgira cambiar el tamaño del room? O cambiar un sprite? O algo asi, juegas demasiado con las cosas numericas, cuando lo mejor, me parece a mi, es usar funciones genericas, para que cualquier cambio no te afecte.

A ver, miralo de esta manera. Ambos metodos tiene casi la misma complejidad cuando se quieren modificar. Ya te di las razones si cambias el room a lo largo, si lo haces a lo alto (height) tendras los mismos problemas mios si lo haces en el tuyo.
Tu mientras tienes que mover manualmente los objetos que quieras reacomodar, yo simplemente cambio las coordenadas en instance_create. De sprites nada, ya que son objetos propios identicos a los que tienes tu.
 
  Como puedo decirte que despues de todo no es tan díficil la creacion y modificacion de este método? Con una respuesta tuya :)

CitarPero creo que con practica y buena predisposicion, se te hace bastante facil.

  Bueno, me voy a dormir. Mañana seguimos :P

jjaja ... nunca un juego de estos será de la rapidez optimizada que ofrece hacerlo en C/C++ o incluso Bmax, y uno de sus grandes problemas no pasa por el tamaño de sus Sprites, sino por la interacción directa que tiene el lenguaje compilado, ASM con el procesador. Y C/C++ es muy superior en optimización.

Lo otro es un problema de recursos, es decir, yo puedo tener 1000 Sprites he imágenes de Todo tipo, y empaquetadas en un, Zip, y al momento de cargar el nivel, voy al archivo y leo y cargo solo los recursos que ocupa ese nivel, dejando un margen de memoria gráfica de un 50% es suficiente, para no agotar el sistema, es bueno que tengan un programa que cuente esta memoria gráfica, libre cuando cargan el juego. Y tambien se da un aviso de Requerimiento gráfico para el XGame 1gb, y asi los usuarios sabrán que menos de eso el juego no correrá.

GameMaker personalmente es bastante bueno, para desarrollar un concepto de juego, se puede optimizar, con codigo, step, y ciertas lineas estrategicas "if(y < view_yview || y > view_hview) deactivate_instance(true)", sin entrar mas en detalles, pero el problema que yo veo de fondo, y no se si tendrá solución, es la persistencia de recursos, osea, si una instancia llama a un objeto que no existe en la room, aparecera un error que dice que la instancia de ese objeto no esta creada, pues bien, lo mismo debiera ser para los Sprites y Background, puesto ya esta creado, no estoy seguro si el Sprite, o Bacground, desaloja esa memoria, cuando acaba la room, y no lo usare en la siguiente Room, y esto si es un problema,,,, porque en C/C++ todo lo que se declara como objeto, no ocupa memoria si no se abre con new, o se desaloja con delete, inclusive las imagenes, osea, no se si me equivoco, yo estaría diciendo, que la memoria usada, es toda la memoria de imagenes declarada, y se agrega toda la memoria usada por los objetos creados en la room,  la suma de ambas, debe ser menor que el total de la memoria de la tarjeta gráfica, sino colapsa, !!!

Hay alguna manera de que toda la memoria declarada en las imágenes, no sea memoria usada para el Game?,, creo que no !!!

 Por lo mismo esbxp, GML no es tan rapido como C++ u otro lenguaje más avanzado, por lo que con un  poco se puede saturar un pc. De ahi la importancia de la optimización.

Citarpues bien, lo mismo debiera ser para los Sprites y Background, puesto ya esta creado, no estoy seguro si el Sprite, o Bacground, desaloja esa memoria, cuando acaba la room, y no lo usare en la siguiente Room, y esto si es un problema

No lo hace, pero existen las funciones sprite_delete y background_delete para liberar la memoria ocupada por estos :)

Citar

CitarA que le llamas considerable? Porque la verdad que yo jamas tuve problemas de FPS con esto

Considerable en relacion a la cantidad de información procesada. Si tienes un room  de 1500 de largo, no se nota la sobrecarga, pero vamonos a los extremos. Tu conoces las pruebas de stress? esas que se hacen para probar la optimizacion de CPUs, Sistemas operativos, Rams, Bases de datos, etc? Se basan en llevar al limite lo que se prueba, procesando cantidades gigantes de datos. Créeme, te lo doy por seguro, si tienes 1 room de 150.000 pixeles de largo y 1500 instancias en el cuarto se notará el bajón si o si. 

Una cosa es que sea logico, no veo la necesidad de tener un room de 150.000 pixeles, ni mucho menos 1500 instancias (En un juego asi)

Citar

CitarComo dijimos que estamos hablando de un juego shooter, tu dices que tu forma de hacerlo es mucho mas optima que la mia. De verdad se justifica en un juego de estas caracteristicas?

Posiblemente no, eso ya te lo había dicho. Pero tampoco esta malo, como le dijiste a Sobaco, y ese fue el punto inicial de este debate.

Si no se justifica usar un metodo que atrae mas bugs, mayor necesidad de prueba y error en vez de logica, y cosas asi, yo lo veo como que esta mal (Como ya dije, no tan amplio, sino que seria una de las peores ideas para usar)

Citar

CitarOsea, tu puedes hacer un juego de "la forma tradicional" que baje considerablemente los FPS, y que al pasarlo a tu modo ya no tenga ese problema?
No te lo quiero pedir como prueba, sino que me encantaria ver eso, porque ademas es algo realmente interesante que sucediera.

Suponiendo que estamos hablando de un shooter de naves del estilo del ejemplo que te adjunte, si. Si tienes uno que sea lento enviamelo.

En las oportunidades que tuve de programar un juego asi, nunca se me bajo ni un FPS, por eso te estoy preguntando.
Mi pregunta es que sin cambiar absolutamente nada, solo como se crean las instancias.

Citar

CitarComo puedes estar tan seguro que nunca te surgira cambiar el tamaño del room? O cambiar un sprite? O algo asi, juegas demasiado con las cosas numericas, cuando lo mejor, me parece a mi, es usar funciones genericas, para que cualquier cambio no te afecte.

A ver, miralo de esta manera. Ambos metodos tiene casi la misma complejidad cuando se quieren modificar. Ya te di las razones si cambias el room a lo largo, si lo haces a lo alto (height) tendras los mismos problemas mios si lo haces en el tuyo.
Tu mientras tienes que mover manualmente los objetos que quieras reacomodar, yo simplemente cambio las coordenadas en instance_create. De sprites nada, ya que son objetos propios identicos a los que tienes tu.

Para mi no es lo mismo poder poner la instancia donde yo quiera, estar viendola en tiempo real y poder modificarla a mi gusto. Que tener que ir poniendolo por steps, que hastaque no corra el juego y llegue hasta ese lugar, no se como van a quedar.
 

CitarComo puedo decirte que despues de todo no es tan díficil la creacion y modificacion de este método? Con una respuesta tuya :)

CitarPero creo que con practica y buena predisposicion, se te hace bastante facil.

Yo no me referia a eso xD
Igualmente creo que nunca lo usaria, creo que no se justifica usar este metodo, tampoco me gusta para hacer distintas cosas en el juego en si.
Pero cada cual con lo suyo.

La habilidad de un programador se refleja en su capacidad de optimizar el código sin cambiar el funcionamiento del mismo. Quizás fue exagerado lo de un room de 150000 pixeles, pero cuál método sirve para el caso y cuál no? Quién sabe, quizás algún día se te de por hacer un shooter extensos como lo son juegos estilo RaidenII y ahí se va a sentir la diferencia de optimización. Igual a lo que apuntamos con FrogGer no es a cambiar tu manera de hacer los shooters sino a cambiar la manera de pensar al programar, la optimización es muy importante, y si nunca la haces, ni para juegos chiquitos, nunca mejorás la técnica. Hace poco vino alguien a preguntar sobre cómo optimizar un código en el que se usaba draw_background_tiled. Si te fijás es sólo una función, pero es totalmente inefectiva ya que la velocidad depende del largo y ancho del room (como el caso de tu shooter). Obviamente nadie te obliga a cambiar la manera de programar, pero estamos acá para repartir nuestros conociemientos y experiencias con los demás. Por mi parte te recomiendo empezar a optimizar todo código que hagas así va a llegar el día que hagas que el crysis corra en un AMD K6... Bueno, tampoco para tanto, pero por ahí viene la mano xD

Cita de: Texic en Junio 14, 2012, 11:42:07 PM
La habilidad de un programador se refleja en su capacidad de optimizar el código sin cambiar el funcionamiento del mismo. Quizás fue exagerado lo de un room de 150000 pixeles, pero cuál método sirve para el caso y cuál no? Quién sabe, quizás algún día se te de por hacer un shooter extensos como lo son juegos estilo RaidenII y ahí se va a sentir la diferencia de optimización. Igual a lo que apuntamos con FrogGer no es a cambiar tu manera de hacer los shooters sino a cambiar la manera de pensar al programar, la optimización es muy importante, y si nunca la haces, ni para juegos chiquitos, nunca mejorás la técnica. Hace poco vino alguien a preguntar sobre cómo optimizar un código en el que se usaba draw_background_tiled. Si te fijás es sólo una función, pero es totalmente inefectiva ya que la velocidad depende del largo y ancho del room (como el caso de tu shooter). Obviamente nadie te obliga a cambiar la manera de programar, pero estamos acá para repartir nuestros conociemientos y experiencias con los demás. Por mi parte te recomiendo empezar a optimizar todo código que hagas así va a llegar el día que hagas que el crysis corra en un AMD K6... Bueno, tampoco para tanto, pero por ahí viene la mano xD

No creo que mi manera de programar sea tan poco optima, sino alguna vez lo hubiera notado.
Siempre busco la manera mas "rapida" para el sistema de hacer las cosas, y hasta ahora me ha ido bien.
Sera porque mi nivel de optimizacion me alcanza para lo que estoy creando, quizas algun dia necesite mas, o quizas este por el buen camino de la optimizacion.
Cuando tenga algun problema con esto, seguramente van a estar ahi, reprochandome todo eso xD Broma, pero van a estar ahi para ayudarme, como siempre, seguramente ^^