Comunidad Game Maker

No sé, habría que ver el código que tienes en STEP, pero ojo, si usas esto en STEP (suponiendo que funcione bien)

if global.nTiempo >= 10 {instance_create(100,100,Ocasa)};

Como STEP se ejecuta constantemente, esto va a provocar que al siguiente paso, después de 10, el contador sea 11, y la condición sigue siendo verdadera, por lo que se va a crear otra casa, y al siguiente paso, otra casa, etc, etc. Tienes que poner un límite a la creación de casas (hay varias formas de hacerlo, depende de cómo se comporte tu juego, una puede ser mejor que otra)

Cita de: empardopo en Diciembre 11, 2014, 01:33:02 PM
El problema que obtengo es que cuando pulso la tecla se desintegran todos; se me ha ocurrido y además era el objetivo final hacer que cuando pulse con el botón izquierdo del ratón sobre uno de los objetos sea cuando se desintegre.
Así que me he añadido un evento mouse - Left Button a mi objeto enemigo pero no consigo que haga nada.

Lo que sucede es que en el objeto enemigo, tienes un evento de tecla Q en donde haces bom = true. Como esto está definido en el objeto enemigo, y además, en el evento DRAW se hace la explosión cuando bom == true, todas las instancias enemigas que haya en la habitación van a reaccionar a la tecla Q y dibujarán la explosión.

La solución es crear un método para seleccionar una sola instancia del objeto enemigo y aplicarle individualmente la desintegración. Está bien que hallas elegido el objeto controlador para hacer eso, pero Mouse Left Button se ejecuta constantemente mientras hagas click con el ratón, entonces, el código de ese evento se podría repetir varias veces mientras no se suelte el botón izquierdo, lo mejor es usar Mouse Left Pressed para que sólo se ejecute una vez por click

En ese evento tienes "bom = true", pero fíjate que la variable bom pertenece al objeto enemigo, así que para referirte a bom del enemigo desde el objeto controlador, la instrucción debería ser obj_enemigo.bom = true. PEEERO, este código va a ocasionar lo mismo que ya pasa, se aplica generalmente a todas las instancias del objeto enemigo. Lo que hay que hacer es obtener el identificador de la instancia donde se hace click y usar eso para ajustar la bom de esa instancia

[LEFT PRESSED] Objeto controlador
[gml]
inst = instance_place(mouse_x, mouse_y, obj_enemigo);      //Guardar el id de la instancia enemiga que coincida con la posición del mouse
if (inst != noone)
     inst.bom = true                                                          //Si la posición no estaba vacía (había instancia), cambiar bom de esa instancia a true
[/gml]

CREATE siempre ocurre una sola vez, antes que STEP

La variable nTiempo la aumentas en STEP, pero como CREATE ya se ejecutó (y no vuelve a ejecutarse más) no hay manera de que ese IF se ejecute. Si vas a evaluar una condición para un contador que se actualiza en STEP, la única opción es usar el mismo STEP para evaluarla (o DRAW, dependiendo del caso)

Cita de: TheSandBoxMKG en Diciembre 11, 2014, 05:21:31 AM
Ademas en el foro hay un post que aconseja usar surfaces para dibujar (no me acurdo de donde pero eran algo asiu como 11 consejos de optimizacion, o que se yo  :P)

Bueno, acabo de hacer la prueba, y en este caso al menos (dibujar sprites animados mediante surfaces) no noto ninguna optimización ni mejora. He usado los dos métodos: dibujar los sprites de dos objetos de la manera tradicional, directamente en pantalla, vs la otra manera, por surfaces. En la esquina superior derecha se muestran los frames por segundo reales a los que corre el juego, como puede verse, usar surfaces no mejora el desempeño en este caso, además que supone usar más código:

a) Como se usan surfaces y éstas son estáticas, hay que manejar contadores adicionales para controlar la velocidad de animación (en draw, hay que cambiar de surface cada ciertos steps para dar la impresión de que es una animación, cuando en el método tradicional eso se hace automáticamente al darle un valor a image_speed

b)El método tracicional tiene otra ventaja, que es que la animación del sprite se cicla automáticamente, en cambio, con surfaces, hay que revisar si se llegó a la última surface para volver a la primera. Si se usa una sola surface para meter todos los frames, pasa lo mismo, hay que controlar el ciclo también manualmente

A mi me gusta usar surfaces, también he leído que en ciertos casos es recomendable usar surfaces, pero por lo que me ha tocado leer, son otros casos. Si dibujar sprites animados fuera más óptimo mediante surfaces, sería extraño que prácticamente nadie use este método de manera normal en sus juegos (no he visto este método en ninguno de los ejemplos que he descargado de la GMC), ni me he topado alguna referencia de YoYo al respecto (en este artículo sobre optimización sugieren usar surfaces, pero para una situación distinta: escalado a diferentes resoluciones https://www.yoyogames.com/tech_blog/30). Así que en mi muy personal opinión, no encuentro justificación para meter más líneas de código en un proyecto cuando el desempeño del juego no va a beneficiarse comparándolo con la "forma éstandar" que además requiere menos líneas.

En el video, los frames del juego cayeron por el uso de CPU que demanda el propio programa de captura, pero sin ejecutar éste último, en ocasiones los frames del método tradicional eran ligeramente más altos que los de las surfaces (digamos unos 30-60 frames más). Supongo que entre más surfaces se usen, la diferencia de frames se podría incrementar ligeramente.  Y bueno, ya le llené a Xizotono su post de mucho rollo que lo más seguro es que ni tome en cuenta, mil disculpas.  :-[
Link al video
https://www.dropbox.com/s/oit9ndvcflv828a/surfaces.mov?dl=0

NOTA: Las animaciones por surfaces se ven más lentas sólo por la velocidad "manual" de animación que elegí, no porque el juego se vuelva más lento. Dibujé en la surface sólo en CREATE, si se usara step para dibujar en ella, probablemente la cantidad de fps bajaría, aunque no creo que mucho.

Cita de: TheSandBoxMKG en Diciembre 11, 2014, 01:51:33 AM
usar varias surfaces.

Entonces, como dije en un principio, se estaría usando más veces draw, lo cual no genera ningún beneficio real, pudiendo dibujar directamente los sprites en pantalla, sin mencionar todo el código que se implicaría usar para dibujar en las muchas surfaces que se necesitarían. Y como dije, esto no resuelve el problema principal, que es hacer todo el juego de sprites animados de todas las ropas acordes a los movimientos del jugador

Ejemplo:
un juego de armadura de 6 piezas (casco, peto, manopla izquierda y derecha, greba izquierda y derecha, todos animados). Se usarían 6 instrucciones draw para dibujarlas en la surface, más el propio sprite del jugador, y como mencioné, dibujar sólo al momento de cambiar de ropas no produciría animación, por lo que se estaría dibujando a cada paso. Al final se estarían usando 7 u 8 instrucciones para dibujar un solo "frame", sin contar con que se manejarían varias surfaces y las surfaces hay que borrarlas después de usarlas, según aconseja el manual. A esto no le veo ventaja sobre dibujar directamente los sprites, en donde serían 6 draws y te olvidas de manejar surfaces, cambiar target y borrarlas.

Cita de: TheSandBoxMKG en Diciembre 10, 2014, 08:02:57 PM
Si no entendiste, hablo de dibujar esos sprites solo cuando cambias de vestimenta y re-usar los surfaces dibujándolos en la pantalla

Tengo mis dudas sobre si eso funcionaría, a lo mejor se me escapa algo, pero si dibujas sprites sólo cuando se cambia de ropa, estarías dibujando superficies "sin movimiento": Según los mensajes anteriores, toda la vestimenta y armaduras serían animadas. Para que la vestimenta y armaduras sigan el movimiento del jugador, se tienen que dibujar constantemente las subimágenes de ESOS sprites en la surface mientras el jugador tenga una pose o acción animada. Dibujar los sprites una una sola vez produciría que sólo se vea UNA subimagen de cada pieza de armadura, es decir, hecharía al traste las animaciones. Así que al tener sprites animados, forzosamente se requiere un dibujo constante (ya sea en la superficie o en la pantalla) y no nada más cuando se cambia de ropa.

Como en GM nativamente no hay superficies animadas, no hay manera de tener subimagenes en una superficie y poder asignarle una velocidad a la cual reproducir la animación. Claro que se pueden dibujar cada subimagen de cada sprite en un arreglo de superficies y dibujar una tras otra para dar la impresión de animación, pero veo difícil que alguien se decida a tomar esta ruta.

Cita de: empardopo en Diciembre 10, 2014, 11:24:53 AM
¿Alguna ayudilla please del motivo por el que empieza a pintar con distintos tamaños y orientación la barra de energía?

Eso pasa porque esa es la instrucción en DRAW del objeto enemigo:
[gml]
draw_healthbar(obj_enemigo.x,obj_enemigo.y,x+43,y-5,myHealth,c_black,c_red,c_green,0,true,true);
[/gml]
Los dos primeros parámetros dependen de x e y del enemigo, pero cuando se crea el objeto enemigo, el script le da valores aleatorios a esas variables:
script_execute(scr_creaEnemigo,xRand,yRand,numImagen);

Por eso cambia el tamaño y posición de la barra de vida. Otra cosa es que en el script tienes
idObjeto.index_imagen = numImagenObjeto;
pero creo que debería ser image_index. Me parece que por pura casualidad te funciona, porque tienes únicamente un sprite en el proyecto, y justamente a numImagen le das valor de 1, que es el índice del único sprite (internamente el índice de los sprites que maneja GM comienza en 1, si no recuerdo mal).

Por último, si en el juego va a haber más de un enemigo en pantalla (a la vez), no es recomendable usar obj_enemigo.x y obj_enemigo.y, la solución es usar
[gml]
draw_healthbar(x, y,x+43,y-5,myHealth,c_black,c_red,c_green,0,true,true);
[/gml]

para información sobre surfaces, visite:
http://www.comunidadgm.org/preguntas-y-respuestas/que-es-un-surface/msg93208/#msg93208
http://www.comunidadgm.org/preguntas-y-respuestas/(resuelto)hacer-un-sprite-en-base-a-dos-tres/msg99687/#msg99687

Es cierto que se pueden usar surfaces, pero no creo que eso resuelva la problemática central: La superficie se dibuja sólo una vez, sí, en la pantalla, pero para dibujar en la superficie, tienes que cambiar el target, y, si tienes 5 o 6 piezas de armadura (sprites) distintos, se tendría que usar 5 o 6 veces la función draw para dibujar esos sprites o piezas en la superficie, así que al final, mediante surfaces, usaste la función draw las mismas veces para dibujar todo un set de armadura que dibujando directo en la pantalla (en realidad, una más, por la necesidad de dibujar la surface misma al final)

Lo complicado es hacer un número significativo de sprites, contando con que son animados, por lo que todas las piezas deben encajar con el movimiento del jugador. Ya sea que con draw, especificando las coordenadas x, y respecto al jugador, o como dijo emanuelsko, en el mismo sprite animado del jugador ir dibujando las piezas de la armadura y al final borrar el jugador. Teniendo los sprites listos, dibujarlos uno por uno directo en la pantalla o en una surface es sencillo

No, el código en "Creation code" es como un SEGUNDO EVENTO CREATE. Se ejecuta una sola vez, antes del evento [Room Start]. Más que nada sirve para inicializar variables y especificar alguna configuración de manera individual, pero no se ejecuta en cada paso

No, en ambos eventos depende del código que utilices y qué tan bueno seas programando que puedas hacer las cosas con las menos líneas de código posible (y no usar funciones lentas). A menos que tengas cientos o miles de objetos, no debería haber ralentizaciones. En el último de los casos, ¿por qué no comprobar si es cierto o no, poniendo código en el "Creation Code" y así salir de dudas?

Los paths tienen una velocidad, representada por path_speed (o algo así, no recuerdo el nombre exacto). Debes comprobar si el jugador está sobre la plataforma, y si es así, moverlo a la misma velocidad (y por supuesto, también detener la gravedad/vspeed del mismo). Esto se tiene que hacer siempre y cuando no se presionen las teclas de movimiento del jugador, de lo contrario, el jugador debe moverse a su propia velocidad.

Dos cosas:
1. Primero, antes de destruír las instancias, deberías preguntar si existen. Tal como está el código, y debido a que está en STEP, una vez que se destruyen las instancias, al siguiente STEP se vuelve a llamar ese código, pero las instancias ya no existen más, y esto ocurre así todo el tiempo que exista el objeto control o mientras corra el juego.

2. Deberias asignar un parent a obj_1, obj_2, obj_3  porque este tipo de operaciones se facilita si hay un parent.

3. (Ya sé que dije dos, pero esto es importante) Dices que al hacer click en la instancia obj_1, se procede a destruír las tres instancias DESDE EL OBJETO CONTROL. Puede que la manera en cómo avisas al controlador que tiene que destruír las instancias sea parte del problema.

Suponiendo que se crea un objeto parent obj_parent para los tres objetos, y que hay una variable que indica si se hizo click en el objeto obj_1 entonces, para destruír los  3 objetos:
[STEP] de obj_control
[gml]
if (click == true) and (instance_exists(obj_parent) )
{
     with (obj_parent)
          instance_destroy()
}
[/gml]

32000 no es la velocidad de muestreo más común. Creo que lo que está pasando es que originalmente el mp3 está manejando otra frecuencia distinta (44 kHz es la más común), pero como tienes una velocidad distinta, por eso ocurre la conversión. Revisa las propiedades del mp3 original, revisa cuál es su tasa de muestreo/samplig. Intenta poner ese valor en GMS. ¿Qué versión de GMS usas? No me ha pasado (o no he visto) que GMS se comporte así con los WAV que he usado, probaré a ver que pasa.

EDITADO: Pues nada, he hecho pruebas, y me ocurre lo mismo que a ti. Aunque el archivo original sea WAV, y elija Uncompressed, GMS lo convierte.
"Converting test to Wav 16bit mono @ 44100Hz"  <--- el archivo original ya estaba a 16bits/441000

No tengo idea por qué ocurre esto, no le veo caso a reconvertir un wav nuevamente a wav con las mismas propiedades. Ignoro si hay un motivo para que esto ocurra o es un bug. Se puede reportar a YoYo/preguntar en el helpdesk, pero de momento puedo vivir con esto, además, en las últimas semanas YoYo no puede procesar rápido los tickets de helpdesk debido a un alza en el número de reportes de errores que están recibiendo  :P

Cita de: carlymx en Diciembre 09, 2014, 01:13:09 AM
En estos casos la idea seria que  :GMS: gestionara el tema, pero no tengo ni idea de como hacerlo y estoy tremendamente interesado en saberlo yo tambien.

Hay suficientess fuentes para consultar y entender cómo funciona
https://www.yoyogames.com/tech_blog/79

http://www.comunidadgm.org/preguntas-y-respuestas/como-hacer-niveles-desbloqueables-estilo-angly-birds-y-que-se-grabe-el-progreso/
http://www.comunidadgm.org/preguntas-y-respuestas/desbloquear-niveles/
http://www.comunidadgm.org/intercambio/(aporte)-niveles-desbloqueables/msg100257/#msg100257