Hola chicos...
Según el tuturial de http://www.comunidadgm.org/manual_GM/Redibujando_la_pantalla.htm
la función screen_refresh() refresca la pantalla, pero yo no tengo esa función en el GM.
¿Por qué? ¿Hay alguna función similar? ¿Alguna doc buena de mi versión? En la web oficial no encontré nada...
Un saludo,
No tengo GM Studio y no encontre mucho al respecto. Vi un codigo que deberia funcionar:
var _selfid;
_selfid = id;
with (all) {
if id != _selfid {
event_perform(ev_draw,0);
}
}
Pero no redibujara los tiles, backgrunds,... solo ejecutara los eventos Step de todos los objetos, y sin importar su depth.
En la pagina (http://gmc.yoyogames.com/index.php?showtopic=561215) recomiendan hacerlo de otr mnera, sin screen_refresh
Para que lo necesitas?
Gracias, Mgbu..
Lo probaré.
Lo cierto es que encontré otra vía para hacerlo. No fuerzo un redibujado, pero si puedes esperar a que se redibuje sólo, me funciona bastante bien.
El tema es introducir un objeto sin sprite en el room, y usar su evento DRAW. La idea sería usar variables booleanas para cuando yo tenga que redibujar algo. Por ejemplo, poner un texto al pulsar sobre un botón (imagen-objeto). Pues creo una variable que al pulsar sea true y en otro caso mantenga false. Luego chequeo esa variable en el DRAW del objeto sin sprite, y si es true dibujo lo que necesito... El texto o lo que sea.
A mi, de momento me funciona bien.
Ahora bien, después de llevar programando toda mi vida, os tengo que decir que este sistema de código que tiene GM me parece bastante arcaico, por decirlo de forma suave. ¿No hay ningún documento donde se explique con claridad cuándo y dónde se produce cada evento de los que tiene GM? Realmente, su ayuda me parece bastante mala. Muy pobre.
Creo que el producto es bueno en si, pero la integración con código es muy mala, o está mal explicada, o incluso indocumentada.
En fin, en mi parecer... Que para hacer una cosa que sería muy sencilla en el propio Java, haya que andarse exprimiendo la cabeza para ver cómo reflejarla en GM....
Un saludo,
O sea que queres hacer algo asi como una ventana emergente, la verdad es que en GM no encontre una forma optima, yo creo un obj_popup con un sprite que sea el fondo y dentro pongo los chequeos de botones y eso. De esa forma no se ejecutan los eventos ev_click de los objetos que estan detras, pero igual la forma es un poco precaria. Aunque no llego a ver donde usas el screen_refresh
Y si, para mi tambien como se ejecutan los eventos no esta demasiado claro, porque como no estoy muy avanzado en programacion simplemente me limito a ver su nombre. Por ejemplo si hay un evento "Keyboard Press" el codigo de adentro se supone que se ejecuta cuando se presiona esa tecla, o si hay un "Alarm" se ejecutara cuando termine su temporizador
Hace poco habian preguntado el orden de ejecucion de los eventos Begin Step, Step y End Step, te puede ser util, aunque nunca lo necesite (Gracias
Penumbra):
Cita de: penumbra en Febrero 19, 2013, 07:49:19 PM
La diferencia es que uno se ejecuta primero que el otro. ;D
De los tres, el STEP normal es el más usado, pero puedes usar BEGIN STEP por ejemplo, para asegurarte que ciertas cosas pasen antes que otras cosas, y que después pase algo más en STEP, y que después ocurra algo más en END STEP.
Después de que el juego se crea (GAME START), el orden de eventos es (sacado de wiki)
Create Event (una vez)
Begin Step
Alarm 0
Keyboard and mouse
Keyboard and mouse press
Keyboard and mouse release
Step
End Of Path
Outside room
Intersect Boundary
Collision events
End Step
Draw
Animation End
Es interesante ver que las colisiones se evalúan ANTES que END STEP, por lo que tu código puede funcionar bien en STEP y no en END STEP, o viceversa. A mi esto me ocurrió y no sabía por qué motivo pasaba. ???
Cita de: internauta en Abril 06, 2013, 04:33:27 PM
Lo cierto es que encontré otra vía para hacerlo. No fuerzo un redibujado, pero si puedes esperar a que se redibuje sólo, me funciona bastante bien.
El tema es introducir un objeto sin sprite en el room, y usar su evento DRAW. La idea sería usar variables booleanas para cuando yo tenga que redibujar algo. Por ejemplo, poner un texto al pulsar sobre un botón (imagen-objeto). Pues creo una variable que al pulsar sea true y en otro caso mantenga false. Luego chequeo esa variable en el DRAW del objeto sin sprite, y si es true dibujo lo que necesito... El texto o lo que sea.
A mi, de momento me funciona bien.
Bueno es que esa es la manera común de hacerlo, a quien se le ocurre que tiene que redibujar la pantalla completa cada vez que quiere dibujar algo.
Cita de: internauta en Abril 06, 2013, 04:33:27 PM
Ahora bien, después de llevar programando toda mi vida, os tengo que decir que este sistema de código que tiene GM me parece bastante arcaico, por decirlo de forma suave. ¿No hay ningún documento donde se explique con claridad cuándo y dónde se produce cada evento de los que tiene GM? Realmente, su ayuda me parece bastante mala. Muy pobre.
Me parece que en esto tienes razón. La documentacion de gm esta muy revuelta y muchas veces incompleta aunque no me parece algo "arcaico", creo que solo es cosa de acostumbrarse.
Cita de: internauta en Abril 06, 2013, 04:33:27 PMEn fin, en mi parecer... Que para hacer una cosa que sería muy sencilla en el propio Java, haya que andarse exprimiendo la cabeza para ver cómo reflejarla en GM....
Creo que eso es más bién por que sigués pensando como si estubiaras en java. Gm se basa en eventos y tienes que esperarlos para hacer las cosas, así de simple. Recuerda que gm es para programar juegos y por lo general necesitas un orden constante en la ejecucion de los eventos para que todo esté en tiempo real, esto no siempre es lo mas optimo pero funciona, así pues lo normal es que los menus y cosas inmobiles de ese tipo se redibujen constantemente por si solos en lugar de como se haría en otros lenguajes.
Creo que tienes razón... Pienso en programar OO, cuando es OE (Orientado a Eventos).
Aún así, VB6 era orientado a eventos más que a objetos, y era muy diferente a esto.
Me costó un poco entender la estructura de Unity 3D, y decidí cambiar a Game Maker porque yo quería hacer juegos 2D, y me parecía que Unity 3D se me iba demasiado para lo que yo buscaba. Aún así, ¿no os parece que Unity serían palabras mayúsculas y GM son minúsculas? Ojo, que no intento menospreciar GM. Me parece un muy buen producto, pero en estado embrionario todavía. Hay otros motores, como Torque, por ejemplo, que también permiten grandes cosas y se programan en C. Unity usa C y/o JavaScript. GM todavía tiene que recorrer camino para llegar a esa integración de código de otros motores.
Aún así, como os digo, me parece un buen proyecto, pero con camino por delante. Veremos si lo recorren o no.
Hay cosas que no están bien y son fundamentales. Por ejemplo, ¿por qué la función de terminar la aplicación no funciona bien en Android?
¿Cómo crear un objeto de forma sencilla? Yo todavía no lo se...
¿Y un sprite? ¿Cómo crear un sprite, ponerlo en pantalla y que no esté debajo de los objetos? Esto debería de ser una propiedad del sprite creado, y sin embargo, no logro encontrar solución sencilla a esto...
En fin... Esto de la programación de juegos es un mundo. Llevo muchos años programando y creo que veo cuando un producto es bueno o no. GM lo es, pero con reservas.
Seguiré intentándolo, pero me temo que al final tendré que usar Unity con una cámara fija para hacer juegos 2D.
Gracias a todos por las respuestas. Las probaré todas.
El refresco de toda la pantalla lo necesitaba porque no me pintaba los sprites y pensé que tal vez así lo haría.
Aún así, si alguien me dice cómo crear un objeto en código y asignarle un sprite, perfecto.
Y también cómo crear un sprite que tenga definido en GM y que esté en primer plano...
Intento usar la propiedad depth, pero no me funciona. No me hace caso. Y yo creo que es porque no se referenciarlo. Uso draw_sprite para pintar el sprite, pero luego no se cómo decirle que lo ponga arriba...
En fin, gracias...
No se, yo veo al GM como una forma de aprender a programar (a mi me sirvio muchisimo, empezar arrastrando cuadrados y traducirlo a escribir me parecio muy bueno para empezar). A lo mejor queda un poco corto en juegos complejos, a lo mejor tambien el GM tiene manias que hay que superar, pero me gusta:
No se como cerrar una aplicacion en Android, habria que ver el manual pero el de la comunidad (en mi firma) es de GM 8
Para crear un objeto se presiona la pelotita en la barra de tareas, o se hace click derecho en una carpeta (subdirectorio de Objects) y se pone Create a new object o algo asi. Pero si queres crear una instancia de ese objeto se debe escribir instance_create(x,y,objeto). Otra forma de crear instancias es colocarlas en el editor de rooms
Para crear un sprite se hace igual que con el objeto. Su posicion en pantalla no es una propiedad del sprite, es una propiedad del objeto. Aca viene lo que podria ser una mania del GM: El depth del sprite dibujado es el del objeto que lo dibuja. Supongo porque el GM se maneja por eventos, entonces depende del orden en que se ejecute el evento Draw de tu objeto
Para agregarle un sprite al objeto se puede hacer en la esquina superior izquierda de la ventana del objeto, o puedes dibujarlo vos mismo en un evento Step
No quiero retar ni nada, si no intento decir que el GM no se queda corto en lo que has preguntado, se debe quedar corto en el 3D, en el rendimiento, o en cosas mas complejas en las que no tuve que renegar todavia
Gracias Mgbu...
Lo de instance_create es un claro ejemplo de la mala organización de los métodos de GM.
¿Por qué lo lía todo?
En fin... Lo que tendríamos que hacer es un manual bueno entre todos, y vendérselo a Yoyo... 8)
Un saludo,
Cita de: internauta en Abril 08, 2013, 10:01:43 PM
Seguiré intentándolo, pero me temo que al final tendré que usar Unity con una cámara fija para hacer juegos 2D.
??? Usar unity para 2d es casi como usar gm para 3D XD.
No tengo ganas de discutir mucho aquì, pero concuerdo contigo en que hay un muchisimas cosas en la misma estructura del gml que se pueden o deben cambiar, mejorar o añadir a gm. Incluso yoyo lo sabe pero intentan mantener la compatibilidad en versiones anteriores, en yoyo se habla mucho de una version de gm a la que de momento le llamàn gm:next(ya que serà la version desarrollada despues de studio) que aùn no està siquiera comenzada pero parece ser como el GM IDEAL.
[quote author=Mgbu link=topic=18470.msg87929#msg87929 date=1365462724
No quiero retar ni nada, si no intento decir que el GM no se queda corto en lo que has preguntado, se debe quedar corto en el 3D, en el rendimiento, o en cosas mas complejas en las que no tuve que renegar todavia
[/quote]
En cuanto al rendimiento, aunque no parezca gm:studio se lleva a varios engines 2d comerciales y dicèn que con la compilacion en llvm la ejecucion de còdigo llegarà a ser hasta 100 veces màs ràpida.
Por ultimo, te recomiendo experimentar algo màs con el gm. Quizàs al principio parezca engorroso, pero ya que entiendas bièn comò funciòna vas a ver lo fàcil y ràpido que es hacer las cosas.
Bruno, eres un crack :-) Me ha gustado tu primera frase...
Le voy a dar a GM más tiempo... :-)
He aprendido cosas en este foro, y también he hecho cosas en el mes que llevo de evaluación, y si es cierto que están pensando en sacar otra versión mejorada, habrá que verlo.
Pero, ¡¡¡ por Dios !!!, lo primero es un manual decente..... XD XD XD XD
Un saludo,