Comunidad Game Maker

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.

Cita de: ferhand en Enero 15, 2013, 07:22:17 PM

Cita de: brunoxzx en Enero 15, 2013, 03:06:31 AM
Por cierto puedes hacer que en lugar de añadirse a un mapa se añadan a un array, eso lo haría mas rápido, el problema es que los arrays solo pueden almacenar 32,000 valores.

  Saludos:

  Corrección: Un "array" solo admite hasta 32000 en cada índice, pero el valor total de espacios no puede superar el 1000000 (millón), o sea 1000 por cada uno al unísono.  XD 

Wow leyendo lo que dices me fui al manual y sí el manual dice exactamente lo que tu dices, y estaba por postear aquí pero mientras escribía me dí cuenta de que no entedia muy bien lo del limite del millon así que me puse a experimentar y según los resultados no existe limite de un millon, los únicos limites existentes en gm, aparentemente son que no puede haber mas de 32000 indices por dimensión y tu memoria ram.

Use esté código para ver cuando era que gm me daba un error
[gml]array[31999, 31999]=0;
for(i=0; i<31999; i+=1){
    for(j=0; j<31999; j+=1){
        array[i, j]=$ffffffff;
    }
    screen_redraw();
    draw_text(0, 0, i);
    screen_refresh();
}[/gml]
Para mi sorpresa gm nunca dio error alguno y mientras el contador subía el uso de memoria ram también cuando "i" hiba por el 1300(esto es 1300*32000 indices ya que es un array bidimencional) el array ya había ocupado mas de un gigabyte de ram  :o y gm no me mando ningún mensaje de error lo deje funcionando hasta que me quedaban como 200 megas de ram no fue mucho tiempo ya que no tengo mucha ram.

Aunque esto no me deja clara una cosa, si cada indice es de 32bits esto es 4 bytes y se hacen 32000 indices de j por cada uno de i, esto es 128,000 bytes por cada indice de i, entonces 1000 indices son 128,000 kb que es igual a 128mb y eso no está ni cerca de un gigabyte, quizás no entiendo muy bien esto de los arrays o es que no son 4 bytes por indice, no lo sé quizás alguien aquí tenga la respuesta. Por cierto use gm8 para las pruebas.

Cita de: Kamikaze link=topic=18038.msg85815#msg85815
Perdón, pero solo le solucione el problema que tenia con el método que el publico con esta manera "temporal", ya que si mal no recuerdo tenia un problema a la hora de usar "Include Files".

Saludos!

Perdón por qué?. Tu diste una opción y yo otra y yo simplemente dije que no recomendaba tu opción ya que me fue muy tediosa cuando la use.

En fin de todos modos creo que se fue por tu opción ya que los included files no están funcionando correctamente. Saludos.

Cita de: Wadk en Enero 14, 2013, 09:01:44 PM

Cita de: Ciberman en Enero 14, 2013, 08:18:24 PM
sabía que el Game_id se guardaba en alguna parte del savegame pero no sabía dónde... pero... lo más interesante que puedo extraer de este script es la linea de:
[gml]
value += file_bin_read_byte(f) * power(256, i);
[/gml]
Osea, no se me hubiera ocurrido que poniendole power a la i y sumandolo se podía convertir a decimal el valor... jaja... muy util...

Claro :P. Es porque esencialmente se lee en base 256. Si se leyera en binario (base 2), sería power(2, i), octal (base 8) sería power(8, i)... en fin, que es un cambio de base común y corriente.

Y como casi todo lo que es potencia de dos en las computadoras puede ser usado a nivel de bits.

256<<(i-1<<3);

El código anterior da el mismo resultado que usando power excepto en la potencia 0 que da un numero enorme. aunque no seria muy útil en el script de wadk tal vez para ciertos bucles enormes podría llegar a ser útil.

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.

Pues esté seria el script para añadir todos los archivos dentro de una carpeta a una mapa.
[gml]
//Id del mapa
file=ds_map_create();
//Variable que almacena el numero de archivos
files = 0;
//Array para almacenar las direcciones de todas las carpetas.
folder[0]="";
//directorio inicial.
directory=get_directory('')+"\";
//Variable que almacena el numero de carpetas
folders=0;
//Carpeta actual, en la que se están revisando los archivos.
aFolder=0;
//variable que almacena el nombre del archivo actualmente revizado.
a=file_find_first(directory+'\'+folder[aFolder]+'\*', fa_directory);

ds_map_add(file, a, 0);
while (true) {
    files += 1;
    ds_map_add(file, a, 0);
    if directory_exists(directory+'\'+folder[aFolder]+'\'+a+'\'){
        files-=1;
        //Existen dos directorios invicibles para el explorador estos son "." y ".." indican la ruta de carpetas anteriores.
        //ya que estas carpetas son inecesarias no las añadimos.
        if ( a!="." && a!=".." ){
            folders+=1;
            folder[folders]=folder[aFolder]+'\'+a;
        }
    }
    //Busca el siguiente archivo
    a=file_find_next();
    if ( a=="" ){
        if ( folders==aFolder ) break;
        aFolder+=1;
        a=file_find_first(directory+'\'+folder[aFolder]+'\*', fa_directory);
    }
}
[/gml]
Como dato curioso el script tarda 16,000ms en buscar 11,000 archivos pero si eliminamos la linea en la que se añade cada archivo al mapa se tarda 700ms, eso solo demuestra lo increíblemente lento es crear nuevos elementos en estructuras de datos en gm.

Por cierto puedes hacer que en lugar de añadirse a un mapa se añadan a un array, eso lo haría mas rápido, el problema es que los arrays solo pueden almacenar 32,000 valores.

P.D: con esto se podría hacer un buscador con todos los archivos previamente indexados y con un buen algoritmo de búsqueda basada en un diccionario podría hacerse un script que encuentre un archivo en menos de un segundo parecido a Evertything.

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.

Pero puedes hacerlo tal como lo dijo calio simplemente así.
[gml]
var a;
with(obj){
     other.a=array[0];
}[/gml]

Pues no hay mucho que decir hace un año hice un juego de zombies que llevaba bastantes superficies y sí, a la hora de probar en otras PCs  me dio bastantes problemas, aveces las superficies aparecían con un montón de rayas y lineas y colores raros pero resulto ser problema de que no limpiaba la superficie al crearla, también llegue a tener el problema de que las superficies no funcionaban por el tamaño o por que se tenia que liberar la memoria de vídeo, para eso simplemente cree un mensaje que salia cuando la superficie no funcionaba correctamente que aconsejaba cambiar de resolución de pantalla (que aveces lo reparaba) y te daba la opción de desactivar la superficie mas grande.

Por cierto los errores de superficies también dependen de la versión de gm, 8.1 y studio son los únicos que de verdad usan la tarjeta de vídeo para manejaras.

Yo también creo que mi versión favorita es la 8 desde que salio no la he soltado, el 8.1 lo use durante un tiempo pero inicialmente era algo inestable en sus versiones finales parece bastante bueno pero excepto para proyectos en 3d no veo razón para usarlo.

Por otra parte sobre lo que Fenris comenta no estoy del todo de acuerdo, si bien gm:studio tiene bastantes bugs, la mayoría son resueltos rápidamente, sobre lo del servicio técnico nunca lo he necesitado pero me pasado por pagina de bugs y los foros de yoyo y los mismos desarrolladores contestan a preguntas. Cosa que no es tan común.

Sobre lo de las superficies son una gran utilidad y no me parece que no se deban de usar en juegos comerciales abecés existen efectos que solo se pueden lograr con una superficie. Si bien las superficies son algo inestables los problemas mas grandes que me han dado es que el equipo no acepte superficies mayores a los 1024 pixeles y he probado en varios equipos la mayoría muy viejos algunos con 256 mb de ram y tarjeta integrada y no me dan muchos problemas y si de algún modo una computadora no corriera juegos con superficies o diera errores siempre puede añadirse una opción en el menú para desactivarlas.

Ya lo probé y tienes razón no se puede modificar ni el nombre ni el archivo. No hay mucho que hacer en estos casos simplemente esperar a que lo resuelvan.

Por cierto la pagina de la que hablas de bugs.yoyogames.com y si alguien ya publico el bug allí no deberían tardar mucho en repararlo.

Cita de: francordoba en Enero 14, 2013, 12:33:10 AM
Alguien a comprobado la estabilidad y sincronización del programa a la hora de incluir archivos por medio del  árbol en la pestaña INCLUDED FILES?

Mi caso es que intenté añadir unos .txt. Pero si los modificaba manualmente desde el propio directorio, Gamemaker no detectaba esos cambios. Pero después empezaba a darme errores y a no encontrar el archivo cuando antes, si que lo ha detectado.

¿Alguna idea o sólo me pasa a mí?

Pues el bug que señalas es solo al cambiar el nombre a los archivos desde la interface, si ese es tu caso simplemente no cambies el nombre de ese modo. Por cierto cuando dices que lo modificabas manualmente desde el propio directorio te refieres al archivo dentro de la carpeta de tu .gmx cierto?.

La verdad no te recomiendo el método que te menciona kamikaze.
Hace unos meses lo usaba pero era muy incomodo tener que poner los archivos en la carpeta temporal cada vez que reiniciaba el gm:studio. Lo que te recomiendo yo es añadirlos a los "included files", en el árbol de recursos están justo debajo de los rooms, solo le das click derecho y le pones en "create included file" y allí seleccionas el archivo y en que plataformas lo necesitas. después para abrirlo solo haces esto:

[gml]file_text_open_read("Ingles.txt");[/gml]
nota: Aunque pongas el archivo en un grupo o carpeta dentro de los included files cuando lo quieras abrir no tienes que poner la carpeta en la que se encuentra dentro de la ruta.

Otra ventaja de este método es que no tienes que preocuparte por poner la carpeta en todas las plataformas a donde lo exportas, una desventaja es que gm al exportar el ejecutable los mete dentro del archivo que se llama "data.win" y no los puedes ver, aunque puedes usar esto solo como algo para pruebas y al momento de crear tu ejecutable haces lo que dice kamikaze.

Cita de: Creador de juegos GM en Enero 13, 2013, 05:20:47 PM

Cita de: Kamikaze en Enero 13, 2013, 02:49:23 AM

Cita de: Creador de juegos GM en Enero 12, 2013, 05:16:44 PM

Cita de: WeGame en Enero 12, 2013, 04:30:04 PM
Muchas gracias por vuestras respuestas. Visto lo visto me quedaré con mi GM 8 Pro hasta que me compre el GM:S :)

te invito a unirte a mi grupo de desrrollo. buscamos alguien que nos de el game maker pro (en la licensia dice
que se puede instalar hasta en tres pc)
quieres unirte?
mandame mp

no buscabamos la licencia entera (digo buscabamos por banano29 y yo)
simplemente buscamos que nos de el programa(las tres pc!!!!!!!!!!!!)
y si se puede hacer simultaneo(segun lo que me diguieron)

Jajaja, perdón pero me causó risa el "buscamos alguien que nos de el game maker pro", yo creo que nadie va a dar su licencia que uno pagó, tendrías que comprar la tuya, seria lo logico :D y con respecto a lo de las 3 Pc creo que se refiere que podes activar tu licencia en 3 Pc diferentes pero no darle uso simultaneo... la verdad en este momento no me acuerdo.

No se si te digan algo si les das uso simultaneo, pero en teoría son 3 computadoras de quien compro la licencia.

Pongo lo que edite de mi otro mensaje:
Doble edit: Yaaa. El problema es que no pusiste que estabas usando gm:studio, por algo está lo de poner el icono en el tema.

Pues lo que sucede es que el gm:studio está sandboxed lo que significa que no puedes abrir archivos fuera de la carpeta temporal que se crea en datos de programa, la opcion mas simple es añadir tus dos archivos de idiomas a los "include_files" del gm.