Todas as classes do Java 2D tem o método intersects. Com ele você pode testar se a bola bateu numa raquete, e então inverter o vetor de direção da bola. 
Eu acabei de fazer uma app em Java que falava tb de movimentaçoes na tela…é o um jogo em k se tem um heroi e varios monstros atrás dele…
tenho de fechar os monstros e movimentar eles atrás do heroi…
na verdade o segredo esta nas coordenadas…
na minha app por exempo para ver k o heroi estava morto era so ver se as coodenadas do monstro eram iguais a do heroi…
Fiz isso faz mais de um ano, não olhei o código para ver como está, mas é uma bolinha que rebate no frame e vc pode fazer o drag dela com o mouse.
Talvez não seja a melhor forma de fazer, mas é interessante.
http://www.guj.com.br/posts/list/48266.java
Até mais!
[quote=Alkamavo]Eu acabei de fazer uma app em Java que falava tb de movimentaçoes na tela…é o um jogo em k se tem um heroi e varios monstros atrás dele…
tenho de fechar os monstros e movimentar eles atrás do heroi…
na verdade o segredo esta nas coordenadas…
na minha app por exempo para ver k o heroi estava morto era so ver se as coodenadas do monstro eram iguais a do heroi…
[/quote]
Isso só funciona bem em ascii, ou em imagens muito pequenas, ou em aplicações baseadas em tiles. Para coisas maiores, é melhor usar um algoritmo de bounding box. Caso contrário, você verá uma imagem sobre a outra ou, numa movimentação maior, um passará pelo outro, sem colisão. O segundo caso é quando o herói está em 1,1 o monstro em 2,2 e ambos caminham um em direção ao outro. O monstro passa para 1,1 o herói para 2,2 e só depois é testada a colisão. Mas, dependendo do caso, essa técnica pode ser usada para paredes, mesmo em aplicações com movimentação vetorial.
O mais simples é o mesmo algoritmo do “intersects” do da classe Rectangle, também conhecido como AABB (Axis-Aligned Bounding Box). Ele leva também em consideração a largura e a altura das duas entidades que estão colidindo. A grande vantagem desse algoritmo é que ele é velocíssimo, já que basicamente é o teste de 4 pontos (ao invés só da coordenada).
Tem também o OBB (Oriented Bound Box), que leva em consideração a inclinação de uma figura em cada eixo. É um pouco mais lento, mas bem mais preciso.
Outros algoritmos famosos para o mesmo tipo de coisa é o BoundingSphere (que usa uma esfera, ou no caso de 2D uma elipse, no lugar de um retângulo) e alguns algoritmos de colisão de pixel (extremamente caros).
[quote=ViniGodoy][quote=Alkamavo]Eu acabei de fazer uma app em Java que falava tb de movimentaçoes na tela…é o um jogo em k se tem um heroi e varios monstros atrás dele…
tenho de fechar os monstros e movimentar eles atrás do heroi…
na verdade o segredo esta nas coordenadas…
na minha app por exempo para ver k o heroi estava morto era so ver se as coodenadas do monstro eram iguais a do heroi…
[/quote]
Isso só funciona bem em ascii, ou em imagens muito pequenas, ou em aplicações baseadas em tiles. Para coisas maiores, é melhor usar um algoritmo de bounding box. Caso contrário, você verá uma imagem sobre a outra ou, numa movimentação maior, um passará pelo outro, sem colisão. O segundo caso é quando o herói está em 1,1 o monstro em 2,2 e ambos caminham um em direção ao outro. O monstro passa para 1,1 o herói para 2,2 e só depois é testada a colisão. Mas, dependendo do caso, essa técnica pode ser usada para paredes, mesmo em aplicações com movimentação vetorial.
[/quote]
Tem razão kuanto a sobreposiçao( sao imagens pekenas o heroi e os Monstros) e a velocidade dos algoritmos…mas eu contornei este aspecto( O da sobreposição ) kuando ambos estao na mesma cordenada…o heroi é considerado morto…chamo metodo “hero.Hide()” ele desaparece do ecrã o monstro toma a posiçao dele…ja nao há sobreposição…
:oops: :oops: :oops: :oops:
É isso mesmo.
Preciso fazer uma app onde uma bola se movimenta na tela, rebatendo nos cantos dela e em possíveis outros retângulos em seu caminho.
Não tive problemas com a determinação da posição da bola e com a velocidade, mas o problema é fazer a reação ao choque
Foi mal, foi mal mesmo. Só deois de eu ter postado a mesagem eu percebi que na verdade a maior parte do problema que eu imaginava ter não existe!
Na verdade, o colega ViniGodoy está certo: eu preciso apenas me preocupar se houve um impacto (usando o método intersect(), que toda subclasse de Shape tem) para decobrir quando houve batida e fazendo algumas comparações simples para descobrir de que lado o choque ocorreu. (E o pior é que até disso eu já sabia! :lol: )
Essas comparações feitas caso intercept() retorne true não passam das seguintes:
[list] Comparar a componente X ( um simples int [ou será double?] ) da bola com a componente X do outro objeto (aquele usado no método intercept() ). Se forem iguais então a batida foi na esuerda ou direita da bola. Basta, aí, inverter o componente X da velocidade.[/list]
[list]Fazer algo análogo com a componente Y. Se forem iguais, então houve uma batida em cima da bola - aí basta inverter a componente Y da velocidade.
[/list]
(Componentes da velocidade são inteiros que eu uso para incrementar/decrementar a location da bola cada vez que o método repaint() da janela é chamado).
Claro que, quando eu digo “testar se são iguais” cabe aí um cuidado: esses componentes X e Y são de um Point localizado no canto superior esquerdo do Shape (se eu não me engano). Assim, se eu quero evitar que minha “esfera plana” entre num retângulo, por exemplo, devo testar o Y dela com o Y+altura do retângulo - nesse caso a bola estará batendo embaixo dele; do mesmo jeito, devo testar o Y+altura da bola com o Y do retângulo para saber se ela está batendo em cima dele. Algo semelhante faço com o X e a largura para descobrir choques na esquerda ou na direita.
Se eu estiver errado em algum detalhe, me corrijam!
Mesmo já tendo a solução, deixo a postagem aqui para quem estiver buscando uma resposta para problemas parecidos.
Agradeço ao colega pela resposta.
Valeu!