Mostrar Mensajes

Esta sección te permite ver todos los mensajes escritos por este usuario. Ten en cuenta que sólo puedes ver los mensajes escritos en zonas a las que tienes acceso en este momento.

Mensajes - Clamud

1321
Puedes hacer eso con un arreglo 2D de tamaño 50x5, aunque escribir uno a uno los elementos del arreglo en un archivo ini me parece demasiado, optaría por usar una "grid" (también de 50x5) en vez de un arreglo para guardar toda la tabla en una sola línea del archivo ini. Pensándolo mejor se debería ser de tamaño 50x6; las primeras 5 filas serían para el estado de los objetos y la sexta para el total de objetos encontrados en cada nivel.

El procedimiento sería algo así:

Primero se crea la tabla
[gml]global.tabla = ds_grid_create( 50, 6 );[/gml]
al principio todos los valores dentro de la tabla son cero. En seguida se carga la tabla desde el ini con la función ds_grid_read. Busca la función en el manual, ahí aparece un ejemplo.

Después al entrar a un nivel (room), en el evento Room Start o Create, los objetos revisan si han sido encontrados, entonces se destruyen
[gml]///obj_1
if global.tabla[# global.level-1, 0 ] instance_destroy();[/gml]
[gml]///obj_2
if global.tabla[# global.level-1, 1 ] instance_destroy();[/gml]
se pone global.level-1 porque los niveles se empiezan a contar desde 1 pero en la tabla se cuenta desde 0.

Al encontrar un objeto se deben ejecutar algunas de estas líneas de código
[gml]//ob_1
global.tabla[# global.level-1, 0 ] = true;
global.tabla[# global.level-1, 5 ] += 1;
instance_destroy();[/gml]
[gml]//ob_2
global.tabla[# global.level-1, 1 ] = true;
global.tabla[# global.level-1, 5 ] += 1;
instance_destroy();[/gml]

Para guardar los cambios se debe usar la función ds_grid_write. En el manual también hay un ejemplo.

En la room de selección de niveles los números se escribirían con un ciclo for
[gml]
for( i=0; i<50; i++ )
{
    draw_text( x,y+i*k, "Level "+string(i+1)+": "+string(global.tabla[#i,5])+"/5" );
}
[/gml]
1322
Bien, el rendimiento del código depende mucho del tamaño de la máscara de colisión.
    Hice un "profile" y lo que consume más tiempo es la ejecución de irandom, eso es por la cantidad de iteraciones que se hacen con los ciclos for. Por ejemplo una instancia con una máscara de colisión de 32x32 hace 1024 repeticiones del ciclo en cada evento Draw y en todos esas repeticiones la función irandom tiene una probabilidad que va de 1% a 0.3% de dibujar un círculo, por lo que como mucho se dibujan 10 círculos en cada Step (en algunos casos si se dibujan más). Se debe programar un ciclo que haga menos repeticiones.
    Otra cosa que se puede optimizar es usar draw_sprite en vez de draw_circle, por lo general los sprites se dibujan más rápido que las primitivas.

He optimizado el código de esta forma
[gml]
draw_self();

repeat( 5 )
draw_sprite( sp1,0,
irandom_range( bbox_left, bbox_right ),
irandom_range( bbox_top, bbox_bottom ) );

image_alpha -= 0.01;
if(image_alpha==0) instance_destroy();
[/gml]
Se ejecuta 33 veces más rápido y la diferencia con el anterior es imperceptible.
1323
Lee el tutorial 08_Levels_And_Saving que está dentro de la sección 00 - GM Basics
https://imagizer.imageshack.us/v2/858x597q90/845/99v8f.jpg
1324
Preguntas y respuestas / Re:Salto como super mario
Abril 18, 2015, 06:55:45 PM
Puedes agregar esta línea de código
[gml]
if( keyboard_check_released(vk_up) and vsp<0 ) vsp /= 2;
[/gml]
1325
Cita de: desplo en Abril 18, 2015, 05:17:10 AM
la resolucion en android le tengo la mas alta (2048x2048).
¿Te refieres al tamaño de la página de textura?
1326
Preguntas y respuestas / Re:problema con sprites
Abril 18, 2015, 04:10:09 PM
Para escalar las imágenes en GIMP sin difuminar los pixeles abre el menú Imagen, elige Escalar imagen, introduce un valor que sea múltiplo del tamaño actual y en Interpolación selecciona Ninguna.

He leido un método para mantener el efecto pixelart pero no lo he intentado. Se trata de dibujar en una surface pequeña (puede ser la "application surface"), usando una vista también pequeña, todo a escala 1:1. Por último se dibuja esa surface estirada al tamaño de la ventana. No estoy seguro de la calidad del resultado pero debe ser mejor que usar una vista con tamaño pequeño y port grande.
1327
Lo primero que necesitas es una rapidez angular para indicar qué tan rápido debe ajustarse a los cambios de ángulo
[gml]ra = 5; //rapidez angular[/gml]
Después se necesita saber la diferencia entre el ángulo actual y el ángulo final, pero esa diferencia debe estar en el intervalo (-180,180] para no hacer giros más largos de lo necesario. Ese valor se obtiene así
[gml]
pd = point_direction( mouse_x,mouse_y, obj_player.x,obj_player.y )
da = angle_difference( image_angle, pd  ); //diferencia de ángulo
[/gml]
Ahora conociendo el signo de la diferencia de ángulos sabemos si se debe restar o sumar la rapidez ángular, pero se debe hacer sólo cuando la diferencia de ángulo es un intervalo más pequeño que la rapidez angular
[gml]
if( da < -ra ) //caso negativo
    image_angle -= ra;
else image_angle -= da;
if( da > ra ) //caso positivo
    image_angle += ra;
else image_angle += da;
[/gml]

En el manual, en la descripción de la función angle_difference, aparece el mismo algoritmo pero reducido
[gml]
var pd = point_direction(x, y, mouse_x, mouse_y);
var dd = angle_difference(image_angle, pd);
image_angle += min(abs(dd), 10) * sign(dd);
[/gml]
ahí el número 10 es la rapidez angular.
1328
Si quieres probar el juego desde :GMS:, con los comandos Run (triángulos verde y rojo), abre :GMS: ve al menú Help -> Open GameMaker in Explorer y copia los archivos a esa carpeta.

Si quieres compilar el juego, en "tipo" elige "Windows NSIS Installer" ó "Compressed Applications zip", te recomiendo el segundo. Después instala o descomprime el juego y copia los archivos en donde se encuentre el ejecutable del juego. Me acabo de dar cuenta que si tienes los archivos del emulador en la carpeta de instalación de :GMS: se agregan automáticamente al archivo zip.

Sólo son necesarios los archivos xinput1_3.dll y x360ce.ini, si quieres puedes copiar el archivo x360ce.exe para configurar el mando fácilmente.
1329
Hablando de cache, puede ser que en tu juego se acumulen varias páginas de textura en la memoria de gráficos. Lo primero sería ordenar los gráficos para que se usen la menor cantidad de páginas de textura por nivel y después llamar a la función draw_texture_flush() al inicio de cada nivel.

Si las explosiones se dibujan sólo con draw_sprite, no debería haber problemas de rendimiento. Si quieres muestra el código para analizarlo.

Aquí hay otros "trucos": http://help.yoyogames.com/entries/27617403
1330
La mejor forma de saber qué es lo que está afectando el rendimiento es correr el juego en modo de depuración y hacer un "Profile", ahí puedes ver qué parte es la que gasta más tiempo; por lo general es el evento Draw de alguna instancia.

Algo que a veces ralentiza es el uso de la "application surface", usa la función application_surface_enable para desactivarla.
1331
Preguntas y respuestas / Re:Step Avoid
Abril 14, 2015, 09:38:08 PM
La función equivalente es mp_potential_step, tiene los mismos argumentos que Step Avoid.

Acabo de recordar que estás haciendo un juego que se ralentiza, tener muchas instancias que usan la acción Step Avoid puede ser la causa de la ralentización. Si, en tu juego, los obstáculos y el punto meta no cambian constantemente, tal vez sea mejor usar la función mp_potential_path y ejecutarla sólo al inicio del juego o dentro de una alarma.
1332
Pues ya tienes las condiciones para hacer que se mueva, que son las mismas condiciones para incrementar el contador. El código puede quedar así:
[gml]
... {x+=32; contador++;}
... {x-=32; contador++;}
... {y+=32; contador++;}
... {y-=32; contador++;}
[/gml]
1334
Si el objeto padre tiene código (o acciones) en un evento y el objeto hijo tiene código en el mismo evento sólo se ejecuta el código del objeto hijo, a menos que se escriba la función event_inherited(). De esa forma se puede ejecutar el código del padre y además ejecutar el código específico del hijo.