Escolar Documentos
Profissional Documentos
Cultura Documentos
Aqui é onde eu revistar muitas discussões (ou seja, argumentos) sobre o porquê do Java não
ser uma má escolha, para a programação de jogos. È possível que você já esteja convencido
das qualidades do Java, e este capítulo não lhe serão útil. Mas talvez ainda haja algumas
dúvidas.
Uma das minhas hipóteses é que o leitor (que é você) já tem uma introdução do
conhecimento de Java, o tipo de material recolhido de um semestre de curso na faculdade.
Próximo o início desse curso, você terá que se deliciava com muitas vantagens do Java:
orientação a objeto, orientação multi-plataforma, a reutilização de código, facilidade de
desenvolvimento, a disponibilidade de ferramentas, confiabilidade e estabilidade, boa
documentação, suporte da Sun Microsystems, baixo custo de desenvolvimento, a
capacidade de usar o código portado (eg C, C + +), aumentou a produtividade do
programador.
Ao invés de explicar cada um deles novamente, eu vou tomar uma abordagem diferente.
Discutirei a adequação do Java para programação de jogos em termos de equívocos e
reclamações por pessoas que pensam que os jogos devem ser implementados em C ou C +
+, ou assembly, ou qualquer outra coisa (contanto que não seja Java).
tecnologia Hotspot tem o infeliz efeito colateral que a execução do programa é muitas
vezes
lento no início até que o código tem sido analisado e compilado.
O Swing é freqüentemente atacado por ser lento. componentes GUI Swing são criados
e controlados pelo Java, com um pequeno suporte OS: o que aumenta sua portabilidade e
torna-o mais controlável dentro de um programa em Java. A velocidade é supostamente
comprometida, porque Java impõe uma camada extra de processamento em cima da OS.
Isto é uma razão pela qual algumas aplicações de jogos ainda utilizar o original Windowing
Toolkit (AWT) – é apenas um método de invólucro em torno de uma simples chamada OS.
Mesmo que o Swing seja lento (e eu ainda não estou convencido), a maioria dos jogos não
exigem complexas GUIs: um jogo em tela cheia, com controles de teclado e mouse são o
padrão, assim, no modo GUI velocidade é menos que um fator.
No entanto, podem significar que os objetos que já não são necessários pelo programa, ou
seja, o lixo não é coletado. Isso se torna um problema se o programa mantém a criação de
novos objetos, que requerem mais memória e, eventualmente, falha quando o máximo
atribuição não seja ultrapassado.
Esse tipo de problema é uma conseqüência do estilo de programação ruim, uma vez que o
lixo coletor só pode fazer o seu trabalho quando um objeto é completamente dereferenced
(isto é, o programa não se refere a ele). A ferramenta de bom, como JProfiler
(http://www.ejtechnologies. com.br / produtos JProfiler / overview.html), pode ser uma
grande ajuda na identificação