Comunidad Game Maker

Encontré un pequeño fallo en las funciones tipo "en caso de que el sprite se salga de la pantalla" (ejemplo: outside room).
Para que entendáis mejor que falla, os paso un programa en el que se observa el fallo.
El programa solo consiste en un bloque que se puede mover con los botones de dirección del teclado, que esta programado para que no se salga lo más mínimo de la pantalla (he usado la función "Intersect Boundary"). Pulsando la tecla 'p' se pone en modo pantalla completa (con la tecla 'o' se sale de este modo).

A ver si es posible hacerle un arreglo.

El ejemplo que posteas es un .exe por tanto no se puede ver el código que usas, y tras de eso hay que instalarlo !

Cambia el ejemplo o pon el código que estas usando.

El evento Outside Room se ejecuta cuando el sprite del objeto esta completamente afuera del room.

El evento Intersect Boundary se ejecuta cuando el sprite de objeto toca la orilla interna del room.

Si los objetos no tienen sprite se tomara en cuanta entoces los valores  de las variables locales x y.

A ver si con esto ya puedes probar.

Por si hace falta, he creado una versión mejorada del programa original.
En esta, hay 2 objetos: uno que se vigila que no se escape de la pantalla con intersec boundary, y otro que tiene un algoritmo que hace de sucedáneo de dicho evento (y que a diferencia del otro funciona perfectamente).

He revisado sobre este bug, y he descubierto que también afecta a las funciones "view" (boundary view y outside view).
Subo otra revisión añadiendo un objeto que tiene una función de ese tipo entre otros experimentos mios.

Y cuál es el bug si es posible saberlo, es decir en qué consiste. Tienes cuatro mensajes, pero en ninguno se menciona específicamente cuál es el error, sólo que encontraste un error relacionado con intersect boundary y outside room. Todos los ejemplos están vacíos y no funcionan, excepto el último, el cual abro y la verdad no sé dónde está el bug o qué es lo que no quieres que suceda

Perdon por lo que voy a decir pero en el pasado ya he visto muchos posts de este estilo y lo que ocurre siempre es un fallo del programador y no de la herramienta. Seguramente sea falta de rigurosidad a la hora de conocer el gml ya que de ser asi, algún experto en la materia lo habría notado, reportado y ya estaría corregido y no tendríamos problemas con eso.

Me explico con un ejemplo: el evento intersec boundary debería funcionar en un objeto si sus coordenadas X o Y son menores que 0 o bien dichas variables más el ancho o alto de sus sprites son mayores que el ancho o alto del escenario (tras lo cual, el sprite esta saliendose de la pantalla), pero aunque funciona bien si las variables X o Y del objeto son menores que 0, ya no es así en cuanto a que sus coordenadas más el tamaño del sprite superen el tamaño del escenario, necesitando que avance en 1 punto más en la coordenada X o Y para que el programa determine que se debe activar el evento (por lo que puede estar saliendose un poquito el sprite, pero no se activara el evento).

Aunque claro, es solo un insignificante punto en las coordenadas X o Y, por lo que si el objeto se moviera por ejemplo de 2 en 2, no ocurre el fallo.

A parte, en el programa de experimentación que subí, lo interesante son 2 objetos, uno llamado "Fallo" que usa intersec boundary, y otro llamado "Correcto", que usa en end step un sucedáneo del evento intersec boundary.

Intersec boundary no depende tanto de las coordenadas del objeto, sino de la máscara que tiene, pon el punto de origen del sprite fuera del area del sprite y aún asi verás que se detiene cuando el sprite toca el borde, sin importar si las coordenadas del objeto son negativas.

Con eso dicho, Marth tiene razón, 1 pixel se escapa a la derecha y abajo antes de que Intersec boundary funcione. Probablemente un error de redondeo, deberias reportarlo a YoYo, en el menú Help de GMS esta la opción Report a Bug.

Así es, siendo estrictos encontraste un BUG (¡fanfarrias!  :D), aunque para que te llegara a afectar tendrías que manejar velocidades bajísimas para los objetos. Hice una prueba sencilla, sólo para los bordes laterales. Cuando el objeto sale por la izquierda, se reporta que sale cuando alcanza los -0.5 (medio pixel fuera en X). Cuando sale por la izquierda, en mi caso, hasta que salió 1.5 pixeles se reporta el evento intersect boundary.

Esto fue en windows, quizás varíe para otras plataformas.

Intersect Boundary es un evento y para que se "gatille" (trigger) es necesario que allá una colision entre el objeto y la orilla del room.
Entonces en el primer step el GM "se da cuenta" que hay una colisión entre el objeto y la orilla, pero no es hasta el siguiente step que el GM realiza (trigger) el Evento Intersect Boundary del objeto.
Osea siempre va ha ver una pequeña salida del room por parte objeto. Ademas creo que la colisión que GM realiza en este evento no es precisa.
Considero que este evento es igual a la casilla "Solid" de los objetos, osea ayuda a un novato a realizar cosas algo complejas de una manera sencilla pero no de una manera tan precisa.

Y esto lo confirma [user]Marth[/user] al decir que cuando el usa el Evento End Step no sucede, osea una manera mas precisa y controlada de verificar la posición del objeto.

En mi opinión no hay un bug, es simplemente como el GM funciona: Eventos y Steps

Aunque esto es solo mi opinión.


PD
[user]penumbra[/user] a que te refieres con "-0.5 (medio pixel fuera en X)" o "hasta que salió 1.5 pixeles" ?
Yo se, que tu sabes, que medio pixel es algo que no existe, solamente quiero saber a que te refieres.
O como sacaste esa conclusión ?

Entiendo que GM tarde un paso en detectar que el objeto salió, y que es hasta el siguiente paso en que se activa el evento intersect boundary, pero incluso puedes dejar todo el tiempo que quieras un objeto (muchos pasos), y aunque esté "salido", mientras no se supere ese umbral que GM necesita para detectarlo como "salido", no se activa nunca el evento intersect boundary.

Cita de: vampy09 en Mayo 02, 2014, 02:57:06 AM
PD
[user]penumbra[/user] a que te refieres con "-0.5 (medio pixel fuera en X)" o "hasta que salió 1.5 pixeles" ?
Yo se, que tu sabes, que medio pixel es algo que no existe, solamente quiero saber a que te refieres.
O como sacaste esa conclusión ?

Son los valores que me reporta GM al usar draw_text(100, 50, x),
Me da valores de posición con decimales, para mover el objeto en X uso x+= 0.1. La habitación mide 250 de ancho, y cuando el borde derecho del objeto (un simple cuadrado) llega a 251 en X, el evento intersect boundary no se lanza, sino hasta que (según draw_text) el valor de x llega 251.5

La verdad esto lo comento más por curiosidad que por otra cosa, digo, no me quita el sueño ni veo cómo me puede afectar este comportamiento. Nunca he usado el evento intersect boundary ni me imagino de momento una situación en que quisiera saber cuando un objeto sale apenas un pixel afuera de la habitación.

De donde sacas que el GM necesita 2 steps para generar colisiones? Las colisiones son detectadas en el mismo step en que ocurren, puedes comprobarlo tú mismo,  crea un evento colisión que muestre un mensaje cuando ocurre y corre el juego a poca velocidad, en el mismo step que la colisión debería ocurrir recibirás el mensaje.

Aparte, si ese fuera el comportamiento esperado debería presentarlo en toda ocasión, pero en este caso el costado izquierdo y superior generan el resultado correcto, mientras los costados derecho e inferior se comen un pixel. El que funcione cuando se hace con GML no demuestra que así es como debería funcionar, solo que hay otras maneras de hacerlo.

Y como menciona Penumbra, es cosa de nada, por eso mismo no lo estoy reportando yo mismo, pero que sea una tontería no significa que no es un bug.

Por cierto, lo que te devuelven x & y son coordenadas, las coordenadas pueden tener decimales, pero a la hora de calcular colisiones y dibujar estas son redondeadas.

[user]penumbra[/user] creo que haz dado con la clave cuando dices:

Citarmientras no se supere ese umbral que GM necesita para detectarlo como "salido"

Osea como calcula exactamente el GM este umbral ?Bueno, es algo que nosotros desconocemos.
Por tanto asumir que por que haya un pixel afuera durante este evento es un bug, creo que algo incorrecto.

CitarLa verdad esto lo comento más por curiosidad que por otra cosa, digo, no me quita el sueño ni veo cómo me puede afectar este comportamiento.

Concuerdo contigo. Esto es algo que sucede tan rápido que no creo que afecte en nada.

PD
Gracias por explicarme como hicistes tus pruebas !

[user]killer[/user]:
1) Estoy de acuerdo contigo: las colisiones se detectan en el mismo step. Lo que yo me refería es que el Evento Intersect Boundary se va ha llamar (trigger) en el siguiente  step que se produce la colision.
Pero como penumbra indica, esto incluso puede tardar varios step despúes de la colision.

2)Yo no digo que cuando se usa el GML es como debería funcionar. Lo quise decir es que si quieres mas control y precisión entonces no uses el evento, debes usar entonces GML.

3)Te repito mi opinión sobre el tema:

CitarEn mi opinión no hay un bug, es simplemente como el GM funciona: Eventos y Steps

CitarPor cierto, lo que te devuelven x & y son coordenadas, las coordenadas pueden tener decimales, pero a la hora de calcular colisiones y dibujar estas son redondeadas.

Por eso le pregunte a penumbra. Te agradezco tu respuesta tambien !
Saludos !