Tengo un problema para salto implementado con delta time, por cierto que aprendi de este foro. El problema es que no entiendo porque el vspeed no me funciona para la gravedad, ya que es tantos pixeles por step, o sea que su logica tiene para que funcionara perfectamente con Delta Time. Os pongo el codigo a ver si me podeis ayudar porque no se que hacerle mas. Gracias por adelantando!!
CREATE:
global.d <<--- esta variable calculada anteriormente en BEGIN_STEEP, me da como resultado 1 con la room_speed a 60 y 2 con la room_speed a 30 y 4 con room_speed a 15.
STEP:
//Mi propia gravedad controlada por pixeles/step sin usar la de game maker
if place_free(x,y+1) {vspeed+=.4*(global.d)}
//El asqueroso salto jajaja
if !place_free(x,(y+1)) and keyboard_check_pressed(vk_up) {vspeed=-8*(global.d)};
Acaba de leerlo otra vez mi post y la pregunta vendria a ser que porque al cambiar la velocidad de la room el vspeed no se mantiene igual? Porque si la habitacion es con menor velocidad el salto es mayor y si le duplico la velocidad el salto es menor, creo que hay que multiplicar algo al vspeed pero no saco el que...
Que le estas indicando al GM cuando pones lo siguiente:
vspeed = -8
Bueno, que mueva la instancia 8 pixeles hacia arriba y el GM movera esa instancia un pixel por step hasta llegar a -8.
Y con esto
{vspeed=-8*(global.d)};
Bueno si el room_speed es 60, entonces el resultado de la expresion -8*(global.d) seria -16, por tanto el GM movera la instancia -16 pixeles hacia arriba, y lo hara un pixel por step.
Ahora lo que tu codigo hace es aumentar LA DISTANCIA del salto dependiendo el room_speed, y no la velocidad del salto.
Y aunque vspeed nos supondria como la velocidad vertical en realidad indica una distancia y el tiempo que le tome a la instancia en recorrer esta distancia depende del room_speed, porque entre mas alto sea el valor del room_speed mas cantidad de steps por cada segundo habra y recuerda que vspeed mueve la instancia un pixel por step hasta llegar al valor indicado.
Claro lo que dices lo entiendo perfectamente ahora, tienes toda la razon. Pero mi pregunta es, como le saco la formula para que funcione entonces? Porque no se que le tengo que hacer para que recorra los mismos pixeles en un tiempo menor si depende por cada step, por mucho que lo cambie si depende por steeps me sera imposible no?
Tambien he probado una alarm que sume a una variable +1 y que dependa del delta_time el salto de la alarma, le digo que por cada 60steps/delta_time, asi funciona perfecta al tiempo de un delta time, pero si le digo a la room que sea de 30steps, empieza a ir bien, pero pasado un minuto hay un desfase bestial con el tiempo real del delta_time que va cuadrado al reloj de windows, si game maker es asi de impreciso, es muy facil hacer juego para dispositivos potentes, pero muy malo para harware antiguo ya que sin delta time no sera lo mismo un step en un galaxy s, que un galaxy s4, por ejemplo, pero si funcionara todo con delta_time ira a menos FPS pero el calculo sera real al tiempo, por eso es mi cabezoneria de intentar conseguir todo con deltatime. Saludetes, a ver si lo sacamos entre todos como usar bien el delta time que sera algo que lo agradeceremos todos sabiendo que ira en todos los dispositivos bien lo que hagamos.
Cita de: Ruben3D en Marzo 13, 2014, 09:06:16 PM
Tambien he probado una alarm que sume a una variable +1 y que dependa del delta_time el salto de la alarma, le digo que por cada 60steps/delta_time, asi funciona perfecta al tiempo de un delta time, pero si le digo a la room que sea de 30steps, empieza a ir bien, pero pasado un minuto hay un desfase bestial con el tiempo real del delta_time que va cuadrado al reloj de windows, si game maker es asi de impreciso, es muy facil hacer juego para dispositivos potentes, pero muy malo para harware antiguo
Sólo como sugerencia, deberías reconsiderar el uso de delta time. Game Maker no está pensado para funcionar (de manera óptima ) usando delta timing. Como lo veo yo, usar delta time acarrea más contras de los pros que ofrece.
Las alarmas ya no van a funcionar de manera exacta. El tiempo delta trabaja con valores no enteros, las alarmas no soportan eso.
Cada variable relacionada con velocidad o tiempo tiene que estar expresada en relacion al tiempo delta
Las colisiones pueden "buguearse"
Ya no se pueden usar variables como gravity, vspeed, hspeed, direction, image_speed, todo habría que ajustarlo al tiempo delta, incluído la manera como mueves las views o fondos.
Los paths ya no se pueden usar como antes, se tiene que modificar su comportamiento para adaptarlo al tiempo delta
Problemas con las lineas de tiempo, puede que haya acciones que no se ejecuten o que se ejecuten en momentos que no deberían.
El teclado y el ratón se leen a intervalos de tiempo irregulares, y se leen menos veces por segundo, esto les resta respuesta y hasta podría afectar la jugabilidad.
Entre otros. Muchos usuarios prefieren usar frame skipping en lugar de delta time.
Otra vez totalmente de acuerdo contigo, mire el como esta hecho y pense lo mismo pero con tus palabras ya me has acabado de decidir. Opte por el frameSkip, vi ejempos por el foro pero no se exacamente como decirle cuando ha de saltar, no se cuando es el momento de que tiene que salta 1 frames a X FPS, o sea cual sera el correcto uso del frameSkip, te explican como hacerlo no cuando usarlo, si me lo aclararas tambien te lo agradecira, y merci por toda la ayuda que me estas dando, eres un crack! ;)
Bueno he sacado un codigo de otro foro y ponian esto y la verdad es que funciona, pero me gustaria que me ayudarais a entender este codigo, ponen el ++ antes de la variable no lo habia visto nunca, a ver si me ayudais a entenderlo porque no me gusta copiar y pegar sin saber que hace.
FrameSkip
-------------
create:
_doDraw = true;
_frameskip = 0;
step:
if (_doDraw < _frameskip) { ++_doDraw; } else { _doDraw = 0; } draw_enable_drawevent(_doDraw == 0);
Yo lo que entiendo es _doDraw es menor que _frameskip --> y a partir de hay ya me he perdido jejjejeje aun me falta mucho rodaje en programacion xDDDD
++ o_draw
es lo mismo que:
o_draw += 1
Osea incrementar la variable o_draw en 1.
Por tanto...
if (_doDraw < _frameskip) { ++_doDraw; } else { _doDraw = 0; }
seria:
-Si _doDraw es menor que _frameskip entonces a _doDraw se le incrementara 1 al valor que tenga en ese momento, sino _doDraw sera 0.
_doDraw es una variable booleana, osea que solo puede ser false o true, y en el GM toda variable que tenga un valor mayor a 0.1 sera considera true y toda variable con un valor de 0 sera considerada false.
Lo que entiendo del codigo es que el evento Draw sera permitido solo si la variable _doDraw tenga valor de 0, osea que sea false.
draw_enable_drawevent(_doDraw == 0);
Perfecto ahora lo he entendido todo perfecto!! muuuuuchas gracias, igualmente he hecho lo del frameSkip con un ejemplo del glosario del GMStudio que hacen un bucle if que cuando los frames skip que queremos en una division como resultado sea 0, actue ese frame como skip, la verdad que estaba muy bien pensando, no habia usado nunca, "mod" en game maker.
Otra cosa que me pasaba era que al calcular los FPS siempre da 0 hasta que pasa 60steeps, entonces empieza a calcular los FPS, hay alguna manera que solo arrancar la room ya calcule los FPS? Vampy, siento preguntarte tanto pero es que eres el unico que me ha hechado un cable con estas preguntas y veo que estas muy puesto en el tema, saludetes tiu!! ;)
El ejemplo que mencionas del manual del GM yo tambien lo vi. Considero que deberias desarrollar tu frameskiping apartir de ese código, es mas sencillo de leer que el que haz posteado aquí por consuguiente mas facil de modificar.
Ahora, se ha que te refieres con tu pregunta, es mas cuando se usa el debugger se aprecia claramente que cuando el GM inicia o entra en un room, los steps bajan hasta casi 0, afectando los fps. La unica posible solucion que pienso es la de usar una alarma. Esta alarma iniciaria con el frameskiping o crea el objeto que controla el frameskiping dandole oportunidad al GM a que "tome velocidad".
Aunque no se si sera la mejor manera, dado que hay calcular "a mano" esta alarma.
La otra forma seria iniciar con el frameskiping en el Evento Room Start del objeto que controla el frameskiping.
He probado lo que me has dicho y no funciona, solo esperar unos 2 segundos con una alarma y actualizar, entonces le digo que si es menos de 55 descarte 2 frames, pero sinceramente a 55fps el juego se ve muy fluido y es una pena el como va, no me acaba de convencer 100% lo del frame/skip.
He leido tambien que el juego al compilar el apk final con YYC Android su performance es x2, o sea que en las pruebas con mi galaxy S1 que ahora oscila entre 55 y 58fps, supongo que al ompilar con YYC estara todo el rato a 60fps estables, no lo se la verdad... es un fastidio no poder probar estas cosas ni los Admob hasta comprar el modulo y no es barato que digamos jejeje me gustaria saber tu opinion vampy, saludetes! ;)
Lo que creo que vayas a lograr con el frameskip va ha ser minimo. En mi opinion el frameskiping es válido si tu juego va ser ha un multiplayer online.
Tienes razon, un juego compilado siempre va ha correr un poco mas rápido que cuando lo corremos dentro del GM y es algo a tomar en cuenta.
En mi opinión, es mejor tratar de crear tu juego de tal manera que al GM le "quede mas fácil" y de este forma evitamos bajonazos en el perfomance del juego.
En los link encontraras algunos consejos de como optimizar tus juegos cuando usas GM
http://www.yoyogames.com/tech_blog/30 (http://www.yoyogames.com/tech_blog/30)
http://forums.tigsource.com/index.php?PHPSESSID=027da815826a51caca152485666d2151&topic=3747.0 (http://forums.tigsource.com/index.php?PHPSESSID=027da815826a51caca152485666d2151&topic=3747.0)
Saludos!
amigo yo nunca he usado eso de delta time o las otras cosas!!!
pero en mi juego como te dije antes lo he instalado en toda clase de dispositivos y en todos tiene la misma velocidad
osea siempre va a 30 nunca he visto que sea mas lerdo o mas rapido!!!
Muchas gracias vampy me mirare los links! ;)
Ocarina una pregunta, a mi lo que me pasa es que si pongo room_speed 30, o sea 30 steps como logica se me queda en 30fps, pero no entiendo porque se ve tan poco fluido el juego cuando en verdad a 30fps ya deberia verse mas fluido y mas rapido, es todo como lento, lo que no se si una SNES iban a 50fps o 60fps dependiendo de los Hz de la TV y por tanto serian unos 50 o 60 steps, es lo que no me queda tampoco claro...
Edito--> Al final lo dejo a 60 steps, no me complico mas jeje saludos! ;)