[Tachikomaia]

¿Y el problema es que si bajas el intervalo se ve mejor pero tarda más de lo que quieres?

No sé, lo siento.

En Flash suelo poner que algo se mueva +X pixeles por frame. Si aumento X se mueve más distancia, parece que se teletransportara en vez de andar. Si aumento el framerate (fps o algo parecido) se mueve más seguido.

Si aumento el fps va a tardar menos en llegar al objetivo.

En tu caso parece que funciona al revés, no sé por qué... Hay más imágenes por segundo, e imagino (no sé) más código ejecutado por segundo, pero el resultado es que tarda más, no parece tener sentido.

[Tachikomaia]

Intenté abrir una imagen en otra ventana para verlo más grande pero se descargó y se me abre con, no importa, el punto es que quizá te está fallando el cálculo por el tema de los decimales, aunque no sé bien por qué sería, pero fijate que el último te pone .9999...
No tengo algo para ver gifs lentamente. Al programar suele haber la opción de que el programa te muestre datos, en este caso la posición en cada imagen. Eso permitiría ver, creo, que se está moviendo menos de 65 m/s.

[manooooh]

Hola

Intenté abrir una imagen en otra ventana para verlo más grande pero se descargó y se me abre con, no importa, el punto es que quizá te está fallando el cálculo por el tema de los decimales, aunque no sé bien por qué sería, pero fijate que el último te pone .9999...
No tengo algo para ver gifs lentamente. Al programar suele haber la opción de que el programa te muestre datos, en este caso la posición en cada imagen. Eso permitiría ver, creo, que se está moviendo menos de 65 m/s.

Si quieres te paso los .mp4 para que puedas pausar.

Sobre los decimales, parece ser, sí. ¿Quieres que intente almacenar en una lista (tipo .txt) los resultados y sacamos conclusiones?

La otra que queda es cambiar el / 1000 por otro valor, digamos / 800 o algo así. Pero esto no sé si está bien (ya que sería una falla del programa, no de la programación) o si efectivamente no está bien el código y va otro número (que no sé cómo se calcula, por eso les pido ayuda, creo que Richard habló de la Escala. Se puede calcular la escala).

Saludos

[Richard R Richard]

Son bloques de programación para aprender a programar, y yo creo que te sobra la inteligencia para entenderlo.

Si pero tengo que aprender a entenderlo.... veamos esto es POO programacion orientada a objetos...  le veo lógica a lo que haces , pero no entiendo un par de cosas , que quizá para ti son obvias pero yo tengo que deducirlas y no estoy seguro...
 
¿Por qué tienes 2 relojes?.... No se puede usar uno solo... es decir no entiendo porque necesitas dos medidas de tiempo, si lo que haces se compara con el tiempo real , con un solo temporizador que dispare un evento cada 20 ms es suficiente.
Por otro lado  si lo que quieres otro reloj para representar un tiempo acumulado de movimiento puedes llevar un contador de eventos del temporizador y multiplicar el tiempo  entre eventos  que es 20ms por el valor del contador.

Mientras escribía esto veo que ya publicaste los 4 videos

Por "todo a la vez no se puede hacer" entiendo que ahora sostienes que lo que pretendo lograr con un intervalo menor no se puede ¿O sí?

Si se puede, pero creo que el problema viene por el  efecto de lo que dije en la primera frase de mi mensaje anterior. " El hardware te aporta retraso"  Si le pides al telefono que calcule muchas veces tarda en hacerlo y representarlo, eso genera un delay y en vez de que tarde 10 segundos  en atravezar la pantalla tarda mas cuantos  mas calculos le pides.

Casi seguro eso creo que se soluciona si usas un solo temporizador ...
 Dame un rato que me familiarice con la lógica , pero creo que todo lo puedes poner en el mismo evento temporizador.

Es decir cada 20ms haces un calculo,  de la posicion del chico.
- lo pones en texto,
- cambias el deslizador
-y la posicion del sprite, todo junto....

;e marea lo de los dos relojes ... explícamelo porque puede me equivoque

Por otro lado  como haces a setear
-la velocidad ,
-la posicion inicial
-la longitud que recorrerá

¿Lo escoges de un menú previo? ¿con un input o similar en tiempo de ejecución?

Más lo veo mas me convenzo que debes poner todo dentro del evento de temporizador de pantalla.
Sube el tiempo a 50ms  haces  menos cálculos y aún veras continuo el movimiento del sprite

[manooooh]

Hola

Si pero tengo que aprender a entenderlo.... veamos esto es POO programacion orientada a objetos...  le veo lógica a lo que haces , pero no entiendo un par de cosas , que quizá para ti son obvias pero yo tengo que deducirlas y no estoy seguro...
 
¿Porque tienes 2 relojes?.... No se puede usar uno solo... es decir no entiendo porque necesitas dos medidas de tiempo, si lo que haces se compara con el tiempo real , con un solo temporizador que dispare un evento cada 20 ms es suficiente.
Por otro lado  si lo que quieres otro reloj para representar un tiempo acumulado de movimiento puedes llevar un contador de eventos del temporizador y multiplicar el tiempo  entre eventos  que es 20ms por el valor del contador.


Mientras escribía esto veo que ya publicaste los 4 videos

Por "todo a la vez no se puede hacer" entiendo que ahora sostienes que lo que pretendo lograr con un intervalo menor no se puede ¿O sí?

Si se puede, pero creo queel prblema viene por el  efecto de lo que dije en la primera frase de mi mensaje anterior. Si le pides al telefono que calcule muchas veces tarea en hacerlo y representarlo, eso genera un delay y en vez de que tarde 10 segundos  en atravezar la pantalla tarada mas cuantos mas calculos le pides.


Casi seguro eso creo que se soluciona si usas un solo temporizador ...
 Dame un rato que me familiarice con la logica , ero creo que todo lo puedes poner en el mismo evento temporizador.


Es decir cada 20ms haces un calculo,  de la posicion del chico.
- lo pones en texto,
- cambias el deslizador
-y la posicion del sprite, todo junto....


 me marea lo de los dos relojes ... explicamelo porque puede me equivoque




Por otro lado  como haces a setear
-la velocidad ,
-la posicion inicial
-la longitud que recorrerá


Mas lo veo mas me convenzo que debes poner todo dentro del evento de temporizador de pantalla
 

El seteo de la velocidad se hace con el deslizador rojo y la posición del chico con el azul. El valor mínimo de la velocidad la seteé a -65 y la máxima a 65 (aunque pueden ser cualquieras). El de la posición lo seteé con programación: el mínimo 0 y el máximo se calcula como Ancho de pantalla - Ancho de SpriteImagen (ya que la x del personaje comienza en el borde izquierdo).

Sobre los 2 relojes:

Necesitamos 2 relojes (uno con intervalo 1 ms y el otro, como dije, lo ponemos a 20 ms) porque tenemos un botón de pausa y play. Si pusiéramos todo en un solo reloj no podríamos mover el personaje cuando está parado ya que la idea es establecer las condiciones (posición y velocidad) antes de darle play. Con 2 relojes podemos incluso moverlo mientras está en play (aunque no tiene realidad física, es una consecuencia de tener 2 relojes).

El RelojMRU se encarga de mover al personaje cada 20 ms y actualizar la posición del deslizador "posición" según su coordenada X.

El RelojPantalla se encarga de todo lo visual y por eso se actualiza cada 1 milésima: desde cambiar el texto de las etiquetas para visualizar los valores hasta actualizar la X del chico de acuerdo a la posición del deslizador "posición".

Por eso tenemos una doble relación: coordenada X del chico cambia posición del deslizador, y posición del deslizador cambia coordenada X del chico.

Saludos

Corregido

[Richard R Richard]

mmmh, ¿por qué cada 1 ms  ese reloj?...no es suficiente que este actualizado cada vez que el otro necesite sus datos.. prueba cambiar ese valor de 1ms a 20ms o bien ambos a 50 ms y chequea si se atrasa.
50ms son 20 fps y no deberías ver saltos

PD. Agrego: Estoy convencido en que se atrasa por hacer mas cálculos más que por un error en tu línea lógica de desarrollar los eventos.

[Tachikomaia]

Sobre los decimales, parece ser, sí. ¿Quieres que intente almacenar en una lista (tipo .txt) los resultados y sacamos conclusiones?

Esperemos a ver si Richard lo resuelve.

Te digo otra cosa:
Cuando en Flash dices a un objeto que se coloque en una posición con muchos decimales, parte del número se pierde. La solución es tener una variable que marque la posición, en vez de simplemente la posición. Al asignar la posición se usa la variable, entonces no se copia exacta pero cuando necesites hacer cálculos tienes la original, no la perdiste.
Digo, podría ser que en tu programa pase algo similar.

Ahora bien, si estás calculando la posición en base al tiempo, no creo que el problema sea por decimales, porque eso pasa si a una posición anterior, menor a la que debe ser, le vas sumando movimiento, pero vos creo que calculas desde 0, no usas la posición anterior para calcular, así que no debería darte problema...

[Richard R Richard]

Hola , reitero no se como funciona bien todavía , pero creo entender que el deslizador es independiente de tu movimiento, por lo  que puedes preguntar sobre si ha sido apretado el boton de play... en caso que no entonces puedes manipular la posicion con el deslizador, en caso que si dejas que el temporizador vaya cambiando la posición del deslizador, si así funciona, no necesitas dos relojes, si detienes  pones en cero el temporizador, o no lo pones en pantalla,  si le diste a play va corriendo, si lo deslizas intencionalmente,  cambiara la posicion, en vez de moverlo en 1 ms lo hara a los 20 ms y casi no notaras la diferencia...