Comunidad Game Maker

Bueno, venía a postear el ejemplo pero ya Guacusio se me adelantó. Buen trabajo, Guacusio.

Cita de: kostra en Octubre 28, 2015, 01:44:17 AM
tiene que haber un límite sí o sí, si le apetece ponerlo bien grande ok, lo que demorará más al juego, pero sin limite, simplemente... PUM! xD

Yo no digo que no tenga que haber un límite, pero hay diferencia entre usar un límite FIJO y un límite DINÁMICO. Ya estoy terminando un ejemplo para mostrar lo del límite dinámico

Es lo mismo que NiuWeb quiere evitar: usar un número fijo para determinar la cantidad de iteraciones. Por ejemplo, con el código que puse antes:
[gml]
for(i=0; i<50; i+=1)
{
     if asset_get_index("captura" + string(i) )  > -1
          contador++
}
[/gml]
Hace lo mismo que el while, partiendo de la suposición de que no habría una cantidad de capturas mayor a 50. Sin contar con que por ejemplo, si se guardan 10 capturas, y se usa 50 como límite, se harían 40 iteraciones de más.

No conozco una función nativa de GML que cuente cuántos archivos (sprites) hay en una carpeta. No digo que no la haya, pero yo nunca la he visto.

SI no la hubiera, creo que lo mejor sería que lleves un conteo de cuántas capturas se crean, y almacenes esa variable en un ini,  y la uses para limitar el ciclo for cuando sea necesario, ya que en la carpeta de escritura de GMS nunca habrá más imágenes que las que indique esa variable. Si el jugador borra imágenes por fuera del juego, es su problema, o crea tu mismo un sistema que permita borrar las capturas desde el juego y modifica el valor de el contador cuando se borre una captura.


EDITADO:
Leyendo el manual, quizás se podrían usar las funciones file_find_first() y file_find_next() para contar el número de imágenes en la carpeta.

Cita de: NiuWeb en Octubre 27, 2015, 10:02:25 PM
Porque el juego se cerrará en algún momento. ¿Y si el jugador elimina las imágenes de forma remota(es decir, del directorio del juego)?. Lo de menos sería crear un .ini con la variable límite, pero como dije antes: No es exacto. Dado caso que el .ini se borre. El conteo se descuadra y devolverá datos que no son. Básicamente, el programa debe saber cuántos archivos/imágenes hay en el directorio sin leer ninguna variable. Sólo contar...

Eso imaginé.
[gml]
for(i=0; i<x; i+=1)
{
     if asset_get_index("captura" + string(i) )  > -1
          contador++

}
[/gml]

Bueno, es posible hacerlo, pero, una pregunta. ¿Por qué no usar directamente la variable límite del ciclo? Se supone que no sería necesario contar las imágenes ya que habría x capturas hechas, de acuerdo a tu código.

Así:
[gml]
for(i=0; i<32; i+=1)
{
   suma += data
}
[/gml]

Cita de: venus en Octubre 27, 2015, 07:29:43 PM
Creo que podría averiguar en que dirección se encuentra el objeto con phy_rotation

No serviría. phy_rotation funciona de manera similar a image_angle, pero en objetos con física. En la imagen de ejemplo el objeto rojo puede tener una rotación de 0, y eso no significa que haya aplicar una fuerza o mejor dicho, un impulso (local) en un ángulo igual a 0. phy_rotation sirve para establecer un ángulo de GIRO a una instancia, no para determinar la dirección de una instancia respecto de otra.

Para saber en qué dirección se encuentra un objeto se puede usar la función de toda la vida: point_direction() pero esto no sería estrictamente necesario estando en un entorno de física (leer más abajo)

Cita de: venus en Octubre 27, 2015, 07:29:43 PM
en el caso en el que sepa en que dirección se encuentra el punto donde tengo que aplicar la fuerza, ¿Como le saco las coordenadas?

Para esto habría varios métodos, todos con cierto grado de "truculencia" debido a que el objeto es irregular. Se me ocurren  varios, pero esto tampoco es necesario ya que el propio motor Box2D incluye variables para saber la dirección de empuje/impulso entre dos instancias que colisionan. Más información:
http://docs.yoyogames.com/source/dadiospice/002_reference/physics/physics%20variables/phy_col_normal_x.html
http://docs.yoyogames.com/source/dadiospice/002_reference/physics/physics%20variables/phy_col_normal_y.html

¿Ya instalaste los drivers USB correspondientes a tu dispositivo?

Tienes que crear una manera de guardar el estado de cada instancia árbol. Y sí, si tienes 500 árboles, tienes que guardar 500 "estados". El estado se puede guardar en un arreglo, estructuras como listas, grids o mapas, o en un ini/txt.

Por ejemplo, en un arreglo bidimensional GLOBAL de nombre status, cada fila correspondería a un registro para una instancia de un árbol
[gml]
i = 0
with(obj_arbol)
{
    status[i, 0] = x         // Guardar coordenada x
    status[i, 1] = y         // Guardar coordenada y
    status[i, 2] = image_index  //o en su defecto una variable que indique en qué etapa de crecimiento está el árbol
    i++
    numero_arboles++         // Llevar la cuenta de cuántos árboles hay
}
[/gml]
Este arreglo se llenaría justo antes de salir de la habitación con árboles. Luego, en un evento evento room start se crearían los árboles y se leería el arreglo para recuperar su estado último. (Tanto el llenado del arreglo como la lectura, se efectuarían desde un objeto persistente)
[gml]
var arbol = noone;
i = 0
if (numero_arboles > 0) and (room = room_arboles)
for (i=0; i < numero_arboles; i++)
{
     arbol = instance_create(blah blah blah)
     arbol.x = status[i, 0]
     arbol.y = status[i, 1]
     arbol.image_index = status[i, 2]
}
[/gml]

Como es de suponer, el tiempo que se esté en otra habitación, se debe calcular cuánto va creciendo cada árbol y sumar/actualizar el grado de crecimiento en el arreglo, para que una vez que se regrese a la habitación con árboles, el crecimiento se refleje en cada árbol. Si quieres ser más preciso y manejar una linea de tiempo distinta para cada árbol, entonces adicionalmente se debería guardar un valor de tiempo en el arreglo (para cada instancia del árbol) y considerar este tiempo en la fórmula de crecimiento que manejes.

¿Qué valor de tiempo guardar? Eso depende del programador, por ejemplo, pueden usarse las funciones de fecha y hora de GML para guardar el momento en que una instancia árbol se creó. Una manera más sencilla sería llevar un contador de pasos que indique cuántos pasos han transcurrido desde que una instancia árbol se creó.

Sé que usar un arreglo no es la solución más elegante, pero el código sólo es para ejemplificar una idea base

¿En qué plataforma? Se me hace raro que un movimiento simple produzca lag, a menos que se aun juego muy pesado. ¿Hay baja de fps cuando esos objetos aparecen en la habitación? Nada se quita con probar, pero si los fps no bajan a algo menor a la velocidad de la habitación, yo no usaría delta_time.

Aquí hay un ejemplo de uso de lengthdir:
http://www.comunidadgm.org/preguntas-y-respuestas/colgarse-de-liana/msg115305/#msg115305

Generalmente se usan para colocar/actualizar la posición de un objeto que gira alrededor de un punto. Por ejemplo, una torreta o cañon que gira sobre un pivote. Al disparar, tienes que hacer que la bala se cree en la punta del cañón, y si este gira en distintas direcciones, tienes que cálcular en qué punto de la habitación se encuentra la punta, y para eso se pueden usar las funciones lengthdir

Aquí hay un tutorial http://gmc.yoyogames.com/index.php?showtopic=556480 según el cual:
Algo así:
[gml]
delta = 60/1000000*delta_time
[/gml]
60 es la velocidad base a la que quieres que el juego se mantenga. La variable delta es algo así como un "factor de compensación" por el cual multiplicarías tus variables de movimiento, por ejemplo la velocidad, para que el objeto se moviera más rápido si el juego baja de fps o más lento si el juego sube de fps. De acuerdo a ese tutorial, antes hay que ajustar a velocidad de la habitación a un valor muy alto (en ese ejemplo 9999).

Otra manera sería usándolo como se muestra en el manual:
http://docs.yoyogames.com/source/dadiospice/002_reference/date%20and%20time/delta_time.html

Yo he leído varias discusiones y algunos opinan a favor de usar delta_time mientras que otros opinan en contra y prefieren usar frame skipping. Hay cosas para las que no es conveniente usar delta_time, por ejemplo, alarmas. Yo en lo personal prefiero tratar de optimizar el código.

Cita de: NiuWeb en Octubre 23, 2015, 11:29:19 PM
entonces, si pongo en el ini_write_real y en ini_read_real:

[gml]ini_write_real("data","data"+string(i),global.data);[/gml]

Ahora serviría?

Sí, pero en lugar del segundo "data" sería "variable", ¿no? (de acuerdo con los ejemplos anteriores)

Cita de: NiuWeb en Octubre 23, 2015, 11:04:44 PM
Entonces, ¿Podría guardarlos en un ini así?:

[gml]
ini_open("ini.ini")
for(i=0;i<10;i+=1)
{
   ini_write_real("data","variable",global.data);
}
ini_close();[/gml]

No. El ciclo se ejecuta 10 veces, pero las 10 veces se está guardando (sobreescribiendo 9 veces) un valor distinto en la misma clave "variable". Al final tendrás un solo elemento guardado en el arreglo, en lugar de 10.

De estp se deduce que debes encontrar una manera de, al a vez que se cambia de valor dentro del ciclo, cambiar (dinámicamente) la clave en donde se guardará el valor. Para esto sirve la función string() (los nombres de las secciones y claves en un archivo ini son cadenas, strings). En el foro ya hay ejemplos de esto, es cuestión de usar el buscador o quizás no, ya que es una solución fácil.