[Tachikomaia]

Cuando E es 1:
R es el valor que yo decido.
I es R/1000.

Cuando E es 2:
R original es dividida entre 1.01.
I es el valor anterior de I + el valor actual de R.

Cuando E es 3:
R original es dividida entre 1.01 de nuevo.
I es el valor anterior de I + el valor actual de R.

Lo que pude obtener de Chatbots es:
I = (E*(E+1)/2) * (R/1000)/1.01^(E-1))
pero está mal, de hecho con ella, entre menor sea T mayor es I, pero es al revés.

Con Deepseek conseguí esto:
I = \( R_0 \)*0,101*(1-(1,01)^(-E))
pero debido a posibles problemas con el código que uso no he podido hacerla funcionar bien. En excel parece bien. ¿Creen que está bien? ¿sirve para R negativo y 0 también?

[Richard R Richard]

Hola, lo que pusiste en números  en la imagen del Excel representa

Cuando E es 1:
R es el valor que yo decido.
I es R/1000.

Cuando E es 2:
R original es dividida entre 1.01.
I es el valor anterior de I + el valor actual de R/1000.

Cuando E es 3:
R original es dividida entre 1.01 de nuevo.
I es el valor anterior de I + el valor actual de R/1000.

Te has olvidado  de decir que hay que dividir  por 1000.

Lo que pude obtener de Chatbots es:
I = (E*(E+1)/2) * (R/1000)/1.01^(E-1))
pero está mal, de hecho con ella, entre menor sea T mayor es I, pero es al revés.

Con Deepseek conseguí esto:
I = \( R_0 \)*0,101*(1-(1,01)^(-E))
pero debido a posibles problemas con el código que uso no he podido hacerla funcionar bien. En excel parece bien.

Ninguna de las dos fórmulas representa lo que calculas con el Excel,  que dices esta bien

¿Creen que está bien? ¿sirve para R negativo y 0 también?

Lo que esta bien solo lo sabes tú,  es tu serie, solo puedo intentar  adivinar que es lo que quieres, por lo pronto,  deduzco que hiciste en Excel, tu verás si sirve.

Dado el número de ejecuciones $$E$$  y el valor que decides $$V$$, el valor de  $$R$$ es simple y directo

$$R_E=\dfrac{V}{1.01^{(E-1)}}$$

Pero $$I$$ es un sumatorio de todos los R previos dividido 1000

$$I=\sum\limits_{i=1}^E \dfrac{R_E}{1000}=\dfrac{V}{1000}\sum\limits_{i=1}^E \dfrac{1}{1.01^{(E-1)}}$$

Para que veas lo que estas haciendo  es

$$I_E=\dfrac{V}{1000}\left(1+\dfrac{1}{1.01}+\dfrac{1}{1.01^2}+\dfrac{1}{1.01^3}+...+\dfrac{1}{1.01^{(E-1)}}\right)$$

Osea estas fórmulas son simples y sencillas para obtenerse con 3 variables dentro de un bucle en un algoritmo, si lo que quieres  es programar.
$$V$$ puede ser negativo (todo será negativo) o cero pero con cero todo resulta cero pues siempre cada volor calculado es proporcional al valor escogido $$V$$.

[Tachikomaia]

Te has olvidado  de decir que hay que dividir  por 1000.

Correcto.

Ninguna de las dos fórmulas representa lo que calculas con el Excel,  que dices esta bien

¿Lo dices por las pequeñas diferencias?
Lo que puse es:
=$B$2*0,101*(1-(1,01)^(-A211))

Osea estas fórmulas son simples y sencillas para obtenerse con 3 variables dentro de un bucle en un algoritmo, si lo que quieres  es programar.

Pero no quiero un bucle sino una fórmula...

No puedo decir mucho más acerca de este tema, el programa me falla por otras cosas y estoy viendo eso. Por ejemplo deben ocurrir 448 ejecuciones en un caso, y un contador me dice que sólo ocurrieron 394.

Arreglé algunas cosas, quizá ahora la diferencia es porque el objeto es grande y entonces se detecta que llegó antes de que su centro llegue al punto calculado.

Pero el cálculo me sigue fallando y no creo que sea por eso.
MeteorRotation: 20
MeteorYSpeed: -2.03764304101357
ApuntandoX: 0
ApuntandoY: 20.5
DistanciaY: 525
TardanzaY: 258
DistanciaX: 0
MovimientoPorCurva: 1.86496243687857
MeteorXSpeed: -1.86496243687857
Frames: 238
MeteorX final: 253.816469056757

Ese final debería ser 400 más o menos.

Frames debería ser 258 para que el meteoro se surve a la derecha por más tiempo y así se acerque a x 400, pero a la velocidad conque se curva en esos últimos momentos, no creo que sea el problema.

MeteorXSpeed es como MovimientoPorCurva*-1, es la velocidad inicial que se calcula debe tener el meteoro para terminar en x 400.
En Excel me da que la rotación lo influyó 1.86496243687857 pixeles, así que el cálculo parece bien.
Claro que en vez de ser afectado por la rotación 258 veces fue 238, pero en Excel me da que la influencia así es 1,83082471, o sea casi lo mismo, no es ese el problema creo.

No sé qué pasa...

¿Dijiste que no podías ver videos en YT? ¿si subo uno al foro sí? De momento te muestro una imagen. Puse Rotación 30 y mira lo que pasa:

Cuando llega ahí arriba, debería ser al centro, o casi, pero como ves la diferencia es mucha.
¿Está mal esto?
MeteorXSpeed = DistanciaX/TardanzaY-MovimientoPorCurva;

Supongamos que debido a la curva, en 200 ejecuciones se moverá 50 pixeles. Eso no significa que la velocidad inicial deba ser -50, porque se aplicará 200 veces. ¿Puede ser que la fórmula sea
(DistanciaX-MovimientoPorCurva)/TardanzaY? Pruebo... Se va demasiado a la derecha ahora.
Pero me parece raro que en el programa la velocidad X resulte igual que el movimiento calculado*-1. Resulta 0 porque distancia x es 0, dividido tardanza es 0, y le resta el movimiento, eso lo entiendo. Pero eso lo debería dividir por, no, no sé, tendré que pensar casos y buscar la relación entre esos datos.

Acabo de hacerlo pero no le veo sentido y no quiero llenar el foro de cosas que parecen sin sentido así que lo dejo, lo siento.

[Richard R Richard]

Lo que puse es:
=$B$2*0,101*(1-(1,01)^(-A211))

En que celda has puesto  eso?
El Excel esta correcto  si o no?

Pero no quiero un bucle sino una fórmula...

Te entiendo pero antes que nada si mis fórmulas  de sumatorio  son correctas,  es decir hacen lo que pides que haga, yo solo conozco un valor límite en el n=infinito que es $$(V/1000)\pi^2 /6$$ ,pero los valores intermedios no tienen valores directos  por fórmulas.


Antes de contestar algo que te confunda, voy a leer otro hilos que has iniciado  con la trayectoria de las piezas del juego para entender bien de que va la cosa, por ahora supongo que es que la bola no viaja recta. Su trayectoria no es una parábola como alguien te había  sugerido, si eso es lo que intentas programar, pero ya te diré mejor cuando relea.


Yo videos de YouTube puedo ver, el tema es que debes dejarlos allí colgados para siempre,  para que el que a futuro el que siga el hilo, encuentre el video, si lo borras de YouTube,  el hilo queda trunco.

[Tachikomaia]

Espera unos días que te explico desde el principio y con videos.

[Tachikomaia]

Bueno Richard, te preparo una explicación desde 0.

Video:

Lo he subido al foro también, el formato es asf pero un programa que lea MP4 debería leerlo, hasta se le puede cambiar la extensión de asf a MP4 y no me ha dado problema:
https://foro.rinconmatematico.com/index.php?action=dlattach;topic=129751.0;attach=35607

Cuando el meteoro sale desde la nave naranja, o cuando la toca, se le asigna (medio al azar) una rotación hacia un lado u otro.

Y una velocidad (también) hacia arriba, hacia la nave azul.

Por ahora, quiero que en ese caso, cuando el meteoro vaya a tocar la nave azul, esté en el centro de la pantalla.

En el video se ve que el meteoro en esos casos hace cualquier cosa, a veces choca contra una pared porque va muy hacia un costado, otras va un poco al centro pero no suficiente, etc.

Eso es lo que quiero arreglar.

Por ejemplo, sabiendo que el meteoro debido a la rotación se moverá cierta cantidad de píxeles hacia la izquierda, hay que asignarle una velocidad X hacia la derecha para contrarrestar. ¿Cuánto se debe asignar, cómo se calcula? Es lo que quiero averiguar.

En cada frame, o ejecución del código, la velocidad X del meteoro es influída por su rotación así:
MeteorXSpeed = MeteorXSpeed+MeteorRotation/1000

Luego la rotación disminuye así:
MeteorRotation = MeteorRotation/1.01;

No sé si necesitas más que eso.

Los cálculos los intento así:

Calculo la distancia Y entre el meteoro y el lugar Y al que debe llegar:
DistanciaY = MeteorY-ApuntandoY;

Calculo cuántos frames o ejecuciones tardará en llegar hasta ese punto (o línea, es el eje X, en un punto de Y):
TardanzaY = Math.ceil(DistanciaY/-MeteorYSpeed);

La distancia X entre el meteoro y el lugar X al que debe llegar:
DistanciaX = ApuntandoX+400-MeteorX;
400 es la mitad x de la pantalla.

Cuánto se va a mover el meteoro debido a la rotación:
MovimientoPorCurva = MeteorRotation*0.101*(1-Math.pow(1.01, -TardanzaY));
Creo haber comprobado que esa fórmula está bien.

Finalmente: La velocidad X que el meteoro debe tener para que cuando llegue a la nave azul, esté en el medio de la pantalla:
MeteorXSpeed = DistanciaX/TardanzaY-MovimientoPorCurva;
Creo que esto es lo que está mal, lo que hace que el meteoro vaya demasiado a la izquierda, etc.

Si no es eso, no sé, quizá algún error de mi lenguaje, que maneja mal los decimales, pero no debería haber las diferencias abismales que hay.

Puedo asignar los valores que quieras para ir buscando el problema:
- Rotación inicial
- Velocidad Y inicial.
- Posición X inicial

Te pongo un ejemplo de salida de datos:
MeteorRotation: -10.80258038398
MeteorYSpeed: -1.48908506263471
ApuntandoX: 0
ApuntandoY: 20.5
DistanciaY: 525
TardanzaY: 353
DistanciaX: 0
MovimientoPorCurva: -1.05852163876754
MeteorXSpeed: 1.05852163876754
Frames: 323
MeteorX final: 494.210208441683
InfluenciaDeRotacion final: -1.04720298986347

La rotación fue poca, y cuando eso sucede no termina tan alejado de x 400, pero hay bastante diferencia entre 400 y 494.
Frames es la cantidad de frames o ejecuciones ocurridas. Es menor que tardanzaY, eso puede ser un problema, pero mi teoría es que como el meteoro es grande el choque con la nave azul se capta antes de que su centro llegue al punto calculado. Y yo no observo que por 20 frames más vaya a cambiar mucho, cuando llega arriba la velocidad X es casi 0.
InfluenciaDeRotacion final es lo que medí, con el programa, que la rotación influyó. O sea, hizo que el meteoro se mueva 1. algo hacia la izquierda. La diferencia con lo que calculé, MovimientoPorCurva, es mínima así que no debería haber problema.

Otra salida:
MeteorRotation: 39.6237854657805
MeteorYSpeed: -2.04296611856807
ApuntandoX: 0
ApuntandoY: 20.5
DistanciaY: 525
TardanzaY: 257
DistanciaX: 0
MovimientoPorCurva: 3.69177198746066
MeteorXSpeed: -3.69177198746066
Frames: 238
MeteorX final: 111.113794405423
InfluenciaDeRotacion final: 3.62721027605372

El meteoro terminó en x 111 en vez de 400.

¿Qué falla?

Luego de escribir esto tuve que salir, anduve pensándolo en el viaje y demás, y según eso la fórmula sería:
MeteorXSpeed = DistanciaX/TardanzaY-MovimientoPorCurva/TardanzaY;
¡Pero parece que funciona mal también! ¿entonces?

[Richard R Richard]

Bueno Richard, te preparo una explicación desde 0.

Video:

Si observas el video, cada vez que el azul toca al meteoro, este  acelera hacia la derecha sin razón aperente, así que yo buscaría en el código donde tienes el error,


o es el valor calculado de la aceleración a la derecha,
o el calculo de la posición en función de la velocidad y la aceleración.


Por otro lado , una vez que el meteoro toca al azul o al otro, la trayectoria queda fijada, solo tienes  que parametrizar que punto de la trayectoria dejaras ver a cada instante,
Si  la posición final queda dada por la sumatoria de lo que llamas influencia, no tienes otra forma que despejar para cada instante, es mucho mas fácil llevar un contador y la sumatoria , frame por frame  y representarlo,  Creo que tu quieres siempre adivinar a donde caerá el meteoro y eso es fácil , ejecutas el bucle una vez y tienes la posición final para llevar al azul a esa posición como tu quieras, mientras tanto repites el bucle posicion por posicion (frame a frame) y los haces coincidir el en frame que necesites.

[Tachikomaia]

Si observas el video, cada vez que el azul toca al meteoro, este  acelera hacia la derecha sin razón aperente, así que yo buscaría en el código donde tienes el error,

Es como un juego Pong, o Tenis para 2, se menciona que fue el 1er videojuego de la historia, también es como esto

la nave azul es un rival, claro que la pelota rebota ahí, por ahora al azar, no programé su puntería, el tema es cómo llega el meteoro a esa nave, no como rebota desde ahí.

Lo de adivinar a dónde irá es una posible mejora, pero tampoco es el tema.

El tema ya fue explicado, no sé qué más decirte, lo que se me ocurre ahora es que el juego sea mucho más lento y el meteoro se mueva mucho más rápido, o sea, por ejemplo sólo estará en 2 posiciones, recorre la distancia en 2 ejecuciones, pero las ejecuciones tardan mucho. De ese modo intentaré ver por qué falla. Pero me tomará tiempo.

[Tachikomaia]

Puse que la velocidad del meteoro sea alta, -100, o sea va muy rápido hacia arriba, pero también puse que el juego funcione muy lento, aunque eso no importa en lo que descubrí.
Resulta que estaba midiendo mal la influencia de la rotación.
Puse que la rotación sea 1000 sin disminución, por lo que es 1+2+3+4+5, es decir 15, pero miren los resultados:
MeteorRotation: 1000
MeteorYSpeed: -100
ApuntandoX: 0
ApuntandoY: 20.5
DistanciaY: 525
TardanzaY: 6
DistanciaX: 0
MeteorXSpeed: 0

InfluenciaDeRotacion: 1
Frames: 1
MeteorX: 401

InfluenciaDeRotacion: 2
Frames: 2
MeteorX: 403

InfluenciaDeRotacion: 3
Frames: 3
MeteorX: 406

InfluenciaDeRotacion: 4
Frames: 4
MeteorX: 410

InfluenciaDeRotacion: 5
Frames: 5
MeteorX: 415

Frames: 5
MeteorX final: 415
InfluenciaDeRotacion final: 5

Ah, no puse cambios en la velocidad X, es 0, así que la posición X del meteoro sólo es influída por la rotación, como ven termina en 415, significa que la rotación influyó 15, pero lo que medí que influyó fue sólo 5, medí mal, mido así:
InfluenciaDeRotacion = InfluenciaDeRotacion+MeteorRotation/1000;
Supongo que con eso mido lo que influye extra en cada frame, sin incluir lo que influye por lo de antes. En vez de ir sumando 1+2+3... sumo lo que aumentó cada vez, 1+1+1...
Supongo que debo sumar la velocidad X cada vez, restando la inicial ¿cada vez?

Seguiré probando...

[Richard R Richard]

Hola, es difícil  recomendarte , sin saber exactamente que es lo que quieres lograr.
Nunca lo confirmaste si una vez el de abajo golpea, quieres adivinar (anticipar) la posición de llegada para llevar el azul a pegar al meteoro.


1) Si las trayectorias  son rectas y no hay impacto  en las paredes laterales, sabes hacerlo?
2) Si las trayectorias  son rectas y  hay impacto  en las paredes laterales , sabes hacerlo?

3) Si las trayectorias  son curvas(parábolas) y no hay impacto  en las paredes , sabes hacerlo?

4) Si las trayectorias  son curvas y  hay impacto  en las paredes , sabes hacerlo?

Aceleración constante, o variable, ? En horizontal  o vertical  o ambas a la vez?

Lo que veo es que en cada frame calculas la posición siguiente  en base a la última calculada, no es un inconveniente,  pero tiene la suma de muchos errores  de precisión. 

Pero es posibles  que al momento  de impactar definir los parámetros  de la trayectoria y saber donde estará el meteoro en función del tiempo,  con cálculos simples primero  calculas cuanto tiempo tardará en llegar hasta arriba,  luego divides. ese tiempo por el tiempo entre frame y frame y tendrás cuantos frases debes calcular para ejecutar un loop qué vaya ilustrado cada posición,.

De ese modo conociendo la posición  inicial y final del deslizador o golpeador de arriba, puedes calcular la velocidad  qué lo llevar hasta el punto de impacto cuando arribe el meteoro, sabiendo  el número  de frases es fácil calcular su posición frame a frame.

Así  que lo difícil para mí no es recomendar como hacer el cálculo , sino te he dado solución ces porque  no deduzco  de tu código el tipo de curva que quieres, parábola, elíptica, hiperbolica,  exponencial etc.

Es decir, no es claro si lo que pretendes es simular una atracción hacia las paredes o una repulsión y a la vez si debe ser simétrico el efecto digamos que si esta cerca de la pared izquierda  sea atraído hacia la izquierda pero si esta cerca de la derecha ves atraído (acelera) hacia la derecha. O bien directamente la curva no depende de la posición  de las paredes laterales.


A cualquiera de las que describí se le puede  dar solución  el tema es que nos comentes cual esperas usar en el juego y no solo un código donde no sabemos como deducirlo , pues sepueden colar errores.