Hola a todos,
Estoy trabajando en una parte de código en la que se deben ejecutan procesos cada "x milisegundos". Entre estos milisegundos, el código no debe detenerse, es decir, no es un Wait al uso, es simplemente un contador de milisegundos mientras van ocurriendo otras cosas.
He estado mirando la documentación oficial y veo que disponemos de la función time() (http://wiki.bennugd.org/index.php?title=Time), que devuelve el tiempo en segundos (según la documentación oficial es así) y la variable timer (http://wiki.bennugd.org/index.php?title=Timer). No logro entender correctamente como funciona timer y no se si me podría ayudar realmente para lo que quiero.
¿Alguien me podría aclarar este asunto a ver si puedo obtener el tiempo debidamente en milisegundos? :D
Gracias,
¿Seguro que quieres usar tiempo real? lo digo porque al principio me pasaba como a ti, venía del game maker donde le metía una variable de tiempo y a cada cierto tiempo pasaba algo en cuestión. Como al fin y al cabo (en ese tiempo) habia que picar codigo me pasé a bennu, hice la misma pregunta que tu (mas o menos) y me aconsejaron que usara un contador. No se si sabes como vá pero te lo explico una mijita
Despues del loop pones la variable a sumar:
var_tiempo ++;
luego cuando llegue a la cantidad deseada ejecuta la acción indicada, incluso reiniciarlo si quieres
Lo digo mas que ná por si hay algun pequeño fallo, el programa se regirá por el tiempo y puede que te dé un salto tremendo, de esta forma, con el contador, si hay algun fallo no habrá salto sino relentización del programa.
Con la struct global timer (http://wiki.bennugd.org/index.php?title=Timer) podés averiguar el tiempo que pasó en centésimas de segundo.
Lo de programar en base al tiempo es algo un poco complicado ya que no hay garantias en cuanto a que tu codigo se va a ejecutar tan rapido, o exactamente tan rapido como vos querés.
Lo que tenes que pensar es que las condiciones en lugar de ser "pasaron x milisegundos" deberian ser algo del estilo "pasaron al menos x milisegundos, pero pueden ser muchos más" y ese muchos mas depende de cosas externas que uno no tiene control (recursos del sistema, carga del sistema, sistema operativo, etc etc etc...). Y bueno, pensando las cosas de esta forma que te digo, queda en vos hacer los chequeos o cuestion que hagan falta para lograr lo que querés.
Usando la variable timer, podes medir el tiempo que haya pasado desde algun evento. Esto es pseudocodigo, pero deberia ser algo así:
timer[0] = 0; // punto inicial en el tiempo, reinicio el contador
loop
if ( timer[0] >= 1000 ) // la condicion no deberia ser nunca con ==
ejecutar_cada_segundo();
timer[0] = 0;
end
end
Quote from: Futu-block on November 03, 2017, 07:57:44 PM
¿Seguro que quieres usar tiempo real? lo digo porque al principio me pasaba como a ti, venía del game maker donde le metía una variable de tiempo y a cada cierto tiempo pasaba algo en cuestión. Como al fin y al cabo (en ese tiempo) habia que picar codigo me pasé a bennu, hice la misma pregunta que tu (mas o menos) y me aconsejaron que usara un contador. No se si sabes como vá pero te lo explico una mijita
Despues del loop pones la variable a sumar:
var_tiempo ++;
luego cuando llegue a la cantidad deseada ejecuta la acción indicada, incluso reiniciarlo si quieres
Lo digo mas que ná por si hay algun pequeño fallo, el programa se regirá por el tiempo y puede que te dé un salto tremendo, de esta forma, con el contador, si hay algun fallo no habrá salto sino relentización del programa.
Gracias por las respuestas chicos.
Con el tema de usar un bucle y un contador no lo veo del todo (quizás por mi conocimiento), por el siguiente hecho:
Quote"¿Y si el proceso donde se está ejecutando el bucle que hace el contador se bloquea por unos segundos por sobrecarga en el procesador y el contador también se realentiza?"
Y otra cosa
Quote¿Cómo se en ciclos de un bucle y contadores a cuánto tiempo equivale?
Los procesos no se ejecutan nunca al mismo segundo, puede existir alguna diferencia mínima que haga que la cantidad de tiempo ya no sea igual.
No estoy echando atrás tu idea, es que no se como equiparar el tiempo a contadores de un bucle y limitar "el tiempo" en ciclos de un bucle, cuando un bucle puede que no siempre se ejecute a la misma velocidad
¿O sí?Quote from: gecko on November 03, 2017, 08:23:18 PM
Con la struct global timer (http://wiki.bennugd.org/index.php?title=Timer) podés averiguar el tiempo que pasó en centésimas de segundo.
Lo de programar en base al tiempo es algo un poco complicado ya que no hay garantias en cuanto a que tu codigo se va a ejecutar tan rapido, o exactamente tan rapido como vos querés.
Lo que tenes que pensar es que las condiciones en lugar de ser "pasaron x milisegundos" deberian ser algo del estilo "pasaron al menos x milisegundos, pero pueden ser muchos más" y ese muchos mas depende de cosas externas que uno no tiene control (recursos del sistema, carga del sistema, sistema operativo, etc etc etc...). Y bueno, pensando las cosas de esta forma que te digo, queda en vos hacer los chequeos o cuestion que hagan falta para lograr lo que querés.
Usando la variable timer, podes medir el tiempo que haya pasado desde algun evento. Esto es pseudocodigo, pero deberia ser algo así:
timer[0] = 0; // punto inicial en el tiempo, reinicio el contador
loop
if ( timer[0] >= 1000 ) // la condicion no deberia ser nunca con ==
ejecutar_cada_segundo();
timer[0] = 0;
end
end
Entiendo lo que me dices pero, entonces si quiero ejecutar 2 procesos que deben ejecutarse entre ellos con una diferencia de 1'02 segundos ¿Cúal es la mejor vía?
si lo que buscas es precision de ejecucion exacta cada X milisegundos, no podras hacerlo en bennugd.
los procesos no son hilos/threads como tales, son simulados, asi si ejecutas un frame, para la siguiente ejecucion tienes que esperar que todos los demas procesos se ejecuten, y tambien el render de video y demas callbacks del motor.
si no tienes frame en la funcion/proceso, los otros procesos no se ejecutaran hasta que tu proceso ejecute un frame.
o sea, que si tu programa es lo suficientemente rapido, con ningun proceso que consuma mucho y ejecutandose en un equipo lo suficientemente rapido, podrias obtener lo que quieres, pero nadie puede asegurarte un heartbeat de X milisegundos
sin mencionar la granularidad de los timers del sistema operativo.
También tienes que tener en cuenta el retraso mínimo entre la ejecución de un frame y del siguiente.
Por ejemplo, a 60fps tienes un retraso mínimo de 16,66 ms entre cada ejecución (o frame) del engine.
Esto es menos problemático en un motor que no dependa de un número de frames fijo (si alcanzara 120fps, el retraso mínimo sería de 8ms) o que se ejecute de una forma que no dependa de los frames en pantalla (por ejemplo, 120 "ticks" del engine, 60 frames en pantalla).
Puesss...me habéis dejado como quien dice "con el culo torcido" xDDDD
La cosa es que estoy implementando un juego tipo dance dance revolution (https://www.youtube.com/watch?v=4tsDb3CeFp4) en donde las teclas hay que pulsarlas al ritmo de la música..
¿Alguna idea para lo que es el proceso de que las teclas aparezcan al ritmo de la música?
primero define la base, como resolucion y fps, despues create un reloj en pantalla y haz pruebas de rendimiento en varias maquinas con la musica/video rulando, si ves que todo marcha bien ya podrias empezar a mapear en el tiempo las teclas a pulsar
Si, es muy buena idea, primero de trabajar bien con el motor y luego ''decorarlo
Quote from: KeiDash on November 03, 2017, 08:30:30 PM
Quote"¿Y si el proceso donde se está ejecutando el bucle que hace el contador se bloquea por unos segundos por sobrecarga en el procesador y el contador también se realentiza?"
Es igual que una cinta de casete en un valkman con las pilas gastadas, la canción sigue sonando exactamente igual pero mas lento, ya tendra pilas nuevas y oirá a su ritmo
Quote from: KeiDash on November 03, 2017, 08:30:30 PM
Y otra cosa
Quote¿Cómo se en ciclos de un bucle y contadores a cuánto tiempo equivale?
Los procesos no se ejecutan nunca al mismo segundo, puede existir alguna diferencia mínima que haga que la cantidad de tiempo ya no sea igual.
Si pones un contador que se actualice cada frame (var_contador++; ) en ( set_fps(60,0); ) cada vez que la variable llegue a 60 pasará un segundo, igual te puedes guiar por eso, si sincronizas varios procesos con estas dos cosas, ya lo tienes
Pues chicos sinceramente muchas gracias por la ayuda, me habéis ayudado mucho.
Lo que haré será probar primero rendimiento a ver que tal y en base a eso pues veré como lo hago. Digo yo, que si el rendimiento es bueno en el juego, el uso de timer[0] o como dice Futu, usar cada frame (var_contador++; ) en ( set_fps(60,0); ) , debería ir medianamente bien ¿No?
Intetaré ir por ahí a ver, ya os iré comentado que tal va el avance!
Gracias chicos
Para hacer lo de la detección de pulsaciones se me ocurre que podrías hacer las preguntas con un rango de tiempo. En lugar de preguntar si pasaron "x milisegundos" deberías preguntar si el tiempo actual está entre "x e y milisegundos".
Y suponiendo que tu juego va a ir "a lo máximo" en 60 fps, sabes que el rango mínimo que deberías ponerle a una pulsación son 17ms, y mientras mas largo sea el rango de la pulsación, más jugable va a ser tu juego con maquinas en donde no llegue a los 60 fps.
Que no te asusten las respuestas, es algo que (a grandes rasgos) se puede hacer, pero no es tan fácil como uno lo imagina a simple vista.
Se puede controlar el rango de pulsación?
Te respondo en mi experiencia que usar timer en Bennu nunca es buena idea, y sin embargo, es imprescindible en otros lenguajes.
Antes de explicarte nada, te digo que en este foro hay gente partidaria de "timer", y gente de contadores. Cada uno tiene sus razones, pero yo soy de contadores.
Hace tiempo implementé un reloj de tiempo real en un jueguecillo llamado Liquid Counter (aun está para Wiz) usando los timer. Básicamente era una variable que sumaba el valor de timer(0) a cada frame (lo siento, no puedo poner corchetes sin que el foro se vuelva loco). Tras unos minutos vi que se retrasaba :S
Luego le metí un contador, y no es que sea exacto, pero apenas se desfasa algún segundo después de un día entero (y se refresca cada vez que arranca el juego).
El problema de los timers es que te dan el tiempo en milisegundos, pero nunca te dan el mismo valor. Por eso, tienes que trabajar con rangos de tiempo, y complican el tema matemático.
La pega de los contadores es, como bien preguntas, si el juego se ralentiza en algún momento, porque entonces el tiempo también lo hace. Pero yo lo prefiero así, porque el juego está sincronizado en todo momento, incluso las entradas de teclado (imagina que el juego se ralentiza y aunque pulses la tecla a tiempo, su respuesta se retrasa porque el código se ha "pausado" y hace las comprobaciones después de tiempo). Es más: imagina que estás jugando a Out Run, el juego se ralentiza porque hay muchos coches en pantalla o porque tienes el antivirus funcionando, pero el reloj es en tiempo real: significa que juegas con un coche más lento que el que fue programado.
Además, sabes que el tiempo que pasa es 1000ms/FPS (o sea, a 50FPS, cada frame son 20ms) con un margen de error inferior al 0'1%
Para un DDR, usar contadores es suficiente. Si habláramos de un FZero o algo de carreras o de velocidad... probablemente te diría lo mismo, y que calcules el momento exacto de cruzar la meta, usando la distancia de más recorrida tras la meta, y la velocidad del vehículo :D
Sin embargo, si trabajas con Unity, el uso del reloj del sistema es obligatorio, ya que los frames por segundo tienen un significado diferente: mientras Bennu trata de mantener una tasa de frames constantes (incluso metiendo tiempos muertos entre medias), y mantiene todos los procesos sincronizados en base a esa tasa de tiempos constantes, Unity intenta ir tan rápido como puede, y es el resto del sistema el que determina la velocidad de ejecución real. El tema de ejecutar "procesos" se hace de forma similar en ambos lenguajes (todos deben ejecutarse antes de pasar al siguiente frame... salvo las físicas en Unity, que van por su cuenta) pero es el tempo el que cambia.
Quote from: KeiDash on November 04, 2017, 10:27:07 AM
Puesss...me habéis dejado como quien dice "con el culo torcido" xDDDD
La cosa es que estoy implementando un juego tipo dance dance revolution (https://www.youtube.com/watch?v=4tsDb3CeFp4) en donde las teclas hay que pulsarlas al ritmo de la música..
¿Alguna idea para lo que es el proceso de que las teclas aparezcan al ritmo de la música?
pense que estabas implementando algo que requeria cuestionar algun dispositivo o algo cada X milisegundos... un dance no necesita demasiada precision... no creo que requiera granularidad de 10ms u 8ms... creo que te da tela tranquilamente...
ahora, con respecto a timers... timers, tu lo seteas a 0 y el sistema en cada frame va actualizandolos, segun pase el tiempo.
lo que sugiero es usar get_timer(), que es similar a time(), pero en milisegundos.
Pues yo vengo a contradeciros a todos y recomendarle que use timer.
En caso de que las FPS no sean estables, con timer no tendrá problemas pero con los contadores sí, teniendo en cuenta que la música no parará.
Quote from: panreyes on November 05, 2017, 10:55:17 AM
Pues yo vengo a contradeciros a todos y recomendarle que use timer.
En caso de que las FPS no sean estables, con timer no tendrá problemas pero con los contadores sí, teniendo en cuenta que la música no parará.
timer es una especie de contador, que se actualiza en cada frame... get_timer no depende de frame, es el valor en el momento...
Perdón la tardanza en responder al tema pero he estado liado estos días.
Al final de momento, lo que estoy haciendo lo hago con contadores en bucles, contando a razón de los fps, tal cual me comentó Futu y Dumpi, usando (var_contador++; ) en ( set_fps(60,0); ).
Espero mostrar algo con fundamento en cosa de un mes.
Saludos y gracias a todos!!
de nada
ansiosos nos hayamos de ver el resultado ;)
Lo cierto es que Panreyes ha sacado un punto importante: en este caso, la música NO se sincroniza con el resto del sistema. Al usar la librería de audio y tirar de tarjeta de sonido, una ralentización de la CPU podría provocar un desfase entre la música y el apartado visual, y un timer, o como dice Splinter, get_timer, te podría dar mayor estabilidad, siempre que tengas muy claro que no vas a trabajar con tiempos absolutos, sino posibles rangos.
En cambio, en la mayoría de los casos, como la velocidad de movimiento siempre se mide en pixels por frame, sí que es recomendable usar los contadores.
Eso me suena a hacer recortes de la cancion por trayectos para sincronizarlos...
A dia de hoy, un pc normal no debería dar problemas de relancización de ninguna manera, ¿no?
Es muy interesante todo esto que comentais la verdad, ahora mismo estoy en el punto de que tengo controlados los tiempos con contadores, y esta semana si sale todo bien, voy a añadir el audio a ver que tal se sincroniza.
La cosa es que estoy haciendo todo esto para Dreamcast, espero que rinda bien, de momento la carga no es grande en memoria así que por ese lado estoy tranquilo, ya me preocupa más como trabaje la librería en sí (mod_dream)
Futu, nunca sobreestimes las capacidades de un PC, que luego quieres portar tu juego a Wiz y te llevas una desagradable sorpresa :D
KeiDash: eso ya ni idea, mi experiencia con DC es muy limitada, pero si Wiz puede moverme "ese" proyecto, no veo por qué no un DDR (a menos que te hayas pasado con los VFX en el fondo :D)
¡Cáspita! es verdan
Buenas a todos,
Hace alrededor de dos meses que estoy trabajando con esto de "
el tiempo" y
crear una especie de cronómetro para poder trabajar con cantidades de tiempo de tipo Segundo, Décimas de segundo y centésimas de segundo.
Re-abro este post porque
necesito ayuda de los profesionales en este sentido, ya que me las estoy viendo y deseando para poder "
crear lo que quiero crear", expongo la base y luego el problema, a ver si alguien me puede dar otra vía para andar en este sentido o ver que desición tomo con el proyecto.
El juegoNo se si alguno lo conocéis, mi intención es la de crear BeatTendency, un juego musical al más puro estilo Beatmanía. Las características de este juego por si alguno la desconoce es la de que una música se reproduce y al ritmo de la música, el usuario debe presionar las teclas para acertar las notas musicales en
el momento preciso.
El momento preciso..¿Cómo que el momento preciso? ¿A qué me refiero y qué quiere decir esto?Esto quiere decir que,
la música, reproduce unas notas musicales que serán las que el usuario debe acertar, y estas notas musicales tienen un tiempo muy marcado y muy específico, es decir:
- La primera nota musical se reproduce en el segundo 7.44
- La segunda nota musical se reproduce en el segundo 9.23
- La tercera nota musical se reproduce en el segundo 11.12
- La tercera nota musical se reproduce en el segundo 11.15
Quizás tu primer pensamiento pueda ser
"hey..pero ¿Dónde está realmente el problema?"Problema Nº1 - El cálculo de unidades de tiempo menores al segundo en BennuGdEn BennuGD por lo que tengo entendido hay dos vías para obtener tiempo
A) función getTime(), ésta devuelve un número enorme (universal) que debes transformar con fórmulas matemáticas para obtener horas, minutos y segundos. Mi duda con esta función es ¿De dónde obtiene esta función el tiempo? ¿Del reloj interno de la consola?
B) Cálculo por frames. Mi juego en este caso corre continuamente a 60fps, por lo que decidí tomar esta vía para calcular el tiempo ¿Cómo? Pues si cada 60fps es 1 segundo, para calcular por ejemplo el caso del segundo 11.12 hago lo siguiente (pseudo código):
11.12segundos = (60 * 11)
désimas = (60 * (1 * 10) / 100)
centésimas = (60 * (2 * 100) / 100)
total = segundos + décimas + centésimas
Es decir, obtengo los ciclos que debe dar un bucle (60 vueltas de un bucle = 1Segundo) en base a un tiempo. El problema de esto es que no estoy seguro de que sea exacto, aunque lo he probado y es bastante aproximado.
¿Cuál es el problema entonces? Problema Nº2 - El retraso de los elementosA medida que se van mostrando notas musicales (hay un bucle que va dando vueltas y va preguntando a cada nota musical si le toca salir o no, en base a el tiempo en ciclos que se le ha asignado con la fórmula anterior) empieza a existir un retraso y las notas empiezan a descuadrar, aunque no se pierde velocidad de juego en ningún caso.
Este problema lo he resuelto manualmente, es decir, a cada tiempo asignado a las notas, lo arreglo dándole más o menos segundos a mano...un trabajo de chinos..
Y en esta tesitura me encuentro...no se como poder trabajar cómodamente ni se si la vía que he escogido es la correcta
ni se si lo que quiero es posible.Necesito vuestra ayuda ya que no se de otra solución para ello.Gracias de antemano.
time() son los segundos desde el 1 de enero de 1970
get_timer() son milisegundos desde que la aplicacion inicio
Quote from: SplinterGU on March 16, 2018, 11:56:39 AM
get_timer() son milisegundos desde que la aplicacion inicio
Representado por el reloj interno de la consola?
Creo que SlinterGU se refiere en PC.
O sea a ti me parece que no te serviría porque es desde cuando inicia el programa, si el usuario tarda x tiempo en dar a start, etc... creo que no puedes controlar ese tiempo.
Yo no tengo mucha idea, pero usaría contadores. Las pruebas que hice para controlar el loop de CDDA parecían tener mucha precisión como te había comentado creo Drumpi.
Seguro que pueden ayudarte con alguna otra idea o sugerencia algún otro compañero por aquí...
Ánimo!
Quote from: KeiDash on March 16, 2018, 01:14:38 PM
Quote from: SplinterGU on March 16, 2018, 11:56:39 AM
get_timer() son milisegundos desde que la aplicacion inicio
Representado por el reloj interno de la consola?
milisegundos son milisegundos... independientemente de lo que hagas o haga la consola o pc, o lo que sea... son milisegundos relativos a cuando se inicio el programa...
no entiendo tu pregunta...
Quote from: Ryo Suzuki on March 18, 2018, 08:51:17 PM
Creo que SlinterGU se refiere en PC.
O sea a ti me parece que no te serviría porque es desde cuando inicia el programa, si el usuario tarda x tiempo en dar a start, etc... creo que no puedes controlar ese tiempo.
Yo no tengo mucha idea, pero usaría contadores. Las pruebas que hice para controlar el loop de CDDA parecían tener mucha precisión como te había comentado creo Drumpi.
Seguro que pueden ayudarte con alguna otra idea o sugerencia algún otro compañero por aquí...
Ánimo!
no importa si pulsa start o no start, no depende de eso... es el tiempo en milisegundos desde que se inicio bennugd... no depende de nada, solo del paso del tiempo...
Quote from: SplinterGU on March 19, 2018, 02:20:38 AM
Quote from: KeiDash on March 16, 2018, 01:14:38 PM
Quote from: SplinterGU on March 16, 2018, 11:56:39 AM
get_timer() son milisegundos desde que la aplicacion inicio
Representado por el reloj interno de la consola?
milisegundos son milisegundos... independientemente de lo que hagas o haga la consola o pc, o lo que sea... son milisegundos relativos a cuando se inicio el programa...
no entiendo tu pregunta...
Bueno pensandolo ahora mi propia pregunta no tiene sentido, como bien dices, milisegundos son milisegundos.
He conseguido trabajar con get_timer() y es muy certero en tiempo (al 100%) aunque no se si es mi solución para mi juego, es decir:
Mi juego muestra algo en pantalla cada X milisegundos (un sprite supongamos), pero hay muchos sprites que mostrar. Cada sprite tiene su tiempo en milisegundos asignado, entonces lo que hago es consultar el tiempo el un bucle para saber en qué momento debe el sprite aparecer, me explico:
Process MostrarSprite(int milisegundos, int spriteId)
Private
int mytime = 0;
Begin
myTime = get_timer() + milisegundos;
Loop
if(get_timer() >= myTime) break; End
frame;
End
GRAPH = spriteId;
X = xpos;
Y = Ypos;
.
.
End
La cosa, problema o handicap es que, cuántos más sprites se empiezan a ver en pantalla, más lento empiezan a ir los procesos internamente y los sprites comienzan a tardar en salir...La verdad es que no se si esto tiene algún tipo de solución que pueda implementar
quizas te convendria tener un proceso controller, donde verifique una estructura con tiempo + sprite (puede ser id de proceso sprite), tengas luego los procesos con los sprites dormidos previamente, y cuando el proceso controlador encuentra que tiene que activar un sprite, le actualiza sus coordenadas y los pone en freeze... asi consumiria menos proceso, en teoria... hay que ver cuanto tarda la logica del controller... que ademas solo haria un get_timer por frame... y deberia quitar de la lista o considerar el estado (congelado, dormido, etc...) en la logica del controlador, para no activarlo nuevamente...
no se, de momento se me ocurre eso
Pues lo tendré en cuenta Splinter, gracias por tu ayuda!
Finalmente despues de muchas muchas pruebas, cálculos y formulas he llegado a la conclusión de que para calcular tu propio tiempo internamente en código o hacerte tu propio cronómetro, la mejor opción (y diría que única) es utilizar la función get_timer() como comenta SplinterGU, es muy precisa y da el tiempo perfectamente aunque desconozco internamente cómo funciona.
Al contrario que un bucle que recorra n ciclos ya sea controlado por los FPS o por una variable que se incremente, get_timer() da el tiempo justo y exacto (como el programa de la TV x'D) mientras que a través de un bucle siempre hay pérdidas, ya que el bucle funcionará a razón de la carga de trabajo del código, es decir, si el sistema se realentiza por lo que sea (mala codificación o una gran carga de datos en memoria) el bucle también se realentiza, dando tiempos impresisos y pérdidas de supuesto tiempo siempre. Ejemplo:
//60 ciclos de bucle = 1 segundo
For(i = 0; i < 60; i++)
i++;
End
Este bucle nunca empezará y terminará en el mismo momento. podría empezar en el segundo 0.00 y terminar en el 0.62, en vez de en el 0.60
Comento esto por si alguno se ve en el mismo dilema aunque muchos digan que "es que es normal que si usas bucles pase eso" y si, es normal, pero cuando necesitas de verdad controlar el tiempo milimétricamente (Segúndos, Désimas, Centésimas y Milésimas) esto no te va a ayudar en absoluto. Recordemos cómo empezó este post (http://forum.bennugd.org/index.php/topic,4618.msg72412.html#msg72412).
Saludos y gracias a todos por ayudarme en este post.
ponme un ejemplo, porque me parece curioso y creo que lo voy a usar para los programas ''demo'' que se cierre y empiece de nuevo cuando leve una hora abierto :D
(que mala idea tengo, lol)
para 1 hora no es necesario get_timer, con time() es suficiente...
Quote from: Futu-block on March 27, 2018, 03:38:50 PM
ponme un ejemplo, porque me parece curioso y creo que lo voy a usar para los programas ''demo'' que se cierre y empiece de nuevo cuando leve una hora abierto :D
(que mala idea tengo, lol)
Coincido en lo que dice SplinterGU, no lo veo muy enfocado a hacer algo con el durante una hora, a no ser que de alguna manera no estés consultando continuamente la función get_timer(). Pues un ejemplo sería algo así:
ftime = atof("60.000"); //Una hora
toWait = get_timer() + (ftime * 1000);
Repeat
frame;
Until(get_timer() >= towait)
Gracias, la verdad que no tengo ni idea de como se usa get_time()
Quote from: Futu-block on April 02, 2018, 08:34:48 PM
Gracias, la verdad que no tengo ni idea de como se usa get_time()
Pues es sencillo la verdad. La función al final lo que devuelve es el tiempo que pasa en milisegundos desde que se inició el programa. Devuelve un entero, que si lo multiplicas por 1000 (cálculo básico de tiempo) te da el tiempo en Milisegundos, por ejemplo:
Sin consutamos el tiempo en un momento concreto, supongamos que nos devuelve el valor entero 5000 (5000 / 1000 = 5 segundos)
Supongamos que pasan 3.056 segundos cuando volvemos a consultar get_timer(), la función debería devolvernos el valor entero 8056 (los 5000 de antes más los 3.056 segundos posteriores)