Comunidad Game Maker

El parámetro "angle" funciona perfectamente para lo que quieres hacer, pero para que rote gradualmente, tienes que colocar una variable y NO un valor numérico. El valor de la variable se aumenta poco a poco en step o en draw.

por ejemplo:

CREATE
[gml]angulo = 0[/gml]

STEP
[gml]angulo += 1[/gml]

En "Transform Sprite", en "angle" introduces la variable angulo

Suponiendo que el objeto sólido que PUDIERA haber entre jugador y enemigo se llamara obj_bloque:

[gml]
if ( (x - obj_jugador.x) < 0 ) and ( abs(y - obj_jugador.y) < 50 )
{
     var cl;
     cl = collision_line(x, y, obj_jugador.x, obj_jugador.y, obj_bloque, false, true)
     if (cl == noone)
     {
            //accion a realizar
     }
}
[/gml]

El código sólo funcionará cuando el enemigo esté a la izquierda del jugador, no a la derecha. Tampoco funcionará si enemigo y jugador están muy lejos en la coordenada y, es decir, la acción sólo se ejecuta si están más o menos emparejados en la coordenada y. Ten en cuenta que el código va en step, por lo que si la condición es verdadera, lo más probable es que la acción a realizar (por ejemplo un disparo), se va a ejecutar MUCHAS veces seguidas.

Así que debes adaptar el código (agregarle cosas o modificarlo) para que la acción sólo ocurra una vez cada, luego haya un tiempo de reposo, y luego se pueda volver a ejecutar.

EDITADO: Hice una corrección en la condición del if interior, porque la primera que puse estaba mal

Este código
if (!surface_exists(surface128)) surface128 = surface_create(128, 128);
    surface_set_target(surface128);
    draw_clear_alpha(c_white, 0);
¿corresponde a scrIniciaCambioTextura();?

y este otro
surface_reset_target();
return surface_get_texture(surface128);
¿corresponde a scrAsignaCambioTextura?

Si se dibuja siempre la misma subimagen, lo más probable es que el error esté en el código que dibuja esas subimágenes, pero no veo que hayas colocado ese código en los ejemplos de arriba.

Es porque la velocidad es mucha para el grosor (ancho) de las paredes. En un STEP la pelota está a punto de tocar la pared, pero al otro STEP, la pelota avanza 30 pixeles y si la pared es menos ancha que eso, pues nunca se produjo una colisión.  Cuando la velocidad es alta, sería necesario cambiar la máscara de colisión de las paredes a una mas ancha para que pueda detectarse la colisión.

http://docs.yoyogames.com/source/dadiospice/002_reference/objects%20and%20instances/instances/instance%20properties/mask_index.html

O diseñar el juego con física. Supongo que la detección de colisiones y cálculos son más precisos y podría evitarse este problema de que se traspasan, incluso se puede marcar la pelota como bala, para que los cálculos sean todavía más precisos a velocidades altas.

Creo que no da error porque la función permite agregar múltiples elementos (hasta 15) a la lista en una sola llamada, cosa que no he intentado.

El ejemplo de Wadk se refiere a colas de prioridad list = ds_priority_create();

Que no es lo mismo que list = ds_list_create();

Esto:
ds_list_add(list, 0, obj_sol)

Debería ser
[gml]ds_list_add(list, obj_sol);[/gml]

No creo que la optimización que puedas hacer en cuanto a páginas de textura tenga relación con el problema (pero si meequivoco, hacérmelo notar). El efecto de un juego con páginas de textura optimizadas es que el proceso de dibujo en pantalla se hace sin contratiempos, pero el problema que mencionas no tiene nada que ver con el dibujo ni con las páginas de textura, ni siquiera me parece que sea un problema de rendimiento (me imagino que el juego, una vez cargado, corre sin lag, a menos que sea un dispositivo con características muy bajas, pienso yo).

Más bien lo veo como un problema propio del motor de Game Maker. Creo que todos o casi todos los juegos comerciales de las grandes compañías no cargan el total de recursos al inicio, sino que es una carga inteligente en donde se va cargando a medida que el propio juego lo requiere. Desconozco cómo carga recursos GM, pero me inclino a pensar que carga todo al principio. No lo puedo asegurar y a lo mejor me equivoco, pero si es como pienso, me parece una barbaridad. Ojalá alguien con más experiencia pueda aclarar esto.

Usar recursos externos es posible en Android, para eso están los Included Files, además del APK, se pueden usar los archivos de extensión con lo que se pueden crear juegos (para android) incluso de varios GIGABYTES.

La única solución que se me ocurre (ojalá haya otras) es precisamente recurrir a archivos externos, y que al comienzo de cada room, o con cada cierto progreso, se vayan cargando los recursos de los rooms más inmediatos. Sin embargo, veo dos inconvenientes:

a) El método se debería implementar a la par que el juego se va creando, o en sus primeras etapas. Tratar de implementar el sistema en un juego casi completo y con tantas rooms quizás sea problemático.

b) A mi modo de ver, no es una solución recomendable: por un lado, la solución implica cargar externamente archivos, pero por otro lado, la misma gente de YoYo advierte que cargar sprites (o cualquier recurso gráfico) de manera externa NO ES RECOMENDABLE (sobre todo en dispositivos móviles) pues afecta el rendimiento gráfico. Entonces tenemos que lo que parece la única solución, no se debe usar. (ojalá alguien dé una solución mejor)

Otra cosa que se me ocurre es que los rooms se creen "al vuelo", es decir, al comienzo del juego sólo hay un room inicial (o los mínimos que se necesiten para comenzar a jugar) y después sería cuestión de ir construyendo dentro del mismo juego los rooms a medida que se vayan necesitando,  mediante las funciones como room_add, room_instance_add, room_set_background, etc. De igual manera, para juegos pequeños puede funcionar, pero veo difícil aplicar este principio con juegos grandes como el tuyo.

En resumen, las opciones que se me ocurren ahora no son muy buenas, si alguien pudiera dar mejores alternativas, creo que más de uno le estaríamos agradecidos (o si tu mismo encuentras una solucion, Mega G, no dudes en compartirla)

Este es el causante del error

[gml]///Lanzar
if( agarre and (mouse_check_button_released(mb_left) or d > 16) )[/gml]
Esta condición no está bien formulada, hace que en cada paso (incluso en el paso donde se acaba de presionar el botón del mouse), si la distancia es mayor a 16, se suelte la bomba, por eso no es posible arrastrarla si el puntero está a más de 16 pixeles del origen. Puedes borrar la última parte de la condición o o cambiar de 16 a un número mayor.

¿No puedes colocar el proyecto para verlo más a fondo? aunque sea una versión con sprites simples/alternativos

Parece que sí, pero no veo que estés usando collision_circle en ningún lado.

¿Has probado a modificar esto?
[gml]if( mouse_check_button_pressed(mb_left) and d <= 16 )[/gml]

Por ejemplo, en lugar de 16, poner 50 (o un valor mayor). A mi me parece que con eso ya podrías arrastrar el objeto aunque no pinches exactamente dentro de su sprite.

http://freesound.org/

Sé que hay muchas, pero de las que he probado (gratuitas), es la que en mi opinión tiene más variedad y mejores efectos.

Cita de: Mataca en Febrero 04, 2015, 02:56:30 AM
Cómo se llama el botón back de android?

"Back Button". Esta parte del manual indica qué constante del teclado corresponde al botón trasero:

http://docs.yoyogames.com/source/dadiospice/002_reference/mouse,%20keyboard%20and%20other%20controls/device%20input/index.html

Tienes que usar las siguientes variables para conocer cuáles son las medidas del GUI en el dispositivo y usar esas medidas para posicionar las teclas virtuales.

display_get_gui_width
display_get_gui_height

http://docs.yoyogames.com/source/dadiospice/002_reference/windows%20and%20views/index.html

En un arreglo de 5X3, las cuatro esquinas corresponderían a los elementos
[0,0]
[4,0]
[0,2]
[4,2]

Tendrías que leer el valor de cada uno de esos 4 elementos y ver si coinciden (uno a uno) con los mismos números que están en azul.