Comunidad Game Maker

Según las correcciones introducidas en la versión más nueva de EA, ahora se ha agregado una opción para la plataforma windows:

Se puede indicar que las páginas de texturas se carguen en demanda, es decir, sólo las páginas requeridas por la habitación actual se cargarían, al contrario de como se venía haciendo, que era cargarlas todas al inicio del juego.

Según el manual, este tipo de carga "inteligente"  YA existía para las demás plataformas (algo de lo que no tenía conocimiento  :o) y es el método usado en esas plataformas.

La carga por demanda provoca que haya una ligera pausa en el juego mientras se cargan las páginas necesarias, por lo que se recomienda optmizar las páginas de texturas de acuerdo a los recursos usados en las habitaciones/niveles.

Cita de: evansmako123 en Octubre 16, 2015, 09:12:45 PM
Problema numero 1: Tengo una animacion para cuando el peaton es atropellado, pero esta animacion se repite sin parar... me gustaria parara en el ultimo Sprite.

Suponiendo que el sprite se llame spr_atropellado. Una solución sería usar el siguiente  código en STEP

[gml]
if (sprite_index == spr_atropellado) and (image_index >= image_number-1)
     image_speed = 0    // Detener la animación del sprite en la última subimagen, antes que se repita
[/gml]

Otra solución sería agregar un evento ANIMATION END, y ahí escribir:
[gml]
if (sprite_index == spr_atropellado)
     image_speed = 0
[/gml]

Cita de: evansmako123 en Octubre 16, 2015, 09:12:45 PM
Me gustaria que la animacion se active solamente cuando toque los pixeles de la moto

Se necesitaría saber cómo estás manejando esa colisión, es decir, qué evento usas o qué función usas y en qué objeto.

No tengo idea de qué va el error, pero según el mensaje de error, se han generado reportes que indican las fallas

Ran lint on variant debug: 36 issues found
Ran lint on variant release: 36 issues found
Wrote HTML report to file:/C:/Users/Emart/OneDrive/Documents/GameMaker/Cache/MaritoRun/Android/Default/com.tictaclabs.maritorun/build/outputs/lint-results.html
Wrote XML report to C:\Users\Emart\OneDrive\Documents\GameMaker\Cache\MaritoRun\Android\Default\com.tictaclabs.maritorun\build\outputs\lint-results.xml

Si esto me pasara a mi, y no encontrara información en la web sobre el error, mandaría un ticket al soporte de YoYo. Seguramente ellos saben si esto es un error relacionado directaente con GMS o si es un error derivado de algún SDK externo.

Aquí alguien reporta un error similar, pero creo que no se ofrece una solución específica. El mensaje es de hoy, así que quizás con el paso de las horas, aparezca más información.
http://gmc.yoyogames.com/index.php?showtopic=679338

Creo que no te has percatado, pero con el código que has puesto, ya estás haciendo las dos cosas, tanto guardar un sprite como cargarlo.

La función screen_save("imagen.png") va a guardar un sprite en el directorio de trabajo de GM (saber su ubicación/ruta no es importante). Incluso si después cierras GM, esa imagen PNG queda ahí. La otra función, sprite_add("imagen.png",0,true,false,0,0) lo que realmente hace es CARGAR un sprite. ¿Qué sprite? Un sprite de nombre imagen.png que previamente se guardó en disco. Entonces, si te fijas, estás guardando y luego cargando.

Suponiendo que en mi juego tengo un botón que sirve para guardar una captura de pantalla, en el evento de click de ese botón usaría la primer función para guardar la imagen
[gml]screen_save("imagen.png")[/gml]

Ahora, al comenzar el juego, quiero que al entrar a la habitación 1 aparezca la imagen que previamente se guardó, si es que existe dicha imagen (el jugador pudo no haber guardado nada en la sesión anterior), entonces:

EVENTO ROOM START
[gml]
if file_exists("imagen.png")
     picture = sprite_add("imagen.png",0,true,false,0,0)   //Esto carga un sprite
[/gml]

EVENTO DRAW
[gml]
if (room == room1) and (picture > 0)    //Comprobar que se está en la habitación 1 y que la variable picture apunta a un sprite válido
     draw_sprite(picture, 0, 10, 10)         // Dibujar el sprite que se guardó en la sesión anterior.
[/gml]

Cita de: NiuWeb en Octubre 16, 2015, 06:39:29 AM
En una room, yo creé un sprite de esta manera:
[gml]screen_save("imagen.png");
sprite_add("imagen.png",0,true,false,0,0);[/gml]

Aquí estás cargando un sprite en GM que está previamente guardado. No importa si la función screen_save se uso en la sesión actual o en una anterior, eso deja un sprite almacenado en disco y la funcion sprite_add lo está cargando, justamente. Obviamente, la función screen_save puede ir en algún evento (cuando necesites guardar un sprite) y la función sprite_add puede ir en otro evento (cuando quieras cargar el sprite)

Cita de: NiuWeb en Octubre 16, 2015, 06:39:29 AM
y lo almacené en una variable global

El error es que un sprite no se puede almacenar en una variable real. Son tipos de datos diferentes. Lo que se almacena en las variables es símplemente un número (índice). Ese índice apunta a un recurso gráfico (sprite), pero NO ES un sprite. Un sprite es un conjunto de pixeles que no puede guardarse símplemente en un número.

De la misma manera, la variable sprite_index almacena un simple índice que apunta a un sprite. Apunta, pero no es el sprite en si mismo, como un número telefónico apunta a un teléfono físico, pero NO ES el teléfono físico, es sólo un número. Esta es la razón de por qué en el INI no se guarda ningún sprite/imagen, se guarda un número real nada más.

Las únicas maneras de guardar sprites de manera permanente son usando las funciones como
screen_save()
sprite_save()
sprite_save_strip()
surface_save()
background_save()

Cita de: Ynfiniti en Octubre 15, 2015, 02:25:56 PM
¿Podrías compartirlo Penumbra? es interesante ese efecto.  :)

Seguro, pero es un truco tan sencillo, que hasta da pena mencionarlo  :-[:

Como dije, a mi me pareció desde un principio que era un efecto visual. La idea se reforzó más en mi cabeza por el estilo monocromático del juego. El "truco" es usar "parches" (draw_rectangle) del mismo color que el fondo. Por ejemplo, en las barras:

Como se puede ver, el parche/rectángulo se dibuja encima de los otros objetos y es ligeramente menor que el objeto barra, para no bloquear sus bordes blancos.

La misma idea se aplica en las orillas/márgenes de la habitación. Alrededor del rectángulo blanco o marco blanco hay cuatro "parches" externos (entre los bordes de la habitación y el marco), dibujados en el evento GUI (que se dibuja por encima de todo). No importa que los objetos se traslapen en esa zona, esos cuatro rectangulos bloquean la visión y da la impresión de que hay una fusión con el marco blanco.

Todo esto funciona mientras el juego sea monocromático. Si los objetos tuvieran un color de relleno distinto al fondo, el efecto se estropearía.  :D

Cita de: Clamud en Octubre 15, 2015, 04:14:20 AM
No puedo acceder a sandbox.yoyogames, ¿tu sí?

También puedo acceder al link del sandbox

Cita de: Ynfiniti en Octubre 15, 2015, 03:59:15 AM
Se podría hacer así, pero creo que hay un método más elaborado para cosas como esas, un ejemplo es el juego "PANICBOX": http://sandbox.yoyogames.com/games/214428-panicbox , Cada figura al rozar o superponerse con otra, se mezcla con la otra figura y sus bordes desaparecen en el lugar en donde se solapan... quisiera saber como lo hicieron  :-[

Quizás me equivoque, ya que desconozco que lógica usó el autor, pero a mi me parece que en ese juego no se están fusionando objetos realmente, sino que es un efecto visual. Si esto fuera así, entonces ese método visual no funcionaría en un juego en donde se desea evaluar colisiones en los objetos fusionados considerando la forma resultante de la unión de dos o más sprites.

Lo que me lleva a pensar que en el juego panicbox no se fusionan realmente dos o más objetos en uno solo, es que para su mecánica, no tiene ningún caso fusionarlos.

1. A mi me da la impresión que en todo momento las colisiones se basan en las máscaras individuales de cada objeto y no en una posible máscara "fusionada"
2. Los objetos que se empalman, después de un tiempo se vuelven a desempalmar.
3. Por el número de objetos y su movimiento, creo que si se quisiera realmente fusionar objetos (y después de un tiempo "desfusionarlos"), se estaría requiriendo mucho procesamiento, y al final, si  no se fusionara nada, las colisiones seguirían trabajando igual.
4. Como hay muchos objetos en movimiento, la fusión/desfusión (perdón por el término) se estaría realizando en STEP una y otra vez, para muchas distintas instancias, y sin embargo, el consumo de procesador al correr el juego me hace sospechar que no ocurre ninguna fusión, aunque no lo puedo asegurar.
5. Creo que la mayoría del tiempo, el fusionar objetos es más apropiado (me refiero a juegos normales que no usan el engine de física box2d ) si esos objetos van a ser estáticos, es decir, objetos que después de fusionados ya no cambiarán de forma al siguiente STEP.

Igual me equivoco, pero esa impresión me da a mi. El efecto de fusión me gustó bastante, no sé si sea el método usado por el autor de ese juego, pero he logrado replicarlo aunque no lo he pulido por falta de tiempo:

Cita de: fasst007 en Octubre 15, 2015, 01:14:08 AM
Quitarlo sería que quede el sprite en 3x3 pixel con el cuadrito solo y dejandolo transparente el sprite mediria 10000x10000 pixel.

Eso formalmente se conoce como cropping o recorte o reajuste de canvas/lienzo, pero no me pareció que el post original hiciera referencia a esto.

Creo que si el usuario quiere remover el color de fondo, es porque desea conservar todo ese espacio vacío en el sprite final. Si esto no es así, y se quiere tener un sprite de un círculo sin espacio vacío alrededor, entonces no hay necesidad de usar la función sprite_add ni de recurrir a algo que borre un color de fondo porque:

a) Seguramente ya hay en el árbol de recursos un sprite con un círculo dibujado en él, sin lienzo/canvas enorme.

b) Si el inciso a no se cumple, en lugar de remover un color de fondo, se puede crear una superficie, se dibuja un círculo en ella (mediante un sprite o mediante la función correspondiente) y al final esa superficie se convierte a un sprite.

Cita de: Johann en Agosto 14, 2014, 01:26:22 AM
Recuerden que ComunidadGM es un foro oficial de Game Maker en español, reconocido por YoYoGames como tal, por lo tanto es ILEGAL solicitar y/o compartir software ilegal y no se debería hacer referencia alguna a éste.

Se supone que el tercer parámetro de la función sprite_add() sirve para remover el fondo, por lo que puesto en true, tal como está en tu ejemplo, debería quitar el fondo.

Para que la opción de remover el fondo funcione, el color debería ser parejo, ya que lo que hace GM es revisar de qué color es el pixel de la esquina inferior izquierda en el sprite, y borrar todos los pixeles que coincidan con ese color de ese pixel.

Ya vi a lo que te refieres. Lo que pasa es que tal como está el código, la detección y resolución de colisiones lo hace por partes, primero en una dirección, (x) y luego en la otra(y). Este lógica funciona cuando el jugador se mueve en ángulos múltiplos de 90° (arriba, abajo, izquierda, derecha), pero no funciona (bien) cuando el jugador se mueve en ángulos múltiplo de 45° (diagonales). En este último caso, la detección se debería hacer al mismo tiempo para las dos direcciones.

Para poder detectar una colisión correctamente cuando hay movimiento diagonal, entonces la función place_meeting debe incluír tanto el incremento xa como el incremento ya (en el código original sólo se incluye uno de los dos y por eso falla).

Aquí me estoy moviendo en diagonal, y ahora ya no se empalman los objetos:


El código modificado es este:
http://pastebin.com/1LQGcTHw

NOTA: Yo modificqué el nombre del objeto pared, así que tienes que cambiarlo al nombre de tu objeto o habrá un error.

Cita de: vitail en Octubre 14, 2015, 01:27:01 AM
quiero saber pq cuando yo muevo mi rectangulo a otro rectangulo hacia la esquina, lo traspasa

¿Un rectángulo a otro rectángulo?  ???

Probé el código, traté de colisionar contra objetos pared en todas las direcciones y el jugador nunca traspasó ningún objeto pared. No sé exactamente qué error te suceda, ya que la descripción no es muy clara.

real: "toma una una cadena y devuelve un número"

http://docs.yoyogames.com/source/dadiospice/002_reference/strings/real.html

No creo que haya un tamaño adecuado, más bien creo que depende del juego y el estilo del artista. Hay muchos sprites hechos en 32X32, aunque eso sí, tienen un estilo que tira más a lo deforme/cartoon/no realista. No porque alguien te diga hazlos de "64X32" tienes que hacerlos exactamente de ese tamaño. Intenta hacer los personajes aproximadamente un 30% o 50% más grandes, a ver si el resultado mejora. Tampoco se debería abusar haciendo los sprites muy grandes, porque es más tardado dibujar detalles en ellos y por lo mismo animarlos.

Busca juegos con un estilo similar al que quieres usar e intenta hacer personajes más o menos con las mismas características, sin que llegues a hacer un clon. La mayoría de personajes que he hecho rondan los 60 pixeles de alto, pero eso es una preferencia personal nada más. A menos tengas mucho talento, para hacer buenos sprites hay que invertir bastante  tiempo en practicar hasta lograr una apariencia aceptable.