Olá.
Entendo que, pelo código original, traçamos linhas (superfícies das raquetes) sobre as quais são atribuídas as colisões. Dessa forma, eventualmente uma bola pode vir "por trás" das raquetes, colidindo com essa linha e com a borda vária vezes até que saia pelo outro lado ou, até mesmo, extrapolando o campo visual e indo para o "limbo"... Em qualquer caso, para ocorrer o bug, a bola já teria tocado o fundo primeiramente, o que configura um ponto.
Então, para evitar o rebote da bola e para não deixar de marcar o ponto, simplesmente escrevi o código prevendo que, no caso de a bola "vir por detrás das raquetes" (velocidade negativa para a raquete da direita e positiva para a raquete da esquerda), ele desconsideraria a colisão. Assim a bola segue seu rumo natural, sem desvios, e o ponto é marcado.
Acrescento que implementei um único código (função raquetada()) para as duas raquetes, baseados em condicionais (vários "e" para cada raquete e um "ou" para separar as raquetes). Os valores 17, 60, 583, etc. nas condições têm a ver com a espessura das minhas raquetes e com o afastamento delas das bordas da tela, logo são irrelevantes. Por fim, "somRaq" é a minha variável carregada com o som da "raquetada".
function raquetada() {
if (((xBola<17) && (yBola>(yraq1-raioBola)) && (yBola<(yraq1+60+raioBola)) && (xVeloc < 0)) || ((xBola>583) && (yBola>(yraq2-raioBola)) && (yBola<(yraq2+60+raioBola)) && (xVeloc > 0))) {
xVeloc *= -1;
somRaq.play();
}
}Como o código é simples e curto, não vejo problemas nessas escolhas. Mas e se fosse complexo e longo, esse grande número de condições atrasaria o processamento de alguma forma?
Obrigado.
