Como faço para saber se dois quadrados na tela se colidiram?
Bills,
Não é tão simples assim. Existe toda uma lógica.
Quer aprender a fazer jogos? Dá uma olhada no Slick2D. Tem também o PontoV
Falowz!
Nao sei responder, mas tambem fiquei curioso e fui atras dar uma olhada.
Sei que é não é uma coisa fácil, mas seria legal alguem explicar (provavelmente alguem que programa pra jogos) como é a lógica para eu poder entender de uma forma bem grotesca, apenas pra ter uma noção.
funciona através de Matrizes XY? Se alguma dessas posicoes XY de um outro objeto estiver com uma parte dentro destas outras matrizes faz a colisao?
Fica num while pra verificar isso?
Ou… “ha, tem frameworks prontos, exige mta matematica, usa eles e seja feliz”
Bills, a sua dúvida é referente a programação J2ME?
Se for eu posso te ajudar!
O Slick2D tem uma parte que ajuda bastante a parte de colisões…
Se lembro direito, você faz uma verificação simples, if quadrado1.intercepts(quadrado2)
Mas os dois tem que estender uma classe…
Agora, se for fazer na mão (já fiz uma vez), aí é osso. Tem que saber onde está exatamente o quadrado1 e o quadrado2 e verificar os quatro pontos deles. Se um desses pontos do 1 estiver na parte do 2 (aí a lógica é sua!), então colidiu.
Falando é bem simples… faz um arkanoid pra você sentir.
Tenso.
Segue o exemplo de um jogo que estou fazendo…
int quadX=0, quadY=0;
// desenha um quadrado
g.fillRect(quadX, quadY,20,20); // os parametros respectivamente significam: posição X, posição Y, tamanho X, tamanho Y OBS) Em canvas a "unidade de medidas" é pixels
int bolaX=50, bolaY=50;
// desenha uma bola
g.fillArc(bolaX,bolaY,10,10,0,360); // os parametros respectivamente significam: posição X, posição Y, tamanho X, tamanho Y, inicio do desenho do cículo, fim do desenho do circulo
// TESTANDO COLISÃO
if((bolaX>=quadX-10)&&(bolax<=quadX+20)&&(bolaY>=quadY-10)&&(bolaY<=quadY+20)){
g.drawString("BOOM!");
}
espero que tenha ajudado!
Ah josue1912, aí não vale!
mostrou de onde sai o coelho da cartola! heheheheh
Opa, estou me intrometendo…
No ano passado nas aulas de Delphi nos fizemos um joguinho de sapos que comem moscas, haushaush
mas enfim, utilizamos o design patterns Observer, dá uma pesquisada a respeito por ele, se tiver interesse, hehe…
Obs: estamos utilizando orientação a objetos no Delphi, o que é bem raro de se ver, haushaush
[quote=jaboot]Ah josue1912, aí não vale!
mostrou de onde sai o coelho da cartola! heheheheh[/quote]
O objetivo do forum não é nos ajudarmos?!
Um listener cairia bem aí
creio que não há nem dúvidas disso
:shock:
O listener é mais ou menos o padrão do Observer, é a ideia de observar o que aconte, por exemplo, com a posição de um objeto.
é mais ou menos um Observer nao, Listener é um observer!
Listener = Ouvir, Observer = Observar…
haushaush, não podia perder o trocadilho, hehe =)
Mas enfim, peço desculpas, o amigo ai de cima está correto…
Existem diversos algoritmos para detecção de colisão. Alguns são mais simples, outros mais complexos. Tudo depende da qualidade da detecção e do tempo de resposta.
Os algorítmos mais simples, rápidos e conhecidos são os de axis-aligned bounding box (AABB) e bounding sphere. O AABB assume que em torno dos objetos existem quadrados, alinhados aos eixos (ou seja, os quadrados não giram se o objeto girar). O teste de colisão com bounding box é muito simples. Basicamente, testa-se se o quadrado não está fora da área de colisão, ou seja, o quadrado A poderia estar depois do quadrado B (a.x1 > b.x2), antes (a.x2 < b.x1) ou, usando a mesma lógica para o y, acima ou abaixo (caso seja 3D, usa-se a mesma lógica para o z para testar se está à frente ou atrás). É isso que a classe Rectangle2D, indicada pelo pessoal faz.
Caso nenhuma dessas situações se verifique, os objetos colidem entre si.
A bouding sphere (ou bounding circle, se for 2D) considera que objetos tem em torno de si áreas circulares. O teste de colisão nesse caso é bastante simples. A distância entre os centros do objeto (obtida subtraindo seus vetores de posição) deve ser menor que a soma dos raios das esferas para que exista colisão. É o teste ideal para colisão de bolas entre si.
Existe também uma série de algoritmos mais caros, para garantir mais precisão. Em 2D, é comum usar colisão por pixel. Testa-se pixel a pixel se áreas não transparentes da imagem colidiram. É um método muito preciso. Outra possibilidade é a colisão de polígonos convexos. Há algoritmos clássicos para isso, mas seu custo aumenta a medida que o número de lados dos polígonos aumenta também.
Normalmente, usa-se uma combinação das duas estratégias (cara e barata) para se detectar colisão. A fase que lida com a separação do espaço de colisão (geralmente através de quad ou octrees) e testes baratos é geralmente chamada de Broad Phase, enquanto a fase que testa com os algorítmos caros é chamada de Narrow Phase.
Existem também algoritmos especializados para objetos que se movem muito rápido (bullets). O que pode ocorrer em objetos assim, é que eles "atravessem" outros entre 2 etapas do game loop, já que o salto de pixels para seu movimento pode ser muito grande. Esse efeito é conhecido como tunelling, descrito pela imagem abaixo:
Para evitar o tunelling, é possível usar algoritmos de ray tracing, ou de interseção de segmentos de reta, geralmente a partir das extremidades e do centro do objeto que se move, e por toda trajetória de onde ele se moveu. Outra possibilidade é dividir o módulo de física em iterações menores, processadas de maneira seguida.
Engines de física como a Box2D e Bullet Physics implementam praticamente todas essas técnicas.