[Resolvido] Torricceli (Capítulo 2/2)

E então, gostou do primeiro capítulo? Entusiasmado para ler o segundo? Vamos lá.

No primeiro capítulo, concluímos que a equação de torricceli FUNCIONA em programação, desde que você coloque, ao atualizar a posição:

Código:

s += v + a/2;
v += a;

onde s=posição, v=velocidade e a=aceleração. Meu erro era usar, no step:

Código:

s += v;
v +=a

Nesse capítulo, que também é uma pergunta, e não um tutorial, vamos aplicar essa teoria no sistema de coordenadas do game maker. Primeiro, lançaremos um projétil com velocidade não-nula nos dois eixos e aplicaremos gravidade no eixo vertical. Segundo torricceli (que, não me canso de dizer, estava CERTO):

Torricceli escreveu:y = y0 + v0y*t + a/2*t²;
x = x0 + v0x*t

Onde y0 e x0 são a posição inicial, v0y e v0x são as velocidade iniciais nos eixos y e x, e t é o tempo, em steps, igual nas duas equações. Vamos nos focar na primeira equação, por enquanto. Eu já sei que a segunda será dada em função do que acharmos aqui.

y = y0 + v0y*t + a/2*t²

Como meu propósito é lançar um projétil do de um ponto conhecido e fazer com que ele atinja outro ponto conhecido, y e y0 são conhecidos. A aceleração também é sempre um valor constante arbitrado, portanto, conhecida. Restam duas incógnitas: v0y e t. Eu poderia arbitrar o tempo, também e calcular v0 a partir daí:

y = y0 + v0y*t + a/2*t²
v0y*t = y - y0 - a/2*t²
v0y = (y - y0 - a/2*t²) / t

Teste pra ver, funciona que é uma beleza. Mas tem alguns problemas: nem sempre acerto o alvo do jeito que eu queria, ou seja, às vezes, quero acertar o alvo quando o projétil está descendo e acerto quando ele está subindo, tals. Tem uma sub-trama dessa novela, aqui, mas fica pra outro dia.
Então o negócio é arbitrar v0y e calcular o tempo, mas de cara sabemos que isso não vai dar certo. Pode ser que o valor arbitrado seja baixo demais ou alto demais.
Chega de enrolação: minha idéia é arbitrar o ápice da parábola. Pego o mais alto dos dois pontos, somo mais um pouquinho e defino que é pra acertar o alvo depois de passar pelo ápice. Encontro v0y, calculo o valor de t a partir daí, jogo na equação em "x" e todo mundo fica feliz.
Eu sei achar o valor do ápice usando derivadas. Se você tem outra forma de fazê-lo, fique à vontade.

y = y0 + v0y*t + a/2*t²

dy/dt=at + v0y
no ápice, dy/dt=0, então
t(m) = -v0y/a

ym = y0 + v0y(-v0y/a) + a/2*(-v0y/a)² => ym = y do ápice (y máximo ou mínimo)
0 = y0-ym - v0y²/a + (a/2)*(v0y²/a²)
-1/a*v0y² + 1/2a*v0y² + (y0-ym) = 0
(-1/2a)*v0y² + (y0-ym) = 0
v0y² = -(y0-ym)/(-1/2a)
v0y² = 2a*(y0-ym)
v0y = sqrt(2a*(y0-ym))

y1 = y0 + v0y*t1 + a/2*t1² => y1 = y final (posição a ser atingida)
a/2*t1² + v0y*t1 + (y0-y1) = 0

delta = b²-4ac; x = (-b+-sqrt(delta))/2a => equação de segundo grau (báskara)

delta = v0y² - 4*a/2*(y0-y1)
delta = v0y² - 2a*(y0-y1)
delta = sqrt(2a(y0 - ym))² - 2a(y0-y1)
delta = 2a(y0-ym) - 2a(y0-y1)
delta = 2a(y0-ym-y0+y1)
delta = 2a(y1-ym) olha que legal: se y1 = ym, delta é zero!

t = (-v0y +- sqrt(delta))/(2*(a/2))
t = (-v0y +- sqrt(delta))/a
"+" e "-" sqrt(delta)... Um significa acertar o ponto na trajetória ascendente e o outro, na trajetória descendente. Como quero acertar depois do ápice, uso o maior deles
t = max((-v0y + sqrt(delta))/a, (-v0y - sqrt(delta))/a)

e, finalmente,

v0x = (x1 - x0)/t

Fim!!!
Fim?
Peraí... o valor de v0y é uma raiz. Raízes não podem ser negativas. Tem caroço nesse angú...
Veja bem, eu quero somar um valor à posição em y e SUBIR na tela. Se esse valor não puder ser negativo, eu não poderei subir.
Então tem um erro nesse raciocínio. O pior é que nos testes (em que eu deixo a utilidade da equação de lado e coloco a gravidade virada pra cima), os números batem. (1)
Como, então, inverter os valores, de modo a aplicar essa teoria num projétil?

Além disso, filosofando um pouco e analisando a equação, se a aceleração for zero, a velocidade também será zero, independente da diferença entre y0 e ym. A aceleração ser zero deveria transformar a trajetória numa linha reta, não numa linha com inclinação=0.

(1) testei mais alguns valores aqui, parece que tem um furo aí, mesmo. Não bateu como esperado, mesmo com a gravidade pra cima. Aqui, os eventos que usei:
create

Código:

//entrada de dados
a = -.5;
y = 10; y0 = y; x = 10; x0 = x;
y1 = 150; x1 = 230;
ym = max(y0, y1) + 10;
tCounter = 0;

//cálculos
v0y = sqrt(2*a*(y0-ym));
vy = v0y;
delta = 2*a*(y1-ym);
t =  max((-v0y + sqrt(delta))/a, (-v0y - sqrt(delta))/a);
vx = (x1 - x) / t;

press space (pra dar tempo de pensar)

Código:

y += vy + a;
vy += a;
x += vx;

tCounter += 1;

Draw (pra não ter que usar debug)

Código:

draw_sprite(sprite_index, 0, x, y);
draw_line_color(0, ym, room_width, ym, c_white, c_white);
draw_line(0, y1, room_width, y1);
draw_line(x1, 0, x1, room_height);

var i;
i = 20;
draw_text(20, i, "v0y = "+string(v0y)); i+=20;
draw_text(20, i, "vy = "+string(vy)); i+=20;
draw_text(20, i, "y = "+string(y)); i+=20;
draw_text(20, i, "y1 = "+string(y1)); i+=20;
draw_text(20, i, "ym = "+string(ym)); i+=20;
draw_text(20, i, "vx = "+string(vx)); i+=20;
draw_text(20, i, "x = "+string(x)); i+=20;
draw_text(20, i, "x1 = "+string(x1)); i+=20;
draw_text(20, i, "t = "+string(t)); i+=20;
draw_text(20, i, "tCounter = "+string(tCounter)); i+=20;

Por isso acredito que seja calcular o vspeed de acordo com o hspeed.

Primeiro, vamos calcular o tempo de acordo com o hspeed, que já temos (se for num script, pode ser um argumento).

s= hspeed . t //distancia que o projetil percorre
s=dist_hor + v0 . t //distancia que o alvo percorre

hspeed . t = dist_hor + vo .t

Código:

t = dist_hor / (hspeed - v0)

Obs: dist_hor é a distância horizontal entre os dois objetos (projetil.x - alvo.x).

Descobrimos o tempo, já temos o hspeed.
Agora descobriremos o vspeed.

y = y0 + vspeed.t + gt²/2

Porém, se considerarmos que o y inicial é igual a 0 e o final também, temos que:

Código:

-gt/2 = vspeed

Temos todos os valores. Basta criar o projétil e atribuir sua velocidade em cada eixo.

Até mais!

Funciona, Pedrø, mas olhando apenas a equação no eixo Y, isso é como arbitrar o tempo. Note que se você NÃO considerar os valores de Y iguais a zero (o que não pode ser feito, já que eu quero o objeto subindo na tela e atingindo uma altura diferente da inicial), você chega na mesma equação que eu mencionei:

Pedrø escreveu:y = y0 + vspeed.t + gt²/2

equivale a

saim escreveu:y = y0 + v0y*t + a/2*t²
v0y*t = y - y0 - a/2*t²
v0y = (y - y0 - a/2*t²) / t

Que, como eu disse, funciona, mas não é o que eu estou buscando, porque gera bugs. Deixa eu me aprofundar um pouco mais, pra justificar que raio de bug é esse.
Pense em duas masks quadradas. Um personagem chega na beira de uma plataforma e se prepara para pular para outra, bem acima. Eu pego e uso essa equação e traço o movimento parabólico dele. Daí, na colisão com a próxima plataforma, ponho ele pra andar de novo.
Então o ponto inicial é (bbox_right, bbox_bottom) e o ponto final (vou chamar a instância a ser atingida de "alvo) é (alvo.bbox_left, alvo.bbox_top).
Só que essa equação faz com que ele acerte o alvo durante a ascenção acenção assenssão enquanto ele está subindo. Daí, a colisão ocorre de baixo pra cima, uns poucos steps antes do previsto. Isso dá pra mandar o computador ignorar e manter o movimento até o momento de atingir o alvo, mas já fica ruim. Mas, mesmo fazendo isso, o movimento pára bruscamente. Pra causar uma impressão de mais realismo, é importante pegar a colisão na trajetória descendente. Por isso eu quero garantir que o ápice da parábola ocorra antes da colisão. Uma vez feito isso, posso até ignorar outras colisões que o efeito geral não fica ruim.

Muito obrigado pela tentativa, mas eu procuro mesmo é uma forma de corrigir o que quer que esteja errado nessas minhas transformações.

Saim. Pesquisei um pouco e talvez tenha descoberto a solução. Você escolhe o hspeed, aí o resto é calculado.

É essa:

x = Vx.t (lembre que x é distância entre eles)
t = x/Vx (lembre que o alvo só move verticalmente)

y = Vy.t + gt²/2

Lembre que Vy é a velocidade inicial.
Lembre que y é o deslocamento vertical.

Como o alvo se move verticalmente (MU), vamos colocar isso na conta.

(Alvo_y - Player_y) + (Alvo_vspeed.t) = Vy.t + gt²/2

Código:

Vy = (Alvo_y-Player_y)/t + Alvo_vspeed - gt/2

Pronto. Vê se dá certo agora...
É tudo questão de adaptar.

Edit: Eu testei e deu certo.
Centralize a sprite com Y=0.

Até mais!

Pedrø... Essa é a mesma solução de antes. Repare que, renomeando as variáveis e brincando um pouco com números, chegamos à mesma equação:

v0y = (y - y0 - a/2*t²) / t

A diferença é que na minha equação, o alvo não se move verticalmente. Acho que isso foi um erro de interpretação do que eu falei. O meu alvo NÃO se move.
O problema é acertar o alvo quando o projétil está subindo. Eu NÃO quero acertar o alvo quando o projétil está subindo. Quero acertar quando ele está descendo. Pra isso, tenho que colocar o ápice da parábola ANTES do alvo.
Em resumo, meu objetivo é:
- definir a posição do ápice em função da posição dos pontos
- uma vez encontrado o ápice, achar o valor de v0
- em função da equação encontrada, definir o tempo necessário pra acertar o alvo em Y
- em função desse tempo, definir a velocidade em X

Não entendi muito bem.
O projétil está acertando o alvo quando sobe e quando desce?
Tem algum jeito de você ilustrar isso?

Até mais!

Vou fazer um desenho assim que chegar em casa, mas deixa eu tentar explicar com outras palavras, enquanto isso.
Eu quero acertar o alvo quando o projétil está descendo. O motivo disso é que acertar o alvo enquanto o projétil está subindo gera bugs. Necessariamente o projétil irá subir e, depois, descer.

Fazer isso com o jogo de cabeça pra baixo, está feito e mostrado no primeiro post (refiz aqui e os erros não voltaram a acontecer). É possível fazer com o jogo de cabeça pra baixo porque a velocidade inicial é calculada a partir de uma raiz, portanto TEM QUE SER positiva.

Deixando de lado a filosofia e forçando os números, acabei de conseguir espelhar o cálculo (vim postar por causa disso). Isso me permite calcular a velocidade usando um valor positivo e, depois de usar esse valor, multiplicar por -1. Seria um script mais ou menos assim:

Código:

var x0, y0, x1, y1, y1_, a, ymax, delta, t;
a = -grav; //"grav" é minha variável (positiva) pra gravidade.
//Essa é a primeira inversão de eixos
x0 = bbox_right; y0 = bbox_bottom; //ou argument0 e argument1
x1 = alvo. bbox_left; y1_ = alvo. bbox_top; //ou argument2 e argument3
y1 = 2 * y0 - y1_; //segunda inversão de eixos
//(espelha y1_ em relação a y0)
ymax = max(y1, y0) + 20; //pode substituir "20" por "argument4"
//como os eixos estão invertidos, tem que SOMAR uma constante

//de agora pra frente, os cálculos são como se o jogo
//estivesse de cabeça pra baixo
vsp = sqrt(2 * a * (y0 - ymax));
delta = 2 * a * (y1 - ymax);
t = max((- vsp + sqrt(delta))/a, (- vsp - sqrt(delta))/a);
hsp = (x1 - x0) / t;
//finalmente, reinverte a velocidade vertical,
//pra poder aplicar a gravidade positiva
vsp *= -1;

No step, coloco isso aqui, conforme definimos no primeiro capítulo da novela:

Código:

x += hsp;
y += vsp + grav / 2;

Isso funciona. Ainda tem umas aproximações pra levar em conta, na hora da colisão, mas matematicamente, funciona. Essas aproximações têm que ser levadas em conta quanto t não é um valor inteiro e, por isso, a colisão não acontece EXATAMENTE no ponto esperado. Quando t é inteiro, o ponto de colisão é perfeito. Então, já posso encerrar a novela e usar esse script.

Só que agora, vem a parte filosófica. Porque será que o cálculo de vsp (ou vspeed) vem como uma raiz? Teoricamente, a aceleração ser positiva ou negativa resulta numa parábola com a boca pra baixo ou pra cima, mas sempre resulta numa parábola.
Dessa forma, partir de um ponto com velocidade num sentido e aceleração no outro é sempre possível (lógico!).
Porque, então, está sendo impossível calcular uma velocidade negativa? Não é só programação, essas fórmulas são usadas na vida real, então tem um erro aí. Não sei qual é, mas tem.
Agora, se TEM o erro como eu CONSIGO calcular o movimento num sentido? Erros de raciocínio não deveriam resultar em números errados?

Simples meu amigo:
V=Vo+at(I)
Torricelli diz:
S=So+Vo*t+(a*t²)/2;(II)
Então t=(V-Vo)/a;
Substituindo em (II):
S=So+Vo(V-Vo)/a+(a*(V-Vo)²)/2a²
delta(S)=(VoV-Vo²)/a+(V²-2VVo+Vo²)/2a
Multiplicando tudo por 2a
2*a*delta(S)=2*Vo*V-2*Vo²+V²-2*V*Vo+Vo²
2*a*delta(S)=-Vo²+V²

Código:

V²=Vo²+2*a*delta(S).


É aquela formula que eu te falei.Pensei que vc já a conhecesse...
Quando se tir a raiz a velocidade pode ser tanto positiva quanto negativa.
Como a gravidade é positiva entá o V tem de ser negativo pois no inicio ela começa contrariando a gravidade!Independente do sentido que adotar não influencia alguma(Faça os testes!).
Mas veja que não é perfeita como eu te falei tem um problema:Quando a variação do y é zero!!Agora vc pode olhar o source se tiver entendido!!
Até mais colega!

É isso aí.
Quando você atira para cima (no Game Maker), a gravidade é considerada positiva. Mas se atirar para baixo, a gravidade deve ser negativa.

Y = Yo + Vo.t +- gt²/2

Considerando que o player esteja no ponto (30, 120) e o alvo no ponto (100, 20), fazemos assim:

Y = -100 (ou seja, a distância vertical entre eles)
Yo = 0

-100 = 0 + Vo.t + gt²/2 (a gravidade é positiva pois a velocidade vertical será negativa [o projétil vai subir e depois descer]).

Do contrário, se o alvo estivesse abaixo do player.

Y = 100
Yo = 0

100 = 0 + Vo.t - gt²/2 (subtraimos a gravidade, pois a velocidade vertical é positiva [o projétil desce e depois sobre]).

Resumo: sinal da gravidade é o contrário do sinal da velocidade vertical.

@Todos: Antes de qualquer coisa, gostaria de mostrar a seguinte imagem:

É isso que eu estou querendo. Sair do ponto (y0, t0) com a velocidade vertical v0 (e uma velocidade horizontal também, claro), passar pelo ponto (ym, tm), que é o ápice da parábola, e atingir o ponto (y1, t1).
E, claro, quero uma equação genérica, que eu possa aplicar em qualquer situação. Mesmo se eu não souber o sinal da aceleração. Há situações (raras, mas há) em que a aceleração é negativa.

@Hatzo enkiri:
De fato eu não me lembrava dessa equação.
De fato, quando se tira a raiz, o valor da velocidade pode tanto ser negativo quanto positivo que, elevado ao quadrado será positivo. Mas como, então, determinar com exatidão qual dos dois?
E você está fazendo um pouco de confusão. Ou no raciocínio, ou na hora de escrever.

Como a gravidade é positiva entá o V tem de ser negativo pois no inicio ela começa contrariando a gravidade!Independente do sentido que adotar não influencia alguma(Faça os testes!).

Veja bem: eu QUERO que ela contrarie a gravidade, mas isso não é obrigatório, pela matemática. Imagine-se no alto de um prédio, com um balão d'água na mão. Você quer acertar o saim, que está parado lá embaixo. Você até PODE jogar o balão pra cima, pra também pode jogá-lo com velocidade no mesmo sentido da gravidade. Não dá pra fazer isso se o saim estiver na cobertura do prédio ao lado, que é mais alto, mas no nosso problema, y1 pode ser mais alto OU mais baixo que y0. Então, a menos que se obrigue que a velocidade seja contrária à gravidade, não sabemos que bicho vai sair.
E... como vou saber, a partir da sua equação, o valor de V, pra achar V0?
PS: baixei sua engine, mas infelizmente o GM 8.0 só lê da versão 5.0 pra frente... Tem como me mandar os eventos de cada objeto, pra eu fazer uma versão 8.0? Tenho certeza que você já resolveu isso, mas não consigo ver como.

@Pedrø

Quando você atira para cima (no Game Maker), a gravidade é considerada positiva. Mas se atirar para baixo, a gravidade deve ser negativa.

De forma alguma. A gravidade é constante, não importa pra que lado você atire.
Até podemos inverter o sinal da gravidade nas equações, pro forçar a barra, que é o que você, eu e o Hatzo enkiri estamos fazendo.

@Todos, de novo:
Parece que, pra generalizar, vou ter que colocar um "if sign(grav)=1{ //código} else { //outro código}". E ainda prever a situação em que "grav = 0" (já que, de acordo com minha fórmula, a velocidade seria zero, nesse caso, o que sabemos que não é verdade). Afinal, em todos os casos, a velocidade vem sendo calculada com uma raiz.
De qualquer forma, fiquei empolgado com o sucesso da inversão de eixos. É uma idéia meio tosca, mas funciona. Já que estou em casa e tenho como upar imagens, uma figura que ilustra o que eu quero dizer:

Ih, errei qual v0 é espelhada...
Primeiro eu espelho o valor de y1, se a gravidade for positiva (como normalmente é), e calculo como atingir aquele ponto espelhado, como se eu não me importasse da parábola ficar com a boca virada pro lado errado. Daí, eu simplesmente inverto o sinal de v0 e não mexo no step event, que o projétil atingirá o alvo.

Bom, a menos que alguém tenha uma forma genérica de se resolver isso, independentemente do sinal da aceleração, vou me contentar com isso e declarar a novela como encerrada (até eu cismar de que eu quero aceleração na horizontal também ou um módulo conhecido da velocidade inicial, variando apenas a direção ou ambos).

Você até PODE jogar o balão pra cima, pra também pode jogá-lo com velocidade no mesmo sentido da gravidade.

Só que estamos falando de movimento parabólico.
Se você quiser atirar direto para cima ou para baixo, você simplesmente coloca a equação com os dois sinais iguais.

E... como vou saber, a partir da sua equação, o valor de V, pra achar V0?

V = 0, pois no final das contas, ele vai colidir com o saim e parar.

De forma alguma. A gravidade é constante, não importa pra que lado você atire.

Lembre-se que na verdade é aceleração. E como estamos trabalhando com vetores, temos os sinais de acordo com o sentido. Então a aceleração pode ser negativa, se estiver no sentido contrário da velocidade. E como a aceleração tem o valor da gravidade, usamos como negativa.

Agora eu pergunto, porque não saquei ao certo o que você quer saber, o que você quer saber sobre isso?

Até mais!

Pedrø escreveu:

Você até PODE jogar o balão pra cima, pra também pode jogá-lo com velocidade no mesmo sentido da gravidade.

Só que estamos falando de movimento parabólico.
Se você quiser atirar direto para cima ou para baixo, você simplesmente coloca a equação com os dois sinais iguais.

Foi isso que eu quis dizer. É possível, sim, atirar o projétil numa velocidade vertical com sentido igual ou da gravidade e acertar o alvo. O Hatzo enkiri tinha partido do pré-suposto que não era.

Pedrø escreveu:

E... como vou saber, a partir da sua equação, o valor de V, pra achar V0?

V = 0, pois no final das contas, ele vai colidir com o saim e parar.

Não de acordo com a equação. Ele vai parar porque eu vou dizer a ele pra fazer isso, novos elementos entram em campo. A equação é elaborada de forma a garantir a colisão, mas não de forma a reagir à colisão.

Pedrø escreveu:

De forma alguma. A gravidade é constante, não importa pra que lado você atire.

Lembre-se que na verdade é aceleração. E como estamos trabalhando com vetores, temos os sinais de acordo com o sentido. Então a aceleração pode ser negativa, se estiver no sentido contrário da velocidade. E como a aceleração tem o valor da gravidade, usamos como negativa.

Isso é uma simplificação pra ficar mais fácil lembrar da fórmula. O fato é que a equação é sempre a mesma: S=S0+v0t+a/2t². Se "a" é positivo ou negativo, isso não vem ao caso. A equação permanece verdadeira.

Pedrø escreveu:Agora eu pergunto, porque não saquei ao certo o que você quer saber, o que você quer saber sobre isso?

A princípio, eu queria lançar um projétil pra cima (ou seja: v0 sendo negativa) e acertar um alvo quando a trajetória fosse descendente. Isso eu já consegui, só que de um jeito tosco, tive que forçar a barra com os números, porque o cálculo da velocidade foi feito através de uma raiz.
Agora eu quero contornar essa limitação. Quero um script que faça isso: eu entro com a posição inicial, a final, a aceleração e uma diferença entre os pontos e o ápice. Daí o script calcula a velocidade horizontal e vertical pra acertar o alvo.
Quer dizer, isso eu até já consigo, mas com um switch:

Código:

switch(sign(aceleração)){
case 1: ...; break;
case 0; ...; break;
case -1; ... break;

Então não tem muito mais motivo pra esticar a conversa a não ser filosofia. PORQUE, afinal, não é possível que o cálculo da velocidade me retorne um valor negativo (já que a fórmula acaba em uma raiz), sendo que o valor procurado PODE ser negativo.
Além disso, porque que, dependendo dos valores de entrada, pode ser impossível chegar num valor real (já que chega-se numa raiz de número negativo)?

Acho que é possivel sim. Vamos ver o exemplo anterior que eu postei.

Distancia vertical = 0 + Vo.t + gt²/2

-100 = Vo.t + gt²/2

Supondo que a gravidade seja 1.

-100/t - t/2 = Vo

Logo chegamos a um valor negativo, pois o tempo é sempre positivo.
Basta descobrir o tempo com base na velocidade e distância horizontais.

Edit: Espero o capitulo 3.

Até mais!

É. Não tinha pensado nisso. Arbitramos o tempo e calculamos v0.

Velu, garoto!
Tópico resolvido!