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 !
Y como exactamente hiciste esa prueba? porque cuando yo lo pruebo el evento Intersect Boundary también ocurre en el mismo step que es detectado. Lo que dice Penumbra es que hasta que el objeto no se mueva más allá del punto que GM considera "tocando el borde" el evento no ocurrirá, aunque en realidad ya debería haber ocurrido steps atrás.
Bueno hice un objeto.
En el evento Create puse:
hspeed = -1;
En el evento Intersect Boundary
x = xprevious;
y = yprevious;
hspeed = 0;
En el evento Create puse un breackpoint, con la tecla F9.
Corri el "juego" en modo debugger. Inmediatamente el debugger "salta" permitiendome ver varias ventanas. Entre ellas la ventana Source y la ventana Locals.
El debugger entonces me permite correr el juego una linea de código a la vez con la tecla F11.
Entonces atravez de un analisis de la información que las ventanas Source y Locals del debugger, concluyo que las acciones programadas en el evento Intersect Boundary se realizan un step despues.
Pero sinceramente esto es ahogarse en un vaso de agua.
La verdad que para que un ser humano se de cuenta que el objeto se salío un pixel durante un step (osea 0.33 segundos ! si el room_speed es 30) es sumamente improbable.
Por tanto de mi parte:
1)No es bug.
2)Es algo tan minusculo que no afecta en nada.
¡Pues me alegro de que al fin lo pillarais! ;D
Por cierto, en mi ejemplo supongo que la "mascara" del sprite es el sprite completo. :P
Y aunque es una tontería para juegos avanzados, sí, lo voy a reportar.
Pero no dices a través de que análisis o de que información llegas a esa conclusión, yo puedo decir que descubrí que las ranas que viven 300 años sacan alas, pero cuando me pregunten como llegue a esa conclusión yo no puedo decir, bueno primero agarre una rana y le hice una prueba de ADN y con algunos análisis e información demostré que es cierto.
Pero bueno, vamos a hacer la prueba como tú la haces, con la adición de algunos elementos de control, primero otro objeto que avanzara en la posición contraria, segundo una variable de control que indicará el momento justo en que el evento se activa, tercero, un contador de steps:
(https://imageshack.com/a/img843/5628/mqgg.gif)
Como vemos en la imagen, los objetos empiezan en la misma posición, moviéndose en direcciones opuestas, 1 pixel a la vez.
Cuando el objeto superior llega al borde de la room aún no se ha activado el evento intersect boundary, porque la máscara de colisión aún no ha salido de la room, no es hasta el próximo step que el movimiento del objeto lo enviara fuera de la room, lo que activa el evento Intersect Boundary, que con el código que tú mismo has propuesto lo enviara a la posición del step anterior y eliminara su velocidad. Como resultado, parecerá que no ha cambiado de posición, pero la variable de control de este objeto se cambiara para indicar que en efecto el evento ocurrió.
Cuando el objeto inferior llega a su borde puede pasar un pixel extra, este él es bug que estamos discutiendo, que según tu no es un bug, aún pasado ese pixel extra en el próximo step el objeto intentará seguir moviéndose, es hasta ese momento que el GM lo considera fuera de la room, y de nuevo tu código se activa, lo envía a la posición anterior y elimina su velocidad.
Por supuesto no planeo que tomes una simple imagen como prueba, por eso acá dejo el proyecto. Si crees que me equivoco en algo y tienes la prueba de que el evento Intersect Boundary se ejecuta 1 step tarde después de haber ocurrido, o aún más tarde como decias en un post anterior, siéntete libre de demostrarlo, pero haciendo eso, demostrándolo, no solo diciéndomelo.
Me parece que lo que ocurre acá es que no entiendes completamente cómo funciona el evento, al evento no le interesa si el la máscara de colisión del objeto está al lado del borde del room, solo le interesa si la máscara se sale del room, igual que en los eventos colisión no importa si la mascaras de dos objetos están "tocándose", solo importa si una está sobre la otra.
Uff... pared de texto... en fin, si, el bug es insignificante pero nosotros no somos nadie para decir si puede afectar o no a alguien más, después de todo Marth lo notó.
1)Te doy la razón cuando dices que debo demostrarlo y no simplemente escribir que lo he logrado por medio de un analisis etc.
Pero la razón de esta resumida explicación es que estoy apelando a tu experiencia y conocimiento del uso del GM, por tanto creo que no es necesario darte una explicación extremadamente detallada.
Ademas para evitar poner como tu dices: "una pared de texto".
2)La prueba que tu posteas, realiza exactamente lo que yo vi con mi prueba. Ademas es algo con lo yo estoy desde un inicio de acuerdo.
Osea yo estoy de acuerdo contigo en porque y como funciona este evento.
La unica diferencia es que yo no considero un bug que el objeto se salga un pixel por algunas orillas del room.
Esta opinión simplemente lo doy por la
manera en como mi mente entiende el GM: Steps y Eventos.
Pero si creo que esto es algo que no debería suceder de esta manera, por tanto no le veo ningun problema que se reporte esta situación como un bug.
PD
[user]Killer[/user]: Te agradezco tu respeto y palabras consisas. Espero que no lo tomes como algo personal, por que para mí no lo es.
Nah tranquilo, acá no hay nada personal, igual ya le dimos muchas vueltas al tema, cada quien tiene su opinión y es obvio que eso no va a cambiar.
Con Marth reportándolo ya quedará en manos del staff de Yoyo ver si es bug o no, en todo caso disculpa si en algún momento soné grosero o terco.
Ya informe a yoyo Games del pequeño bug.
Ahora lo demás ya es cosa de dicha empresa...