Problemas com Datagram... MouseListener e repaint()

Puxa, ninguém se arriscou a responder a sua pergunta, eu vou tentar.

Separar o model do view é sempre bom. Vamos por partes…

1. Envio de mensagem.

Voce deveria usar uma outra Thread para enviar a sua mensagem. Ou usar um Channel (do pacote nio). Jamais usar a AWT Dispatcher (que é quem ouve o seu clique) para fazer tarefas pesadas.

2. Modelo.

Sua matriz deveria ser um objeto. Um objeto que tenha as suas responsabilidades, por exemplo, descobrir se uma posição dá pontos ou não, e se auto-atualizar:

public boolean isHit(int position);
public void updateAfterHit();

Voce pode, depois, ir melhorando o seu modelo: se a sua matriz é esparsa (poucos valores não-nulos), talvez seja melhor manter uma lista de… valores não-nulos! Se vc só tem, na matriz inteira, uma única posição não-nula? Por que você não guarda apenas ela?

public boolean isHit(int position) {
  if (position == mosca) return true;
  else return false;
}

Um java.util.HashSet pode ser um ótimo armazenador para posições não-nulas…

3. replicação de dados
   Em vez de mandar tudo a cada vez, vc pode mandar apenas as alterações. Por exemplo, a nova posição 1 e qual jogador acertou (podendo ser nenhum). Assim, se todos os clientes conhecem as regras, eles podem atualizar suas próprias matrizes.

4. repaint() e eventos.

Já começou bem chamando o repaint() em vez de inventar um jeito mirabolante. O repaint() deve ser chamado a partir da Thread que leu a mensagem, e por último, após fazer todas as atualizações no modelo. O que esse método faz é colocar o componente numa lista. De tempos em tempos, a AWT Thread lê esta lista e faz as operações necessárias para pintá-lo (chamando o paint(Graphics)).

Múltiplos repaints não interferem em nada. Se o objeto já está na lista de espera, ele não é colocado de novo. Só garanta que vc está chamando repaint no seu JPanel, pra ele não repintar tudo (sei lá, digamos, o JFrame inteiro).

5. Camada de comunicação, protocolo, etc.

Por que UDP? Vc sabe que o UDP não garante algumas coisas que o TCP garante, né? Pra começar:

i. Pacotes podem não chegar ao destino
ii. Pacotes podem chegar ao destino fora de ordem.

Se você precisa de confirmação, vc tem que elaborar seu próprio esquema de ACKs (aí é da sua matéria, meu!!). Pode ser que o seu programa trave porque o servidor não soube ler a mensagem (chegada fora de ordem) ou ela não chegou nunca. E vc tem que mandar de novo se vc não tolera perdas.

De modo geral, mensagens UDP muito grandes tendem a se perder. Se o seu datagrama é grande e contém o objeto inteiro serializado, é bom considerar as alternativas pra diminuir o tamanho dele. Agora imagina os Warcrafts da vida, que trabalham com a ordem de 500 a 1000 alterações por segundo, comunicação direta entre os clientes, tolerancia baixa a falhas e ainda têm que renderizar um monte de coisas!! : )

boa sorte!!

[]s

Ae dukkie…
Eu fiz alguns tunnings no programa e funfou legal…
Valeu pela ajuda, mas quando eu vi sua mensagem jah tinha apresentado o trab…
T+
Valew pela boa vontade!!!

Abraços