Saludos makeros:
Se que esta pregunta debe ser una sencillez solucionarla, pero no logro verla por mi mismo. :-[
Cuando utilizo la función: variable_global_array2_get() solo tengo que colocar el nombre de la variable como una cadena de caracteres. Como la variable es global puedo acceder a sus datos desde cualquier objeto.
Pero en el caso de la función: "variable_local_array2_get(name,ind1,ind2)" ¿Si quiero acceder a la variable cómo indico el objeto donde se encuentra la variable? Al ser local la variable no tengo forma de acceder a ella desde otros objetos.
No se que hacer... :'(
Necesitas ejecutar la función en el otro objeto.
Supongamos que tienes el siguiente array en un objeto llamado obj_test:
my_array[0,0] = 1;
my_array[0,1] = 2;
my_array[1,0] = 3;
my_array[1,1] = 4;
my_array[2,0] = 5;
my_array[2,1] = 6;
Vamos a usar el siguiente código para dibujar el valor de my_array[2,1] en otro objeto:
with (obj_test){ draw_text(0,0,variable_local_array2_get("my_array",2,1)); }
Y el resultado debiese ser que el objeto dibuja el número 6 en la esquina de la room. :)
Por algún motivo que no logro entender, el siguiente código también funciona
var bleh;
with (obj_test){bleh = variable_local_array2_get("my_array",2,1); }
draw_text(0,0,bleh);
Si alguien sabe exactamente por qué la variable local bleh funciona dentro del with, que me avise porque no lo termino de entender yo :p
Espero que haya resuelto tu duda :)
Saludos makero calio:
Muchas gracias por contestar tan rápido. :D
Entiendo que utilizas la estructura "with", pero dentro del código de la estructura no estamos en el objeto desde donde se realiza la llamada, sino en el objeto donde está la variable "my_array". ¿No habrá una forma de acceder a los valores de dicha variable sin "salirse" del objeto que realiza la llamada?
Por cierto, es normal que la variable "bleh" creada antes del "with" tome los valores de "my_array". La variable "bleh" está en el código "padre" que contiene al segmento del codigo del "with", o sea un segemento de código abarca al otro. ;D
Pero puedes hacerlo tal como lo dijo calio simplemente así.
[gml]
var a;
with(obj){
other.a=array[0];
}[/gml]
Cita de: ferhand en Enero 14, 2013, 11:46:38 PM
Entiendo que utilizas la estructura "with", pero dentro del código de la estructura no estamos en el objeto desde donde se realiza la llamada, sino en el objeto donde está la variable "my_array". ¿No habrá una forma de acceder a los valores de dicha variable sin "salirse" del objeto que realiza la llamada?
No se exactamente si existirá alguna forma, pero dentro de la función no creo que haya alguna forma de hacerlo a menos que sea ejecutando el código
en la instancia que contiene la variable, dentro de la instancia que necesita obtener el dato.
Una pregunta, ¿por qué estás ocupando esa función? ¿Es porque defines dentro del juego una variable en cierta instancia que no todas las instancias del mismo objeto poseen, y necesitas una forma de corroborar que ésta exista en la instancia que estás chequeando para evitar un error? Si es así, creo que se me ocurren un par de formas creativas para solucionar el problema :D
Cita de: ferhand en Enero 14, 2013, 11:46:38 PM
Por cierto, es normal que la variable "bleh" creada antes del "with" tome los valores de "my_array". La variable "bleh" está en el código "padre" que contiene al segmento del codigo del "with", o sea un segemento de código abarca al otro. ;D
Eso tiene sentido :p aunque sigo sin entender del todo por qué código que se ejecuta en otro objeto es capaz de escribir en una variable local del código padre sin hacer referencia explícita a éste.
Si tuviese una variable llamada "bleh" en el objeto emparentado, ¿Cual de las dos variables escribiría?
Cita de: brunoxzx en Enero 15, 2013, 12:15:32 AM
Pero puedes hacerlo tal como lo dijo calio simplemente así.
[gml]
var a;
with(obj){
other.a=array[0];
}[/gml]
Si no me equivoco, other sólo devuelve un valor en eventos de colisión.
Cita de: calio en Enero 15, 2013, 01:32:40 AM
Si no me equivoco, other sólo devuelve un valor en eventos de colisión.
Pues aunque el manual no lo diga funciona. Aunque no se si pueda llamar a una variable temporal desde otro objeto, pero creo que si.
Por cierto lo que dice ferhand es correcto estas declarando la variable en un objeto fuera del with y usándola en otro objeto dentro del with.
[gml]var a;
with(obj){
other.a=variable_local_array2_get("array", 1, 2);
}[/gml]
y creo que este es el script que debí usar hace rato.
Bueh, sabía que me podía equivocar xD pasa que he tenido un par de complicaciones utilizando other fuera de un evento de colisión, y cuando leí en el manual que sólo devolvía el id del otro objeto en esos eventos supuse que era por eso :p
Cita de: brunoxzx en Enero 15, 2013, 02:14:33 AM
[gml]var a;
with(obj){
other.a=variable_local_array2_get("array", 1, 2);
}[/gml]
y éste código -tomando en cuenta que other sí funciona- parece la versión más limpia :D
...y para evitar hacer más posts, te voy a explicar una manera ingeniosa de chequear qué instancias tienen o no definidas qué variables sin que provoque error :D esto me salvó una par de veces cuando tuve que dejar de ocupar ésta función y su hermana _set.
Lo primero es crear una lista.
global.defined_ids = ds_list_create();
y en cada vez que tengas que definir éstas variables que sólo algunas instancias poseen, escribes lo siguiente al final del código:
ds_list_add(global.defined_ids,id);
añadiendo la id del objeto en cuestión a la lista.
Ahora, cada vez que tengas que hacer la comprobación (léase donde llamas a la función variable_local_array2_get()), en lugar de chequear si la variable existe o no, sencillamente compruebas lo siguiente:
if (ds_list_find_index(global.defined_ids,id_de_la_instancia_en_cuestion) > 0)
{
...
}
Así compruebas que el objeto tiene la variable en cuestión :)
Ahora, si tus rooms no son persistentes, necesitas limpiar esa lista cada vez que la room acabe. En el evento Room End vas y pones:
ds_list_clear(global.defined_ids);
Y listo :D
Ahora, si lo que necesitas realmente es leer y escribir en variables pasadas como string por un motivo u otro, mi solución propuesta es crear un map que nos va a ayudar a mantener éstas variables ubicables por su nombre como string. ¿Cómo lo hacemos? pues así:
Primero creamos el map en cada objeto
vars = ds_map_create();
Y ahora creemos algunos scripts para escribir y leer "variables" dentro de este map.
var_set(id,name,val);
var id, name, val;
id = argument0;
name = argument1;
val = argument2;
if (ds_map_exists((id).vars,name) == true)
{
ds_map_replace((id).vars,name,val);
}
else
{
ds_map_add((id).vars,name,val);
}
var_get(id,name);
var id, name;
id = argument0;
name = argument1;
if (ds_map_exists((id).vars,name) == true)
{
return (ds_map_find_value((id).vars,name));
}
else
{
return 0; //éste valor lo puedes cambiar por el valor que tu quieras considerar como nulo
}
donde id es la id de la instancia, name el nombre de la variable y val su valor.
Se que no viene al caso en absoluto, pero más vale prevenir xD
Jaja yo también las deje de usar por lentas y por que no funcionan en gm:studio.
Por cierto a mi no se me había ocurrido solución para saber si existe una variable así que me las tuve que idear para no usarlas en ningún script ni juego.
La solución ideal para todo lo de las variables dinámicas son los mapas ya que a estos se puede acceder por un string, y de hecho hay algo increíble, en ciertos casos acceder una llave en un mapa es mas rápido que a una variable nativamente en gm, esto según leí de Mike Dailly se debe a que dolphi no accede a las variables usando un diccionario sino que tiene que ir una por una hasta llegar a la requerida lo cual hace que en programas con cientos de variables accedan lentamente a las ultimas creadas.
Saludos makeros brunoxzx y calio:
¡Muchas gracias por contestar! :D
En el diseño que estoy tratando prescindo bastante de la estructura objeto nativa de GM, por lo que no tendré muchos objetos con variables distribuidas entre ellos. Simplemente me pareció mejor crear las variables de tipo "local" en lugar de "global". No estoy seguro de las implicaciones, simplemente creí mejor la otra forma, pero no podía acceder a los arreglos locales entre los distintos objetos.
Por supuesto que no se me ocurrió la utilización de la estructura "with". :-[
Ya anteriormente tenía una lista de todas las variables creadas dinámicamente, solo que al acceder a ellas utilizando dicha función en su forma local no funcionaba y quería saber qué pasaba.
¿Creen que para no tener que utilizar la partícula "with" sea mejor crear las variables globales? ¿Ocupan más espacio las globales que las locales? ???
¿Tendré que crear otro tema en el foro? XD :-[ XD :-[ XD
perdón por meter mi cuchara, en esta charla de "adultos" XD
En mi travesías por aprender GML, recuerdo una recomendación que se repite bastante, tanto que la tengo muy presente, y esta más o menos dice así: "procura usar variables locales siempre que puedas, evita usar variables globales". Luego se menciona que las variables globales no se destruyen al finalizar la ejecución del script y las locales sí.
A mi, la verdad, me parece una recomendación de poco valor, tomando en cuenta el hardware que se maneja hoy en día.
Citar¿Creen que para no tener que utilizar la partícula "with" sea mejor crear las variables globales? ¿Ocupan más espacio las globales que las locales?
Creo que no hay diferencia en cuanto al tamaño de local y global. Hasta donde sé, a diferencia de los lenguajes 'mayores', GML maneja únicamente dos tipos de datos,
string y
real. Ahora, lo que determina el tamaño de una variable, no es el valor que almacena, sino su tipo de datos. Como todas las variables (globalesy locales) son REAL en GM, todas ocuparán el mismo espacio en RAM.
Si no mal recuerdo, en este caso, todas las variables de GM, ocuparían 8bytes en memoria. Para utilizar un Kilobyte de memoria, necesitarías tener 128 variables (un sprite , el que sea, ocupa más que esto). Para ocupar 1
mísero Megabyte de RAM con variables, necesitarías un juego con 131072 variables. Reto a un valiente a que haga un juego con 130000 variables distintas
Después del cálculo anterior, no no le veo sentido a eso de usar variables locales y evitar las globales. Para mi, bienvenidas sean las variables globales. Quizás hace 20 años me hubiera preocupado por no gastarme un megabyte de ram, pero no ahora. ;D
Saludos makero penumbra:
Cita de: penumbra en Enero 15, 2013, 08:31:12 PM
perdón por meter mi cuchara, en esta charla de "adultos" XD
No te preocupes, todos tenemos lo mismo en común: GM, eso nos hace iguales. XD XD XD
Cita de: penumbra en Enero 15, 2013, 08:31:12 PM
Creo que no hay diferencia en cuanto al tamaño de local y global. Hasta donde sé, a diferencia de los lenguajes 'mayores', GML maneja únicamente dos tipos de datos, string y real. Ahora, lo que determina el tamaño de una variable, no es el valor que almacena, sino su tipo de datos. Como todas las variables (globalesy locales) son REAL en GM, todas ocuparán el mismo espacio en RAM.
Si no mal recuerdo, en este caso, todas las variables de GM, ocuparían 8bytes en memoria. Para utilizar un Kilobyte de memoria, necesitarías tener 128 variables (un sprite , el que sea, ocupa más que esto). Para ocupar 1 mísero Megabyte de RAM con variables, necesitarías un juego con 131072 variables. Reto a un valiente a que haga un juego con 130000 variables distintas
Después del cálculo anterior, no no le veo sentido a eso de usar variables locales y evitar las globales. Para mi, bienvenidas sean las variables globales. Quizás hace 20 años me hubiera preocupado por no gastarme un megabyte de ram, pero no ahora. ;D
Si las variables fueran números puede que sí tengan el mismo tamaño en "Ram", pero en cuanto a los "string" no lo creo. Un "string" es una cadena de caracteres, o sea un "array" de caracteres. Cada caracter pesa, creo que 1 Byte, en dependencia del tipo de codificación. Lo que indica que un "array" de tres caracteres ocupa más espacio que otro de cuatro. XD
¡Si influye la cantidad! XD XD XD
Sería interesante saber si un número entero de más de una cifra ocupa un Byte o más. A mi en lo particular me parece que ocupa un byte por cifra... ???
Cita de: penumbra en Enero 15, 2013, 08:31:12 PM
perdón por meter mi cuchara, en esta charla de "adultos" XD
En mi travesías por aprender GML, recuerdo una recomendación que se repite bastante, tanto que la tengo muy presente, y esta más o menos dice así: "procura usar variables locales siempre que puedas, evita usar variables globales". Luego se menciona que las variables globales no se destruyen al finalizar la ejecución del script y las locales sí.
A mi, la verdad, me parece una recomendación de poco valor, tomando en cuenta el hardware que se maneja hoy en día.
Citar¿Creen que para no tener que utilizar la partícula "with" sea mejor crear las variables globales? ¿Ocupan más espacio las globales que las locales?
Creo que no hay diferencia en cuanto al tamaño de local y global. Hasta donde sé, a diferencia de los lenguajes 'mayores', GML maneja únicamente dos tipos de datos, string y real. Ahora, lo que determina el tamaño de una variable, no es el valor que almacena, sino su tipo de datos. Como todas las variables (globalesy locales) son REAL en GM, todas ocuparán el mismo espacio en RAM.
Si no mal recuerdo, en este caso, todas las variables de GM, ocuparían 8bytes en memoria. Para utilizar un Kilobyte de memoria, necesitarías tener 128 variables (un sprite , el que sea, ocupa más que esto). Para ocupar 1 mísero Megabyte de RAM con variables, necesitarías un juego con 131072 variables. Reto a un valiente a que haga un juego con 130000 variables distintas
Después del cálculo anterior, no no le veo sentido a eso de usar variables locales y evitar las globales. Para mi, bienvenidas sean las variables globales. Quizás hace 20 años me hubiera preocupado por no gastarme un megabyte de ram, pero no ahora. ;D
Ejem. justo estaba hablando de esto en otro tema xD. es cierto lo que dices., todas las variables independientemente del numero que esté dentro de ellas ocupan el mismo numero de bytes aunque no se si sean 8 bytes por variable ¿de donde sacaste ese dato?.
Y bueno tal vez ningún programador pueda llegar a 131072 variables que mensionas pero con estructuras de datos o arrays no es nada del otro mundo, una imagen en la ram se puede llevar varios megas.
Cita de: ferhand en Enero 15, 2013, 10:57:52 PM
Saludos makero penumbra:
Cita de: penumbra en Enero 15, 2013, 08:31:12 PM
perdón por meter mi cuchara, en esta charla de "adultos" XD
Si las variables fueran números puede que sí tengan el mismo tamaño en "Ram", pero en cuanto a los "string" no lo creo. Un "string" es una cadena de caracteres, o sea un "array" de caracteres. Cada caracter pesa, creo que 1 Byte, en dependencia del tipo de codificación. Lo que indica que un "array" de tres caracteres ocupa más espacio que otro de cuatro. XD
¡Si influye la cantidad! XD XD XD
Sería interesante saber si un número entero de más de una cifra ocupa un Byte o más. A mi en lo particular me parece que ocupa un byte por cifra... ???
Sobre los strings creo que tienes razón.
Sobre lo de un byte por cifra como ya dijo penumbra en gm todas las variables "reales" ocupan el mismo numero de bytes.
Y bueno respondiendo a tu pregunta las globales y locales ocupan lo mismo como ya te respondieron, el único consejo que yo te daría es el dejar de usar las variable_get y set estás son lentas y no funcionaran en ningún gm siguiente y tampoco en ningún lenguaje de programación compilado, aunque bueno si no vas a cambiar de gm no veo mucho problema.
Citarpero en cuanto a los "string" no lo creo. Un "string" es una cadena de caracteres, o sea un "array" de caracteres.
Cierto, me falto hacer énfasis. Al referirme a global y local, estaba hablando sólamente de variables numéricas, no de cadenas. Claro que un array o las estructuras de datos en general pueden ocupar más RAM que una variable numérica sencilla, pero aun así, creo que aunque tu manera de programar sea la más desorganizada, no podrías "hacerle cosquillas" a la RAM en base a variables numéricas simples o incluso estructuras de datos (a menos que a propósito escribas código para generar datos basura con el único propósito de comerte toda la RAM). Otra cosa son los objetos, instancias, fondos, srpites, archivos de sonido, partículas, etc. Ahí sí hay que medirse.
Citar
todas las variables independientemente del numero que esté dentro de ellas ocupan el mismo numero de bytes aunque no se si sean 8 bytes por variable ¿de donde sacaste ese dato?.
http://www.maartenbaert.be/game-maker-dlls/http-dll-2/buffers/ (http://www.maartenbaert.be/game-maker-dlls/http-dll-2/buffers/)
"Game Maker uses doubles (float64) to store numbers,"
Type
Size (bytes) Lowest value Highest value Resolution Other names
float64
8 -8.9885e307 8.9885e307 ~16 significant figures double
Cita de: penumbra en Enero 16, 2013, 02:25:41 AM
http://www.maartenbaert.be/game-maker-dlls/http-dll-2/buffers/ (http://www.maartenbaert.be/game-maker-dlls/http-dll-2/buffers/)
"Game Maker uses doubles (float64) to store numbers,"
Type Size (bytes) Lowest value Highest value Resolution Other names
float64 8 -8.9885e307 8.9885e307 ~16 significant figures double
Jaja gracias la verdad no lo sabía :).
Bueno, en vista que ya puedo acceder a las variables locales creadas de forma dinámica mediante la la función "variable_local_array2_get" doy por solucionado el tema. :)
Aún así si alguien encuentra una manera de hacer sin que medie la estructura "with" será escuchado atentamente. XD
¡Gracias a todos! ;D