O nome do jogo é Anti-Invaders. É um jogo de tiro espacial como vários outros que apareceram ao longo do tempo. É um gênero bem conhecido e de implementação relativamente simples, por isso mesmo uma boa escolha para um projeto didático.

A idéia é mostrar umprojeto simples porém completo, desenvolvido com protótipos e releases e comentando cada evolução em posts semanais. Serão decisões de game design, de arquitetura de software e de implementação que, no final, darão uma visão completa do processo.

Acredito que será útil principalmente para quem está iniciando e não tem, ainda, noção clara do processo como um todo.

Iniciaremos, então, com a primeira versão do GDD (Game Design Document), criado com base neste post do Everton, embora bem simplificado. Algumas seções não foram preenchidas – nelas está anotado o que deveria ser colocado alí. O foco deste documento é na história de base, fases (tamanho do jogo) e controles. Clique no link abaixo para baixar o PDF.

GDD_Anti_Invaders

Semana que vem teremos um protótipo do jogo para ter idéia do que querermos fazer.

Antes de tudo vou ressaltar: não recomendo trabalhar com threads a menos que seja o desenvolvimento de um jogo AAA, o qual não é foco deste site (digamos um Batman: Asilo Arkhan). Jogos assim, exigem intenso processamento de I.A., física e gráficos e possuem, em geral, muito dinheiro para serem feito. Isso justifica a utilização de uma forma de programação mais complexa. Ainda mais que estes jogos em geral são criados em C++, uma das piores linguagens para trabalhar com threads. Mesmo no Java, cujo uso é relativamente simples (como veremos abaixo), depurar um programa com thread é um inferno.

Além disso, projetar o código para tirar proveito de threads é tarefa para arquitetos competentes – caso contrário você vai criar um código complexo, difícil de depurar e manter e, provavelmente, vai cair em dead locks e outros problemas de concorrência . E ainda corre o risco de acabar com um código pouco eficiente, apesar do esforço adicional.

Fica então o aviso: o código abaixo serve para efeito de exemplo e não deve ser base para um jogo do mundo real.

Bom, se depois do que foi dito acima você ainda não desistiu de ler sobre threads, vamos em frente – o fato é que o conceito por trás delas, e sua correta utilização, são importantes para tirar todo proveito de uma CPU com múltiplos núcleos. Vamos ver como fazer isso com o gameloop desenvolvidos nos meus artigos anteriores. Se você não leu, filtre os posts pela tag Java e leia-os antes, ok?

Modularizando o jogo

Começo criando duas classes especializadas em atualizar a lógica do jogo (lembra do update?) e em atualizar a tela (lembra do render?). Chamarei elas de Controlador e Renderizador, respectivamente. Seu código está abaixo. Basicamente, eu tirei as rotinas update() e render() da minha classe do jogo e coloquei em classes separadas.

Arquivo Controlador.java

001package abrindoojogo.exemplos.thread;
002
003import javax.swing.JFrame;
004
005public class Controlador
006{
007    Contador contador;
008    JFrame frame;
009    Nave nave;
010
011    public Controlador(JFrame frame, Contador contador, Nave nave)
012    {
013        this.frame = frame;
014        this.contador = contador;
015        this.nave = nave;
016    }
017
018    public void update()
019    {
020        contador.contaPulso();
021        nave.x += 1;
022        if (nave.x > frame.getWidth() + 30)
023        {
024            nave.x = 0;
025        }
026    }
027}

Arquivo Renderizador.java

001package abrindoojogo.exemplos.thread;
002
003import java.awt.Color;
004import java.awt.Graphics2D;
005import java.awt.image.BufferStrategy;
006import javax.swing.JFrame;
007
008public class Renderizador
009{
010    BufferStrategy bs;
011    Contador contador;
012    JFrame frame;
013    Nave nave;
014    public boolean terminado = false;
015
016    public Renderizador(JFrame frame, BufferStrategy bs,
017                        Contador contador, Nave nave)
018    {
019        this.frame = frame;
020        this.bs = bs;
021        this.contador = contador;
022        this.nave = nave;
023    }
024
025    public void render()
026    {
027        contador.contaFrame();
028        Graphics2D g = (Graphics2D) bs.getDrawGraphics();
029        g.setColor(Color.black);
030        g.fillRect(0, 0, frame.getWidth(), frame.getHeight());
031        int x = nave.x;
032        int y = nave.y;
033        for (int i = 0; i < nave.qtd; i++)
034        {
035            g.setColor(Color.yellow);
036            g.drawLine(x, y, x - 20, y - 5);
037            g.drawLine(x, y, x - 20, y + 5);
038            g.drawLine(x - 20, y - 5, x - 20, y + 5);
039            y += 15;
040            if (y > 550)
041            {
042                y = nave.y;
043                x += 15;
044            }
045        }
046        g.setColor(Color.white);
047        g.drawString("Pulsos: " + contador.getPulsosPorSegundo() +
048                     "  Frames: " + contador.getFramesPorSegundo() +
049                     "          naves: " + nave.qtd, 10, 20);
050        g.dispose();
051        bs.show();
052    }
053}

Veja que essas classes recebem “de fora”, no momento de sua construção, os objetos necessários para seu funcionamento. Ou seja, elas não possuem dados próprios, encapsulando apenas o algoritmo. Para que elas compartilhem os mesmos dados, criei também uma classe separada para armazenar os dados da nave:

Arquivo Nave.java

001package abrindoojogo.exemplos.thread;
002
003public class Nave
004{
005    int x;
006    int y;
007    int qtd;
008}

A classe do jogo em sí é exatamente igual à classe JogoLoopSimples vista em um artigo anterior, só que sem update() e sem render() e com o gameloop modificado conforme abaixo:

001public void gameloop()
002    {
003        initialize();
004        Controlador c = new Controlador(this, contador, nave);
005        Renderizador r = new Renderizador(this, bs, contador, nave);
006        while (true)
007        {
008            c.update();
009            r.render();
010        }
011    }

Além disso, mais uma pequena modificação: ao sair do programa (pressionar ESC), envio para o console os dados de pulsos e frames, para registro. Isso é feito com um System.out.println() chamado na rotina keyPressed():

001public void keyPressed(KeyEvent e)
002    {
003        if (e.getKeyCode() == KeyEvent.VK_ESCAPE)
004        {
005            System.out.println("Pulsos: " + contador.getPulsosPorSegundo() +
006                                "  Frames: " + contador.getFramesPorSegundo() +
007                                "          naves: " + nave.qtd);
008            System.exit(0);
009        }
010        ...

Executando o programa assim, temos o seguinte resultado:

Reconhece a tela? É o mesmo protótipo da nave dos outros posts. Mas perai… Uau! 460 fps! Não eram apenas 40! Como foi que ficou mais rápido?

Simples: troquei de máquina… Veja: essa é uma máquina bem mais rápida e tem um processador de dois núcleos como podemos ver no painel do gerenciador de tarefas. Note outra coisa também: apesar do jogo estar programado de forma a rodar o mais rápido possível (sem limitação de pulsos), ele utiliza apenas 50% do processamento da máquina. Nos gráficos pode-se ver claramente que o jogo está ocupando praticamente todo núcleo da esquerda, enquanto o da direita está ocioso (quase ocioso, na verdade, está atendendo o S.O. e processos de fundo, como o antivirus).

Abaixo da tela está a saída do console do NetBeans, mostrando o número de pulsos e frames registrados ao fechar o programa.

A soma das partes

Modifiquemos agora nosso gameloop comentando o update(). Assim vamos ver quantos frames conseguimos se eliminarmos o trabalho de atualizar a lógica do jogo.

A saída é a seguinte:

Veja que temos zero pulsos, já que update() nunca foi executada. Mas a quantidade de frames não mudou. Ou seja, o impacto de processamento da nossa lógica é muito pequeno. Vejamos o contrário. Vamos comentar o render().

Resultado abaixo:

Pois é, sem o render() não aparece a tela. Mas o programa está lá, rodando, como podemos ver pelo processamento. Ao pressionar ESC basta olhar para a saída para ver a quantidade de pulsos e… Caraca! Mais de três milhões e meio de pulsos por segundo! Realmente, a parte (bem) mais pesada é a atualização da tela. A atualização da lógica (nesse caso, pelo menos) é tão efêmera que esse computador consegue realizar mais de 3.000.000 em um segundos contra apenas 460 atualizações da tela no mesmo tempo.

Analisando os resultados, entram as Threads

A primeira coisa importante é ver como o render() segura o jogo quando usamos esse tipo de gameloop, que é o mais simples. A cada volta do laço temos um update() (muito rápido) e um render(), que demora e faz com que o próximo update() acabe demorando a ser executado.

Mas o que conta para este post é o seguinte: reveja as imagens acima e preste atenção no processamento. Ele nunca passa de 50%. Ou seja, meu jogo não está tirando tudo da minha máquina nova! Praticamente ele só usa o núcleo da esquerda, enquanto o outro fica com pouco processamento, oriundo das tarefas do sistema. Isso é bom, na verdade. Mas e se eu precisasse de mais processamento? Teria uma forma de usar o outro núcleo? Tem sim, com threads.

Você sabe que o S.O. é multitarefa, ou seja, executa vários programas ao mesmo tempo. Você pode ver um vídeo e ouvir música ao mesmo simultâneamente, porque o S.O dá um pouco de processador para o vídeo e um pouco para a música. É a mesma CPU, porém dividida entre dois programas.

Se tem mais de uma CPU (mais de um núcleo, como na máquina acima), o S.O. pode dar um núcleo inteiro para o vídeo e o outro núcleo para a música, ao invés de dividir a mesma CPU. Isso torna as coisas mais ágeis ainda.

As threads permitem ter esta multitarefa dentro do mesmo programa. Por exemplo, você cria uma thread para carregar os dados do jogo e outra para rodar uma animação. Assim, o S.O. dá um pouco de processamento para cada uma, e o resultado é que você pode mostrar uma animação enquanto os dados são carregados.

A modificação que faço a seguir no código vai permitir colocar o Controlador em uma thread e o Renderizador em outra, de forma a executarem paralelamente e, de quebra, rodar cada um em um núcleo, utilizando todo o poder da máquina. Se o render() sozinho dá 460 frames e update(), também sozinho, dá 3.000.000, agora deverei obter o jogo rodando simultâneamente com 3.000.000 pulsos e 460 frames.

Vamos ver se funciona:

001public class Controlador implements Runnable
002{
003    Contador contador;
004    JFrame frame;
005    Nave nave;
006
007    public Controlador(JFrame frame, Contador contador, Nave nave)
008    {
009        this.frame = frame;
010        this.contador = contador;
011        this.nave = nave;
012    }
013
014    public void run()
015    {
016        while (true)
017        {
018            Thread.yield();
019            update();
020        }
021    }
022
023    public void update()
024    {
025        ...
026
027public class Renderizador implements Runnable
028{
029    BufferStrategy bs;
030    Contador contador;
031    JFrame frame;
032    Nave nave;
033    public boolean terminado = false;
034
035    public Renderizador(JFrame frame, BufferStrategy bs, Contador contador, Nave nave)
036    {
037        this.frame = frame;
038        this.bs = bs;
039        this.contador = contador;
040        this.nave = nave;
041    }
042
043    public void run()
044    {
045        while (!terminado)
046        {
047            Thread.yield();
048            render();
049        }
050    }
051
052    public void render()
053    {
054        ...

Modifiquei o código das classes Controlador e Renderizador para que implementem a interface Runnable do Java. Para isso, também declarei o método run() e dentro dele coloquei um laço. O Renderizador tem um laço que fica chamando render(). O Controlador tem um laço que fica chamando o update().

Agora a modificação no gameloop:

001public void gameloop()
002    {
003        initialize();
004        Controlador c = new Controlador(this, contador, nave);
005        Renderizador r = new Renderizador(this, bs, contador, nave);
006        Thread t;
007        t = new Thread(c);
008        t.start();
009        t = new Thread(r);
010        t.start();
011    }

Aqui está o uso das threads, finalmente. Basta criar um objeto do tipo Thread informando para ele um objeto do tipo Runnable (o Renderizador, por exemplo). Depois chamamos o método start() da thread e ela vai chamar o método run() do objeto que lhe foi passado. O método run() será executado em paralelo ao resto do programa. Então, estamos colocando o laço do render() e o laço do update() para rodarem em paralelo.

Curioso para ver o resutado? Está abaixo:

Voilá! Um milhão e oitocentos mil pulsos e 459 frames. E usado 100% da CPU. Veja que agora os dois núcleos estão absolutamente carregados – a linha do gráfico está “cravada” no topo.

Mas porque deu valores menores do que quando rodamos cada um separadamente? Bom, é que a CPU ainda precisa atender os tais processos de fundo, S.O., antivirus, etc. Eles devem estar rodando no mesmo núcleo do update(), o que fez ele executar mais lentamente. Mas foi uma boa escolha do S.O., já que esse é o processo mais leve. Inteligentes estas máquinas modernas, não?

De qualquer forma, é um desempenho muito acima da primeira versão que eu mostrei.

Conclusão

Não usem threads.

Pelo menos não até chegar a um ponto onde não tenha mais o quê otimizar no código de vocês e ainda assim o jogo esteja lento. Uma minoria de jogos atuais faz uso intensivo de threads (menos de 20, pelo que sei), e todos especialistas concordam que não é fácil.

O que fiz no código acima, compartilhar um objeto (a nave) entre duas threads rodando paralelamente é perigoso. Nesse caso uma delas atualiza os dados e a outra apenas lê. Mas se duas threads atualizarem os mesmos dados ao mesmo tempo, as consequencias serão imprevisíveis. O Java facilita porque possui formas de sincronizar dados, impedindo sua leitura simultaneamente por duas threads. Mas não adianta sincronizar tudo, senão uma thread vai acabar esperando pela outra para poder acessar os dados e vão acabar rodando em sequencia, ao invés de em paralelo.

Por outro lado, o Java, por sí,  já tira proveito de processadores de múltiplos núcleos. Existem outros processos que a máquina virtual faz, como coleta de lixo e otimização interativa do código. A JVM (Máquina Virtual Java) faz uso de threads para separar e rodar em paralelo estas operações, melhorando o desempenhdo do seu programa sem você ter que fazer nada.

Bom, fica aí um exemplo de uso de threads para quem não conhecia.

Baixe o código fonte deste artigo.

Aprendemos, no post anterior, a diferença entre o pulso e o frame, sendo o primeiro relacionado à lógica do jogo e o segundo à atualização da tela. Tinhamos uma classe Main que criava um objeto do tipo JogoLoopSimples. Vamos modificar essa classe para usar agora um objeto do tipo JogoPulsoFixo.

Arquivo Main.java

001package abrindoojogo.exemplos.gameloop;
002
003public class Main
004{
005    public static void main(String[] args)
006    {
007        JogoPulsoFixo jogo = new JogoPulsoFixo();
008        jogo.gameloop();
009    }
010}

O game loop da classe JogoLoopSimples era assim (para relembrar):

001public void gameloop()
002    {
003        initialize();
004        while (true)
005        {
006            Thread.yield();
007            update();
008            render();
009        }
010    }

Uma chamada a update() e uma a render(), acopladas. Se render demora, update também demora e o jogo fica lento. Bem, vamos partir do seguinte pressuposto: é possível “aturar” uma taxa de frames baixa, mas uma taxa de pulsos baixa modifica a jogabilidade.

Imagine um jogo onde uma nave se move um pixel por pulso. Se temos 60 pulsos por segundo, ao final de dois segundos a nave terá se movido 120 pixels. Mas se a taxa cair para 10 pulsos por segundo, em dois segundos a nave vai se mover apenas 20 pixels. E mais: se o computador for muito rápido, a taxa pode subir a 100 pulsos por segundo, e a nave vai andar 200 pixels em dois segundos. A jogabilidade é totalmente afetada.

A solução que apresento a seguir tenta manter a taxa de pulsos fixa, em detrimento da taxa de frames. Ou seja, se a máquina é lenta, priorizamos os pulsos e geramos os frames conforme der. Sempre teremos 60 pulsos por segundo, embora a taxa de frames possa cair para 10.

Isso causa o seguinte efeito: a nave vai se mover sempre 120 pixels em dois segundos, independente da velocidade da máquina. Mas se a máquina for lenta, a tela estará sendo atualizada apenas a 10 frames por segundo – o jogador vai ver a imagem quadro a quadro, mas a jogabilidade não fica tão comprometida, porque não há mudança na velocidade da ação.

E se a máquina for muito rápida, ainda assim ficaremos apenas com 60 pulsos por segundo, embora possamos estar obtendo 100 frames. A atualização da tela será bem rápida, o que é bom, e a nave continua se movendo na velocidade esperada.

Eu mostro abaixo a nova classe, chamada JogoPulsoFixo. Ela é derivada da classe do artigo anterior, de forma que tem tudo igual a ela. A lógica do jogo é exatamente a mesma. Só sobreescrevi o método gameloop, para modificá-lo.

Arquivo JogoPulsoFixo.java

001package abrindoojogo.exemplos.gameloop;
002
003public class JogoPulsoFixo extends JogoLoopSimples
004{
005    long PULSOS_DESEJADOS_POR_SEGUNDO = 60;
006    double NANOS_ESPERADOS_POR_PULSO = Contador.NANOS_EM_UM_SEGUNDO / PULSOS_DESEJADOS_POR_SEGUNDO;
007
008    @Override
009    public void gameloop()
010    {
011        initialize();
012        long nanoTimeDoProximoPulso = System.nanoTime();
013        while (true)
014        {
015            Thread.yield();
016            while (System.nanoTime() > nanoTimeDoProximoPulso)
017            {
018                update();
019                nanoTimeDoProximoPulso += NANOS_ESPERADOS_POR_PULSO;
020            }
021            render();
022        }
023    }
024}

A modificação (marcada em vermelho) é simples em termos de código, mas pode ser difícil de entender como funciona. Por isso vou explicar bem detalhadamente.

Nas linhas 005, 006 são declaradas constantes. PULSOS_DESEJADOS_POR_SEGUNDO armazena a quantidade de pulsos que desejamos que o game rode. Nesse caso é 60. Não é necessário mais do que isso para a lógica de qualquer jogo. Alguns rodam a 30 ou 25.

NANOS_ESPERADOS_POR_PULSO armazena a quantidade de nanosegundos que cada pulso deve durar. Calcular isso é fácil: se queremos 60 pulsos por segundo, basta pegar a quantidade total de nanosegundos que cabem em um segundo (1e9 ou 1.000.000.000) e dividir por sessenta pulsos. Cada pulso vai durar, nesse caso, 16.666.666 nanosegundos. Em geral vai durar menos, mas queremos ter um pulso a cada 16.666.666 nanosegundos, de forma a constituir 60 por segundo.

Agora veja o game loop. A grande mudança é que temos um outro laço dentro dele, para chamar repetidamente update(). Funciona assim: inicializamos uma variável chamada nanoTimeDoProximoPulso com o valor no nanosegundo atual. Em seguida entramos no game loop e já caimos no loop do update. É feita a verificação para ver se o nanosegundo atual é maior do que o nanoTimeDoProximoPulso, o que certamente não será, já que acabamos de atribuir o tempo atual a esta variável.

Pois bem. Entramos no loop do update(), chamamos esta rotina e depois adicionamos ao nanoTimeDoProximoPulso a quantidade de nanos esperados em um pulso. Isso nos dá o momento no tempo quando deverá ser executado o próximo pulso. Não executaremos ele antes desse tempo. Por outro lado, passar muito desse tempo, executaremos ele mais de uma vez até recuperar o atraso.

Vamos analisar um exemplo volta a volta do game loop. Respire fundo antes de continuar lendo.

1. Vamos assumir que tudo iniciou com o nanoTime = 0 (zero). Executamos update(), que demora 5.000.000 nanosegundos e somamos 16.666.666 na variável nanoTimeDoProximoPulso. Isso quer dizer que o próximo pulso é esperado para ocorrer nesse tempo.
2. Como update() demorou apenas 5.000.000 nanosegundos, ainda não chegamos ao 16.666.666 e saimos do loop do update. É executado em seguida o render(), que demora mais 5.000.000 nanosegundos e voltamos ao início do game loop.
3. Nova verificação do loop do update. O tempo atual é maior do que 16.666.666? Já que update() levou 5.000.000 e render() mais 5.000.000, estamos em 10.000.000 nanosegundos, que é menor. Não entramos no loop do update, ou seja, desta vez o update() não será executado, porque ainda não está na hora esperada. Executamos o render(), que leva mais 5.000.000 nanosegundos e voltamos ao início do game loop.
4. Agora já estamos em 15.000.000, mas ainda é menor do que 16.666.666, então pulamos novamente o loop do update e vamos direto para o render. Mais 5.000.000 nanosegundos e voltamos ao início.
5. Agora sim, estamos em 20.000.000 nanosegundos e isso é maior do que o esperado para o próximo pulso, que deveria ter ocorrido em 16.666.666. Estamos atrasados, mas tudo bem – agora entramos no loop do update, executamos ele (mais 5.000.000) e somamos mais 16.666.666 na variável nanoTimeDoProximoPulso. Isso quer dizer que agora vamos esperar até o tempo chegar em 33.333.332 para executar update() novamente.

Já deu para notar que update está sendo limitado. Praticamente temos três render() para cada update(). Essa é uma máquina rápida. Vamos refazer a análise em uma máquina lenta.

1. Tudo inicia no nanoTime = 0 (zero). Executamos update(), que agora demora 10.000.000 nanosegundos e somamos 16.666.666 na variável nanoTimeDoProximoPulso.
2. Como update() demorou apenas 9.000.000 nanosegundos, ainda não chegamos ao 16.666.666 e saimos do loop do update. É executado em seguida o render(), que demora 15.000.000 nanosegundos (placa de vídeo lenta) e voltamos ao início do game loop.
3. Nova verificação do loop do update e o tempo atual é 25.000.000, ou seja, maior que o 16.666.666 esperado para o próximo pulso. Assim, entramos no loop do update e executamos ele. Mais 10.000.000 se passam e estamos então há 35.000.000 nanosegundos de jogo. Acrescentamos novamente 16.666.666 à variável, ficando com 33.333.332, que seria a hora do próximo pulso.
4. Mas veja: já estamos em 35.000.000, ou seja, já passou a hora do segundo pulso. Então ficamos dentro do loop do update (porque 35.000.000 é maior que 33.333.332) e vamos executar update mais uma vez. Se passam mais 10.000.000 e estamos em 45.000.000. Somamos novamente 16.666.666 na variável e o próximo pulso fica então esperado para 49.999.998.
5. Ok, desta vez o tempo atual (45.000.000) é menor do que o esperado para o próximo pulso (49.999.998). Então pulamos o loop do update e vamos para o render(). Executamos ele e, devido aos seus 15.000.000 ficamos em 60.000.000 e voltamos ao início.

Já deu para ver que vamos entrar novamente no loop do update porque estamos bem atrasados. Vamos acabar executando o update duas vezes novamente, ou seja, nessa máquina o update executa o dobro de vezes que o render.

Caramba, que explicação cheia de volta… Entendeu? Espero que sim. Caso contrário, leia novamente o exemplo. Experimente colocar o comando contador.sleep(X), onde X é um número de milisegundos, dentro das rotinas update() e render() no arquivo JogoLoopSimples. Isso vai simular rotinas demoradas. Use valores como 50 ou 100 milisegundos.

Esse game loop mantém a taxa de pulsos fixa (na verdade pode oscilar entre 60 e 62) e pode ser utilizado para a criação de games reais. Mas ele apresenta um problema com máquina muitissimo lentas: pode ser que o update() precise rodar 500 vezes para cada render(). Ou mais! Ou ainda, ficar rodando sem nunca chegar na taxa desejada, e assim nunca executar o update().

Alguma dica de como resolver isso? Se você achar uma solução envie para mim (nornberg no gmail). Depois publico um post citando as soluções que aparecerem.

Baixe o código fonte deste artigo.

O coração de qualquer jogo é o game loop, um laço que fica sendo repetido durante toda execução do jogo. A cada volta desse laço temos um novo frame de jogo. Mas você sabe que a taxa de frames pode variar muito de um hardware para outro. Como manter a lógica do jogo rodando a uma velocidade fixa, independente da variação nos frames?

Quando jogamos, o que vemos na tela é uma sucessão de quadros que nos dá a impressão de movimento. Isso é chamado animação e tenho certeza que você já conhece seus princípios. Em geral somos levados a crer que, a cada quadro novo que vemos, algo mudou no estado do jogo. Se uma nave está se movendo, a cada quadro ela estará, digamos, um pixel para a direita.

É o game loop, o laço principal do jogo, que emite o que podemos chamar de pulsos para atualizar o estado do jogo (update) e redesenhar a imagem na tela (render). Em sua forma mais simples, a cada volta do game loop temos um pulso para update e um para render. Mas estas duas tarefas não precisam ser sempre sincronizadas. Na verdade, é melhor que não sejam.

Vamos contruir um programa de exemplo para estudar mais a fundo o game loop. Neste post vamos ver o loop mais simples e entender sua limitação. No próximo veremos como desacoplar o update do render, de forma que o update rode sempre a uma determinada velocidade e o render rode o mais rápido que puder.

Arquivo Main.java

001package abrindoojogo.exemplos.gameloop;
002
003public class Main
004{
005    public static void main(String[] args)
006    {
007        JogoLoopSimples jogo = new JogoLoopSimples();
008        jogo.gameloop();
009    }
010}

Esta classe simplesmente cria um objeto do tipo JogoLoopSimples e chama seu método gameloop() que vai rodar o jogo. A seguir a classe do jogo em sí, que possui o game loop.

Arquivo JogoLoopSimples

001package abrindoojogo.exemplos.gameloop;
002
003import java.awt.Color;
004import java.awt.Dimension;
005import java.awt.Graphics2D;
006import java.awt.Toolkit;
007import java.awt.event.KeyEvent;
008import java.awt.event.KeyListener;
009import java.awt.image.BufferStrategy;
010import javax.swing.JFrame;
011import javax.swing.WindowConstants;
012
013public class JogoLoopSimples extends JFrame implements KeyListener
014{
015    BufferStrategy bs;
016    Contador contador;
017    int nave_x, nave_y, nave_qtd;
018
019    public JogoLoopSimples()
020    {
021        setUndecorated(true);
022        setSize(800, 600);
023        Dimension d = Toolkit.getDefaultToolkit().getScreenSize();
024        setLocation(d.width / 2 - 400, d.height / 2 - 300);
025        setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
026        setIgnoreRepaint(true);
027        addKeyListener(this);
028        contador = new Contador();
029    }
030
031    public void gameloop()
032    {
033        initialize();
034        while (true)
035        {
036            Thread.yield();
037            update();
038            render();
039        }
040    }
041
042    public void initialize()
043    {
044        setVisible(true);
045        createBufferStrategy(2);
046        bs = getBufferStrategy();
047
048        nave_x = 400;
049        nave_y = 50;
050        nave_qtd = 1;
051
052        contador.inicia();
053    }
054
055    public void update()
056    {
057        contador.contaPulso();
058        nave_x += 1;
059        if (nave_x > getWidth() + 30)
060        {
061            nave_x = 0;
062        }
063    }
064
065    public void render()
066    {
067        contador.contaFrame();
068        Graphics2D g = (Graphics2D) bs.getDrawGraphics();
069        g.setColor(Color.black);
070        g.fillRect(0, 0, getWidth(), getHeight());
071        int x = nave_x;
072        int y = nave_y;
073        for (int i = 0; i < nave_qtd; i++)
074        {
075            g.setColor(Color.yellow);
076            g.drawLine(x, y, x - 20, y - 5);
077            g.drawLine(x, y, x - 20, y + 5);
078            g.drawLine(x - 20, y - 5, x - 20, y + 5);
079            y += 15;
080            if (y > 550)
081            {
082                y = nave_y;
083                x += 15;
084            }
085        }
086        g.setColor(Color.white);
087        g.drawString("Pulsos: " + contador.getPulsosPorSegundo() + "  Frames: " + contador.getFramesPorSegundo() + "          naves: " + nave_qtd, 10, 20);
088        g.dispose();
089        bs.show();
090    }
091
092    public void keyPressed(KeyEvent e)
093    {
094        if (e.getKeyCode() == KeyEvent.VK_ESCAPE)
095        {
096            System.exit(0);
097        }
098
099        if (e.getKeyCode() == KeyEvent.VK_UP)
100        {
101            nave_y -= 1;
102        }
103        if (e.getKeyCode() == KeyEvent.VK_DOWN)
104        {
105            nave_y += 1;
106        }
107        if (e.getKeyCode() == KeyEvent.VK_RIGHT)
108        {
109            if (nave_qtd < 1054)
110            {
111                nave_qtd += 1;
112            }
113        }
114        if (e.getKeyCode() == KeyEvent.VK_LEFT)
115        {
116            if (nave_qtd > 1)
117            {
118                nave_qtd -= 1;
119            }
120        }
121    }
122
123    public void keyReleased(KeyEvent e)
124    {
125    }
126
127    public void keyTyped(KeyEvent e)
128    {
129    }
130}

Vejamos os métodos mais importantes. O contructor faz bastante coisa de configuração, mas tudo com relação à janela do jogo. É tirada a decoração (título, borda, etc) ficando apenas um quadro centralizado no vídeo. É centralizado baseado no tamanho da tela, obtida por meio de Toolkit.getDefaultToolkit().getScreenSize().  Boa parte desse código é parecida com o que foi mostrado no post Passive VS Active Rendering. Note, no entando na criação do objeto “contador”. Ele será utilizado para contar quantos pulsos e quantos frames obteremos. Os pontos onde ele é utilizado estão destacados em vermelho.

O jogo é muito simples – na verdade nem é um jogo. O método update() incrementa a variável nave_x, fazendo ela ir até a direita da tela e então recomeçar da esquerda. Quando uma tecla é pressionada, o método keyPressed modifica a variável nave_y, fazendo a posição subir ou descer, ou aumenta/diminui a variável nave_qtd, que informa quantos sprites teremos na tela.

O método render() limpa a tela, desenha a “nave” (um triângulo feito com linhas) dentro de um loop que vai repetir o desenho tantas vezes quanto for o valor de nave_qtd. Depois mostra na tela os valores de pulsos por segundo e frames por segundos do contador.

Note que toda vez que o método update() é executado, dentro dele é chamado o contador.contaPulso(). E no método render() é chamado contador.contaFrame(). Assim estamos contando quantas vezes estes dois métodos são chamados.

Nosso game loop é a versão mais simples possível, reproduzida abaixo.

031    public void gameloop()
032    {
033        initialize();
034        while (true)
035        {
036            Thread.yield();
037            update();
038            render();
039        }
040    }

É chamado update() e depois render(), um após o outro sem nenhum controle mais elaborado. O método yield() faz o programa interromper rapidamente seu processamento para que o resto do sistema tenha tempo de CPU. Usar ele faz o programa parar um pouco para escutar o teclado. Sem ele, um pressionar de tecla pode ser perdido.

Finalmente vejamos o código do contador.

Arquivo Contador.java

001package abrindoojogo.exemplos.gameloop;
002
003public class Contador
004{
005    static public double NANOS_EM_UM_SEGUNDO = 1e9;
006    protected long pulsosPorSegundo;
007    protected long framesPorSegundo;
008    protected long nanoTimeAnterior;
009    protected long pulsosContados;
010    protected long framesContados;
011
012    public void inicia()
013    {
014        nanoTimeAnterior = System.nanoTime();
015        pulsosContados = 0;
016        framesContados = 0;
017        pulsosPorSegundo = 0;
018        framesPorSegundo = 0;
019    }
020
021    public void contaPulso()
022    {
023        pulsosContados++;
024        verifica();
025    }
026
027    public void contaFrame()
028    {
029        framesContados++;
030        verifica();
031    }
032
033    protected void verifica()
034    {
035        if (System.nanoTime() - nanoTimeAnterior > NANOS_EM_UM_SEGUNDO)
036        {
037            pulsosPorSegundo = pulsosContados;
038            framesPorSegundo = framesContados;
039            pulsosContados = 0;
040            framesContados = 0;
041            nanoTimeAnterior = System.nanoTime();
042        }
043    }
044
045    public void sleep(long miliSecondsToSleep)
046    {
047        try
048        {
049            Thread.sleep(miliSecondsToSleep);
050        } catch (Exception e)
051        {
052        }
053    }
054
055    public long getPulsosPorSegundo()
056    {
057        return pulsosPorSegundo;
058    }
059
060    public long getFramesPorSegundo()
061    {
062        return framesPorSegundo;
063    }
064}

O trabalho desta classe é interessante: cada vez que chamamos o método contaPulso(), ela incrementa o contador de pulsos e chama o método verifica() que testa se já passou um segundo desde a última verificação. Se sim, ele atribui a quantidade de pulsos contados para a variável pulsosPorSegundo. Assim, esta variável é atualizada a cada segundo com a quantidade de pulsos que ocorreram. Nesse momento o contador de pulsos é zerado para contar quantos pulsos ocorrerão no próximo segundo. A mesma coisa para a contagem de frames.

O tempo é medido em nanosegundos, que é bem menor que os milisegundos geralmente utilizados nos programas. Um segundo contém 1.000 milisegundos, ou seja, 1e3 (mil). E possui 1.000.000.000 nano segundos, ou seja, 1e9 (um milhão). Esse valor está registrado na constante NANOS_EM_UM_SEGUNDO para ser utilizado nos cálculos.

Essa classe oferece ainda um método utilitário chamado sleep(), que servirá para realizarmos alguns testes. Ele simplifica o uso do método sleep() de Thread, que precisa de um try-catch para ser usado. Ele faz o processamento parar durante os milisegundos informados.

Executando esse programa, obtenho o seguinte resultado (só mostro o canto da tela):

Conforme os dados do contador mostrados, tenho 47 pulsos por segundo e também 47 frames. Naturalmente estes números serão sempre iguais, porque dentro do loop chamo uma vez update() e uma vez o render().

Se eu desejasse 60 fps (frames por segundo), não seria possível. 47 é tudo que eu consigo no meu computador e ainda fica variando. Se eu pressiono a seta para direita, aumentando a quantidade de sprites até 1054, a taxa de frames cai mais um pouco.

Talvez seu computador seja bem mais rápid e mesmo aumentando os sprites a taxa de frames não apresente muita diferença. Vamos fazer um teste mais exagerado. Chamaremos o método contador.sleep() dentro do método render(), de forma a fazer este método demorar alguns milisegundos a mais.

001
002
003    public void render()
004    {
005        contador.contaFrame();
006        Graphics2D g = (Graphics2D) bs.getDrawGraphics();
007        g.setColor(Color.black);
008        g.fillRect(0, 0, getWidth(), getHeight());
009        int x = nave_x;
010        int y = nave_y;
011        for (int i = 0; i < nave_qtd; i++)
012        {
013            g.setColor(Color.yellow);
014            g.drawLine(x, y, x - 20, y - 5);
015            g.drawLine(x, y, x - 20, y + 5);
016            g.drawLine(x - 20, y - 5, x - 20, y + 5);
017            y += 15;
018            if (y > 550)
019            {
020                y = nave_y;
021                x += 15;
022            }
023        }
024        g.setColor(Color.white);
025        g.drawString("Pulsos: " + contador.getPulsosPorSegundo() + "  Frames: " + contador.getFramesPorSegundo() + "          naves: " + nave_qtd, 10, 20);
026        g.dispose();
027        bs.show();
028        contador.sleep(50);
029    }

Agora sim. O tempo de atualizar a tela (render) leva absurdos 50 ms (milisegundos). Absolutamente lento demais. A taxa de frames cai para 14 na minha máquina.

Agora preste atenção na parte mais importante: a taxa de pulsos por segundo cai junto com os frames, embora apenas a rotina render() tenha recebido o tempo a mais. Isso ocorre porque como uma rotina é chamada depois da outra, em sequencia, update() tem que esperar render() executar para ser executada novamente.

Rodando o jogo você percebe que não é apenas a taxa de atualização da tela que fica lenta, mas o jogo todo. A nave agora leva uma eternidade para chegar até a extremidade da tela, porque temos apenas 14 pulsos de atualização da sua posição por segundo.

Está comprovado o problema. No próximo post a solução. Até amanhã.

Baixe o código fonte deste artigo.

Atualização ativa

No artigo anterior vimos a atualização passiva que pode ser utilizada para a criação de jogos que possuem gráficos simples ou ação lenta. E nestes casos é até recomendada, porque compromete pouco a CPU. Mas em jogos mais animados não podemos depender do S.O. para gerar as atualizações da tela. Nesse caso desligamos o mecanismo de atualização automatica e partimos para o manual, com a atualização ativa.

O Java nos permite controlar a tela de forma deterministica por meio da classe BufferStrategy. Não é um acesso direto à placa de vídeo, porque o Java nos isola da camada de hardware. Mas isso é bom, porque simplifica a coisa e nos oferece uma forma padrão para trabalhar, o mais independente possível da configuração da máquina do usuário.

Abaixo mostro o código de um programa quase idêntico ao do artigo anterior, porém agora usando atualização ativa.

Arquivo: Main.java

 1 package abrindoojogo.exemplos.atualizacaoativa;
 2
 3 public class Main
 4 {
 5     public static void main(String[] args)
 6     {
 7         MeuJogo mj = new MeuJogo();
 8         mj.setVisible(true);
 9         mj.initialize();
10     }
11 }
12
13

Veja que a classe principal é quase igual. A diferença é que a classe MeuJogo agora possui um método initialize que deve ser chamado depois de tornarmos ela visível. Nesse método inicializamos a BufferStrategy (veja abaixo). Destaquei em vermelho as partes que são novidade em relação ao exemplo anterior.

Arquivo: MeuJogo.java

 1 package abrindoojogo.exemplos.atualizacaoativa;
 2
 3 import java.awt.Color;
 4 import java.awt.Graphics2D;
 5 import java.awt.event.KeyEvent;
 6 import java.awt.event.KeyListener;
 7 import java.awt.image.BufferStrategy;
 8 import javax.swing.JFrame;
 9 import javax.swing.WindowConstants;
10
11 public class MeuJogo extends JFrame implements KeyListener
12 {
13     int tom;
14     BufferStrategy bs;
15
16     public MeuJogo()
17     {
18         setTitle("Atualização Ativa");
19         setSize(800, 600);
20         setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
21         setIgnoreRepaint(true);
22         addKeyListener(this);
23         tom = 0;
24     }
25
26     public void initialize()
27     {
28         createBufferStrategy(1);
29         bs = getBufferStrategy();
30         render();
31     }
32
33     public void render()
34     {
35         Graphics2D g = (Graphics2D) bs.getDrawGraphics();
36         g.clearRect(0, 0, getWidth(), getHeight());
37         for (int x = 0; x < 800; x += 10)
38         {
39             for (int y = 0; y < 600; y += 10)
40             {
41                 g.setColor(new Color(x % 256, y % 256, (tom * 50)
                   % 256));
42                 g.fillRect(x, y, 10, 10);
43             }
44         }
45         g.dispose();
46         bs.show();
47     }
48
49     public void keyPressed(KeyEvent e)
50     {
51         if (e.getKeyCode() == KeyEvent.VK_ENTER)
52         {
53             tom++;
54             render();
55         }
56     }
57
58     public void keyReleased(KeyEvent e)
59     {
60     }
61
62     public void keyTyped(KeyEvent e)
63     {
64     }
65 }
66
67

O contructor é muito parecido, mas preste atenção. Ele inclui agora uma chamada ao método setIgnoreRepaint() passando o valor true. Isso desliga a atualização automática. O S.O. não vai mais gerar eventos de atualização para nossa janela.

Em seguida temos o método initialize().

26     public void initialize()
27     {
28         createBufferStrategy(1);
29         bs = getBufferStrategy();
30         render();
31     }

Nesse método eu chamo createBufferStrategy(), que é pertencente à classe JFrame. O parâmetro é a quantidade de buffers de tela que quero usar. Falarei sobre isso adiante. Adquiro uma referência ao BufferStratey e armazeno na variável bs. Através desta variável eu vou ter acesso ao buffer da tela para desenhar meus gráficos. Logo após chamo o método render().

O método render() é o próximo declarado na classe. É nele que se dá o desenho da tela. Veja que é praticamente o mesmo código que estava dentro do método paint() do artigo anterior. Só que agora é um método próprio e não um manipulador de evento. Lembre que desligamos a atualização automática, que chamava o paint(). O método render(), por sua vez, será chamado diretamente por mim, quando eu desejar que a tela seja redesenhada.

33     public void render()
34     {
35         Graphics2D g = (Graphics2D) bs.getDrawGraphics();
36         g.clearRect(0, 0, getWidth(), getHeight());
37         for (int x = 0; x < 800; x += 10)
38         {
39             for (int y = 0; y < 600; y += 10)
40             {
41                 g.setColor(new Color(x % 256, y % 256, (tom * 50)
                   % 256));
42                 g.fillRect(x, y, 10, 10);
43             }
44         }
45         g.dispose();
46         bs.show();
47     }

Examinando esse método, vemos que a parte que lida com o objeto “g”, do tipo Graphics2D, é idêntica à anterior. A diferença está no modo como obtemos o Graphics. Antes ele era recebido como parâmetro no método paint(). Ou seja, o S.O. nos passava o Graphics ao chamar o método. Agora nós pegamos um Graphics do objeto BufferStrategy. Esse Graphics que ele retorna é uma referência para o buffer da tela, desenhando nele, desenhamos nela. Depois de usar, chamamos o método dispose para liberar – adquirimos e liberamos um novo Graphics a cada render.

Depois do desenho pronto, chamamos o método show() do BufferStrategy. Embora nesse momento ele fique um pouco perdido, vai fazer mais sentido quando eu falar em mais de um buffer, daqui a pouco.

A modificação final é no método keyPressed(), que é o manipulador para o evento de tecla pressionada. Depois de atualizar a variável “tom”, chamamos render(). Aqui reside a grande diferença: enquanto antes chamavamos repaint() para avisar o S.O. que desejávamos uma atualização, e ficava a cargo dele atualizar a tela quando bem entendesse, agora chamamos diretamente nosso método render(), que vai obter um Graphics e desenhar na hora, sem espera.

Execute esse programa e o resultado vai ser parecido com o anterior, na parte visual. Quando você ficar pressionando ENTER a tela vai piscar da mesma forma, porém a atualização da tela consome mais CPU e por isso se você ficar pressionando por muito tempo, os eventos keyPressed não vão ser processados a tempo e vão acumular (ao soltar a tecla continuarão sendo gerados eventos por algum tempo).

Note também que redimensionando a janela ela não é mais redesenhada. Não há mais eventos relacionado a essa ação.

DoubleBuffer

Para evitar as piscadas na tela (o efeito chamado de tearing – rasgo), utilizaremos dois buffers ao invés de um. A lógica é a seguinte: se temos apenas um buffer, ele está sempre sendo mostrado na tela. Quando desenhamos nele, o desenho é feito diretamente nela e podemos ver o desenho sendo contruído e reconstruído repetidamente. Isso causa o efeito indesejado.

Se utilizarmos dois buffers, enquanto um deles é mostrado na tela, desenhamos no outro. Assim, enquanto o desenho está sendo contruído, nós estamos olhando para o desenho anterior, que está estático. Quando o novo desenho está pronto, o método show() do BufferStrategy troca os buffers. Aquele que acabamos de atualizar vai para a tela e o outro passa a ser o de desenho. E ficamos nessa, sempre desenhando no buffer de trás (back buffer) enquanto o outro (front buffer ou buffer primário) fica estático na tela. Como a troca de buffers é muito rápida, centenas de vezes mais rápida do que gerar um desenho na tela, não ocorre nenhum efeito perceptível para o usuário.

Para usar dois buffers, basta mudar o parâmetro do método createBufferStrategy(). Passe o número 2 ao invés de 1 e execute o programa. As piscadas sumirão. Você pode usar mais buffers, mas isso torna o processo mais lento e consome bem mais memória – veja, cada buffer é uma cópia da tela, seria como ter três telas na memória de vídeo. E memória de vídeo é algo que não podemos desperdiçar. Apenas em casos muito específicos, ou em determinados hardwares, o uso de triplebuffer traz melhorias e pode ser usado. Mais de três buffers, nem pensar – você pode até passar um número maior, mas provavelmente serão criados apenas 2 ou 3.

Observação: dependendo do seu hardware, a troca de buffers pode ser feita de formas diferentes, o que gera resultados melhores para uns do que para outros. De qualquer forma a diferença deste exemplo para o anterior será gritante.

Fullscreen e mudança de modo de vídeo

Que tal rodar o jogo em tela-cheia? Essa é melhor opção porque cria uma imersão muito mais profunda para o usuário, melhorando sua experiência com o jogo. Mas só tela-cheia não basta por causa do tamanho da tela. Se seu jogo foi feito em 800×600 (como é o caso desse exemplo), colocar em tela-cheia vai fazer ele não ocupar toda tela, ficando uma borda preta ao redor. Em um monitor com resolução de 1440, o jogo fica sendo apenas um quadro no meio da tela.

Para usar tela-cheia, o ideal, então, é mudar o modo de vídeo do monitor para ajustar-se à resolução do jogo. Mudando o modo de vídeo para 800×600 o jogo ocupa todo monitor, sem bordas.

Fazer isso é bem fácil. Veja abaixo o método initialize modificado para colocar a janela em tela-cheia e logo após mudar o modo de vídeo para 800×600.

28     public void initialize()
29     {
30         createBufferStrategy(1);
31         bs = getBufferStrategy();
32         getGraphicsConfiguration().getDevice().
           setFullScreenWindow(this);
33         getGraphicsConfiguration().getDevice().setDisplayMode(
           new DisplayMode(800, 600, 32,
           DisplayMode.REFRESH_RATE_UNKNOWN));
34         render();
35     }
 

Utilizei o método getGraphicsConfiguration() herdado da classe JFrame para, através dele, obter acesso ao dispositivo de vídeo (getDevice). A classe GraphicsDevice nos provê um método para entrar em tela-cheia, que é setFullScreenWindow(). Passamos para ele a janela que vai ocupar a tela – nesse caso, nossa própria classe, que é uma janela. Passando null para esse método saimos da tela-cheia, o que também ocorre, automaticamente, ao fecharmos o programa.

Outro método que temos à disposição é o setDisplayMode(). Passamos para ele um objeto do tipo DisplayMode, criado com os dados do modo de vídeo desejado. Os primeiros dois parâmewtros são largura e altura (800×600). Em seguida a profundidade de cor, ou seja, quantos bits por cor. No caso, passei 32 bits – hoje todos monitores suportam isso. O último parâmetro é a taxa de atualização do monitor (refresh rate). Por exemplo, pode ser 60, 70, 80, etc, onde 60 significa 60Hz e assim por diante. Mas essa taxa não é padronizada e por isso é melhor utilizar a constante DisplayMode.REFRESH_RATE_UNKNOWN, que não muda a taxa de atualização do monitor.

Executando o programa assim, ele entra ela tela-cheia. Mas ainda fica com a borda da janela, o que não é desejado nesse caso. Programas em tela-cheia não exibem a borda. Para esconder ela, basta chamar o método setUndecorated() passando true. Isso tira a decoração da janela (borda, título, botões). Veja abaixo como chamei esse método no contructor.

17     public MeuJogo()
18     {
19         setTitle("Atualização Ativa");
20         setSize(800, 600);
21         setUndecorated(true);
22         setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
23         setIgnoreRepaint(true);
24         addKeyListener(this);
25         tom = 0;
26     }

Pronto, agora temos um programa que roda em tela-cheia, mudando a resolução do vídeo e sem piscar ao atualizar a tela. Além de termos a garantia de que a tela vai ser atualizada sempre que mandarmos.

Mas para evoluir até um jogo, falta um detalhe importante! Você notou que a coisa só se “mexe” quando pressionamos ENTER. Isso porque é dentro do evento do teclado (keyPressed) que modificamos a variável e atualizamos a tela. Um jogo real fica modificando seu estado e atualizando a tela sozinho, sem ninguém pressionar um tecla. Para isso temos que ter um loop em algum lugar – o fatídico game loop. Assunto para o próximo post.

Até lá, pensem na melhor forma de fazer isso. Que tal fazer esse programa ficar mudando as cores sem estar o ENTER pressionado? Mãos à obra.

Baixe o código fonte deste artigo.

Atualização passiva

Esta é forma padrão de atualização de tela para programas em Java, geralmente utilizada por aplicativos. É comum se ouvir falar que esta forma não serve para jogos, mas isto não é inteiramente verdade. Como tudo nessa vida, isso depende.

A atualização passíva consiste em criar uma rotina que é chamada pelo sistema operacional (S.O.) sempre que ele precisar de uma versão atualizada da nossa tela. Em termos técnicos criamos um manipulador de evento (event handler) para o evento Paint.

Veja que é o S.O. que decide quando a atualização é necessária, baseado em dados que ele possui e não baseado em dados do jogo em sí. Esta é sua maior limitação. Por outro lado, é uma forma muito leve em termos de processamento, já que a tela vai ser atualizada apenas quando for necessário e esta é sua vantagem.

Mas baseado em quê o sistema decide se precisa ou não atualizar a tela? Fundamentalmente em mudanças na área da tela como redimensionamento ou ocultamento/reapresentação.

Por exemplo, se nossa tela é uma janela, o sistema vai requerer uma atualização dela sempre que a mesma for redimensionada ou for ocultada e depois mostrada novamente. Nesses eventos é que precisamos desenhar novamente o conteúdo da tela. Veja a ilutração a seguir.

clique para ampliar

Vejamos como implementar isso em Java, usando uma janela do tipo Swing. Criamos uma classe chamada MeuJogo que é derivada da classe JFrame (um frame – moldura – é como chamamos uma janela em Java).

Arquivo: MeuJogo.java

 1 package abrindoojogo.exemplos.atualizacaopassiva;
 2
 3 import java.awt.Color;
 4 import java.awt.Graphics;
 5 import java.awt.event.KeyEvent;
 6 import java.awt.event.KeyListener;
 7 import javax.swing.JFrame;
 8 import javax.swing.WindowConstants;
 9
10 public class MeuJogo extends JFrame implements KeyListener
11 {
12     int tom;
13
14     public MeuJogo()
15     {
16         setTitle("Atualização Passiva");
17         setSize(800, 600);
18         setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
19         addKeyListener(this);
20         tom = 0;
21     }
22
23     @Override
24     public void paint(Graphics g)
25     {
26         g.clearRect(0, 0, getWidth(), getHeight());
27         for (int x = 0; x < 800; x += 10)
28         {
29             for (int y = 0; y < 600; y += 10)
30             {
31                 g.setColor(new Color(x % 256, y % 256, (tom * 50) % 256));
32                 g.fillRect(x, y, 10, 10);
33             }
34         }
35     }
36
37     public void keyPressed(KeyEvent e)
38     {
39         if (e.getKeyCode() == KeyEvent.VK_ENTER)
40         {
41             tom ++;
42         }
43     }
44
45     public void keyReleased(KeyEvent e)
46     {
47
48     }
49
50     public void keyTyped(KeyEvent e)
51     {
52
53     }
54 }

Abaixo o código da classe principal do programa, onde o processamento inicia. Nela criamos um objeto do tipo da classe MeuJogo e fazemos ele ficar visível. Assim a janela aparece na tela.

Arquivo: Main.java

 1 package abrindoojogo.exemplos.atualizacaopassiva;
 2
 3 public class Main
 4 {
 5     public static void main(String[] args)
 6     {
 7         MeuJogo mj = new MeuJogo();
 8         mj.setVisible(true);
 9     }
10 }

Faça o seguinte teste: execute esse exemplo e arraste o canto inferior direito da janela, redimensionando-a. Você vai notar que a imagem pisca: isso é porque está sendo redesenhada a cada alteração de tamanho. Faça isso bem rapidamente e você poderá notar que a imagem deixa de piscar por alguns instantes. Isso ocorre porque o sistema fica sobrecarregado com a mudança de tamanho e, para poupar CPU, deixa de atualziar a imagem, aguardando você parar de mover o mouse para, só então, gerar o evento de redesenho.

Experimente també ficar pressionando a tecla ENTER. Nada ocorre, embora tenhamos um manipulador para o evento KeyPressed que incrementa a variável “tom”, que é utilizada para determinar a cor do gráfico. Porque a cor do gráfico não muda?

O que ocorre é que nosso modelo, digamos assim, ou seja, a representação interna do gráfico mudou (a variável foi incrementada), mas como o S.O não sabe disso, ele não enviou o evento para atualziar a tela e por isso a imagem permanece igual. Para contornar isso basta chamar o método repaint() dentro do evento keyPressed. Veja abaixo.

37     public void keyPressed(KeyEvent e)
38     {
39         if (e.getKeyCode() == KeyEvent.VK_ENTER)
40         {
41             tom ++;
42             repaint();
43         }
44     }

Esse método informa ao S.O. que desejamos uma atualização da tela. Rode o programa agora a fique pressionando ENTER. Agora sim, a cor do gráfico muda. Pronto, temos uma máquina simples que serve como base para um jogo de pouca ação. Por exemplo, jogos de tabuleiro como batalha naval.

Porque não serve para jogos de ação intensa e animações constantes? Porque não temos controle sobre quando a tela será atualizada e porque tudo pisca (você notou que o gráfico piscar ao ficar pressionando ENTER?).

Colocar a chamada ao método repaint não faz a tela ser atualizada na hora. Apenas informa ao S.O. que queremos uma atualização, mas o S.O. pode demorar até alguns segundos para atualizar. Se for um jogo de ação, digamos de luta, o modelo interno do jogo vai ser atualizado várias vezes até que a tela seja redesenhada. Ou seja, seu oponente pode lhe dar um chute, você perder energia e o oponente voltar a posição normal, tudo isso antes da próxima atualização da tela. Quando a tela for redesenhada, você vai ver que sua energia diminuiu, mas não viu o que aconteceu.

E, é claro, tem o problema de piscar. Como estamos atualizando diretamente a tela, ocorre o efeito de tearing (rasgo), onde parece que a imagem fica rasgada. Explicarei porque isso ocorre em um próximo post.

Mas para jogos lentos, quase parando, essa é uma boa opção porque consome muito pouco da CPU. Por exemplo, se for um jogo de damas. Você só precisa chamar o repaint() quando um dos jogadores mover uma peça, o que ocorre com pouca frequência. Não terá o efeito de ficar piscando.

Durante muito tempo isso foi tudo que podia ser feito em Java. Mas já alguns anos que a linguagem permite o que chamamos de active rendering. Esse recurso possibilita atualização instantânea da tela, a cada frame e de quebra nos oferece double buffer (o fim das piscadas), tela-cheia e até mudança de modo de vídeo. Veremos tudo isso amanhã, nesse mesmo site, nesse mesmo horário.

Baixe o código fonte deste artigo.