Nesta parte 1 aprenderemos como inicializar o canvas e carregar e exibir imagens.

A primeira coisa que precisamos saber para criar jogos em HTML 5 é… bem, HTML! É necessário o conhecimento básico de tags e de como criar pelo menos uma página vazia para conter o jogo.

A segunda coisa é um pouco de CSS, que serve para configurar os elementos inseridos na página (bordas, cores, tamanhos, etc). Jogos mais avançados em HTML utilizam muitos elementos fora do <canvas>, que vamos ver nesse tutorial, tirando proveito de outros elementos HTML para apresentar dados e de CSS para formatar este dados.

Finalmente, precisamos saber também Javascript (JS) para fazer a programação da lógica do jogo. A sintaxe é parecida com Java ou C++ e oferece suporte a objetos, embora não seja de fato uma linguagem orientada a objetos. Não oferece, por exemplo, recurso para herança, embora seja possível simular isto com construções mais avançadas.

Vou assumir que você entende pelo menos o mínimo de HTML e CSS e que sabe incluir scripts em uma página. Mas a necessidade disto é tão pequena para este tutorial que é até possível você aprender o necessário só estudando os exemplos.

Dito isso, vamos em frente.

O elemento <canvas>

Uma das novidades que a versão 5 da HTML trouxe foi a tag <canvas>, que cria na página um elemento que permite o desenho direto. Antes disso, para exibir imagens era preciso inserir um elemento <img> para cada uma. Ess elemento cria um objeto gráfico no navegador para armazenar e apresentar a imagem – este tipo de objeto consome recursos do sistema. Se todas imagens fossem sprites animados, teríamos um página bem pesada para o navegador renderizar. Com o canvas, no entanto, podemos desenhar nele todas imagens necessárias e o navegador só vai renderizar o canvas – como se fosse uma única imagem.

Além disso, com o canvas podemos desenhar primitivas gráficas, como linhas, retângulos e texto, além de ter efeitos de composição na aplicação das imagens. A grosso modo, o canvas é como uma imagem cujo conteúdo pode ser modificado. Utilizamos ele como se fosse a tela, desenhando nele cada quadro do jogo.

A inclusão de um elemento canvas na página é feita com a tag <canvas>>. No exemplo de código abaixo temos uma página HTML que contém esta tag e também um elemento <div> acima do canvas, dentro do qual vai uma informação textual.

 
        <script src="aoj/aojcanvas.js"><!--mce:0--></script>
<div id="info">Abrindo o Jogo - exemplo de uso do elemento canvas</div>

Note que esta página inclui dois arquivos externos:

css/estilos.css: Contém o código CSS de formatação dos elementos. Esse código se refere aos elementos pelo seu ID, sendo que o div possui o ID “info” e o canvas possui o ID “Canvas1″.

O conteúdo deste arquivo é o seguinte:

body {
    margin: 0px;
    border: none;
    background-color: black;
}
#canvas1 {
    position: absolute;
    left: 50%;
    top: 50%;
    margin-left: -480px;
    margin-top: -300px;
    background-color: white;
}
#info {
    background-color: blue;
    color: yellow;
    font-family: Arial;
    font-size: 14px;
    font-weight: bold;
    padding: 5px;
    text-align: center;
}

Basicamente o código deste arquivo muda o fundo da página para preto, centraliza o canvas na tela e aplica estilo de fundo, cor e fonte ao div que apresenta o texto. É comum colocarmos os arquivos de estilo dentro de uma pasta “css”.

aoj/aojcanvas.js: este arquivo de script possui o código para inicialização e uso do canvas, contendo algumas rotinas criadas para facilitar a programação. Veremos como usar o canvas a seguir.

Usando o elemento canvas

Para obter uma referência ao elemento canvas, usamos o comando document.getElementById(), passando o ID que especificamos para nosso canvas. Obtemos a referência e atribuímos para uma variável, assim:

    var _aojCanvas = document.getElementById(canvasId);

Para desenhar algo nele, precisamos obter um contexto gráfico, o que é feito com o método getContext do canvas. Esse método requer um parâmetro que, atualmente, só pode ser “2d”.

Depois de obter o contexto, atribuindo ele a uma variável, usamos os métodos dele para desenhar. Veja abaixo:

window.onload = function() {
    var _aojCanvas = document.getElementById('canvas1');
    var ctx = _aojCanvas.getContext('2d');
    ctx.beginPath(); // inicia um desenho.
    ctx.fillStyle = 'blue'; // especifica a cor de preenchimento.
    ctx.strokeStyle = 'red'; // especifica a cor de contorno.
    ctx.rect(10, 10, 200, 100); // especifica um retângulo.
    ctx.rect(220, 10, 50, 50); // especifica outro retângulo.
    ctx.stroke(); // contorna o desenho (dois retângulos).
    ctx.fill(); // preenche o desenho (dois retângulos).
    ctx.beginPath(); // inicia outro desenho.
    ctx.strokeStyle = 'black'; // muda a cor de contorno.
    ctx.rect(50, 50, 100, 100); // especifica um retângulo.
    ctx.stroke(); // contorna o desenho (um retângulo).
}

O código acima desenha dois retângulos preenchidos de azul dentro do canvas. Cada desenho é iniciado com beginPath. Se este método não fosse chamado na segunda vez, o terceiro retângulo especificado ainda seria parte do primeiro desenho e o comando stroke iria contornar os três retângulos.

Perceba que o código foi colocado dentro de uma função atribuída ao evento onload da janela, para que seja executado apenas depois dela carregar completamente. Isso é importante porque se não for feito, o código executaria assim que fosse baixado – o que poderia ocorrer antes mesmo da declaração do canvas ter sido carregada – o que resultaria em erro porque o objeto canvas não existira ainda na página.

Métodos de atalho

A utilização do canvas para desenhar é algo de baixo nível. São precisos vários comandos para desenhar um retângulo na tela, por exemplo.

Para facilitar a programação, é interessante criar funções auxiliares que incluem todas chamadas necessárias para realizar determinadas ações. Assim criamos uma biblioteca própria. O arquivo aojcanvas.js é um exemplo de biblioteca deste tipo, embora incompleta.

Vejamos algumas funções deste arquivo para entender essa prática:

function aojSetCanvas(canvasId) {
    _aojCanvas = document.getElementById(canvasId);
}
 
function aojFillStyle(optionalNewValue) {
    var ctx = _aojCanvas.getContext('2d');
    if (optionalNewValue)
        ctx.fillStyle = optionalNewValue;
    return ctx.fillStyle;
}
 
function aojFillRect(x, y, w, h, optionalFillStyle) {
    var ctx = _aojCanvas.getContext('2d');
    ctx.beginPath();
    if (optionalFillStyle) {
        ctx.fillStyle = optionalFillStyle;
    }
    ctx.rect(x, y, w, h);
    ctx.fill();
}

A função aojSetCanvas() é usada para informar à nossa biblioteca qual elemento canvas desejamos usar – podemos ter mais de um canvas na nossa página. Passamos o ID como parâmetro e o elemento é obtido é armazenado em uma variável global, acessível para todas as demais funções.

aojFillStyle() permite obter o estilo de preenchimento atual, e também modificá-lo. Se for passado um parâmetro, ele é usado para modificar o estilo, que em seguida é retornado. Se não for passado o parâmetro, o estilo atual não é modificado, apenas retornado.

E a função aojFillRect() serve para desenhar um retângulo preenchido. Ela pode usar o estilo previamente definido, mas também aceita um quarto parâmetro opcional que, se informado, é usado como estilo para o retângulo.

Este tipo de comando permite mudar nosso exemplo para o seguinte:

window.onload = function() {
    aojSetCanvas('canvas1');
    aojFillRect(10, 10, 200, 100, 'blue'); // preenche um retângulo azul.
    aojFillRect(220, 10, 50, 50, 'blue'); // preenche outro retângulo azul.
    aojStrokeRect(10, 10, 200, 100, 'red'); // contorna um retângulo vermelho.
    aojStrokeRect(220, 10, 50, 50, 'red'); // contorna outro retângulo vermelho.
    aojStrokeRect(50, 50, 100, 100, 'black'); // contorna um retângulo preto.
}

Este exemplo ficaria ainda mais claro e resumido se criássemos uma função para desenhar um retângulo preenchido e já contornado. Até que ponto devemos ir na criação de nossa própria biblioteca de funções vai depender da natureza de cada projeto – aqueles procedimento que são repetidos muitas vezes são os que devem ser transformados em funções. Não recomendo tentar criar uma porção de funções de antemão porque você acabará com muitas que nunca vai utilizar, e mesmo assim não eliminará o risco de precisar de uma que não lembrou.

Desenhando imagens no canvas

É importante saber como desenhar primitivas gráficas no canvas, mas o principal recurso ainda é a apresentação de imagens, afinal, quase todo jogo é feito de sprites.

Para carregar uma imagem, basta criar um objeto do tipo Imagem e atribuir a URL do arquivo para o atributo “src”. Opcionalmente podemos atribuir uma função para o atributo onload – esta função será chamada quando o arquivo de imagem for carregado. Este é um recurso importante de usar em jogos com muitas imagens, para garantir que todas tenham sido carregadas antes de iniciar o jogo.

Novamente, para facilitar o trabalho, criamos uma função na nossa biblioteca:

function aojNewImage(imgURL, optionalLoadCallback) {
    var img = new Image();
    img.src = imgURL;
    img.onload = optionalLoadCallback;
    return img;
}

Esta função recebe a URL do arquivo da imagem e opcionalmente uma função de callback, que será chamada quando a imagem for carregada.

Para desenhar uma imagem no canvas, temos outra função:

function aojDrawImage(img, x, y) {
    var ctx = _aojCanvas.getContext('2d');
    ctx.drawImage(img, x - img.width / 2, y - img.height / 2);
    if (_aojShowImageCenter) {
        ctx.arc(x, y, 2, 0, 2*Math.PI, false);
        ctx.fill();
    }
}

Nesta função, apenas as duas primeiras linhas são responsáveis por desenhar a imagem no canvas. O IF é usado para desenhar um círculo no ponto (x,y) onde a imagem é desenhada, de forma a enxergarmos onde fica esse ponto. É útil para debugar posicionamento.

Transformações geométricas

O canvas oferece métodos para aplicar transformações geométricas no que é desenhado nele. Por exemplo, podemos rotacionar ou aumentar e diminuir uma imagem no momento de desenhá-la.

É importante saber, no entanto, que uma vez especificada uma transformação, ela fica em efeito para tudo que for desenhado depois. Portanto, depois de aplicar uma rotação, por exemplo, e desenhar a imagem desejada, é preciso aplicar a rotação inversa para deixar o canvas no estado normal antes de desenhar as próximas imagens.

Abaixo está uma função para desenhar uma imagem com transformação de escala. Como parâmetros ela recebe o objeto imagem, a posição (x, y) onde ele deve ser desenhado e os fatores de escala sx e sy.

Veja que para o efeito ser aplicado corretamente é preciso usar uma outra transformação em conjunto – a translação. Fazemos a translação para que a posição da imagem seja transferida para a origem (ponto (0,0)) e então a escala é aplicada. Depois de desenhada a imagem, desfazemos a escala e a translação aplicando estas transformações com o valor inverso.

function aojDrawImageScale(img, x, y, sx, sy) {
    var ctx = _aojCanvas.getContext('2d');
    ctx.translate(x, y);
    ctx.scale(sx, sy);
    ctx.drawImage(img, -img.width / 2, -img.height / 2);
    ctx.scale(1/sx, 1/sy);
    ctx.translate(-x, -y);
    if (_aojShowImageCenter) {
        ctx.arc(x, y, 2, 0, 2*Math.PI, false);
        ctx.fill();
    }
}

No arquivo aojcanva.js existem outras funções deste tipo. Este arquivo e os demais estão no Zip no final da página.

Conclusão

Neste artigo vimos o basico da utilização do canvas para mostrar imagens.

No site abaixo há um guia de referência do canvas para ser impresso, com todos os comandos. O Autor (Jacob Seidelin) também escreveu um livro sobre jogos em HTML 5.
http://blog.nihilogic.dk/2009/02/html5-canvas-cheat-sheet.html

No próximo artigo veremos como implementar um game loop e utilizar o teclado e mouse.

• Visualizar o exemplo funcionando
• Baixar o código fonte do exemplo

Parece incrível e é, mas a configuração do ambiente ainda é um desafio para quem não está acostumado a trabalhar com Git, Maven, Ant e outros diretamente. Nesse curto passo a passo mostramos como configurar PlayN no Eclipse.

O projeto PlayN está passando por modificações neste exato momento. Por isso este passo a passo acabou demorando mais do que eu gostaria – depois que prometi ele, o PlayN simplesmente parou de funcionar em função da atualização da API do Android. Hoje este problema está resolvido, mas para isso o PlayN não vem mais com o pacote de samples – demonstrações do uso da plataforma. Eles poderão ser baixados separadamente em breve – quando ocorrer, informamos aqui.

[ATUALIZAÇÃO]

O PlayN está agora disponível no Maven Central, que é um repositório público. Isso facilita muito o processo todo, já que não é preciso baixar todos os fontes do PlayN para a máquina para poder utilizá-lo – só é preciso criar um novo projeto do tipo Maven e basear ele no arquétipo desejado do Maven Central.

Incluí abaixo o how-to para criar um novo projeto do PlayN no NetBeans, que é mais amigável que o Eclipse, mas o processo é praticamente o mesmo para ambos.

Todo o processo é feito em uma máquina limpa, sem nada previamente instalado. Utilizei o Netbeans 7.0.1 recém instalado e com todas atualizações aplicadas.

Os dados para o arquétipo de projeto são os seguintes:

Segue post original.

Este how-to está longe de ser à prova de falhas – muita coisa depende da configuração da sua máquina se você já tiver o Eclipse ou Maven instalado. Se você não tem nada disso, é provável que a coisa funcione sem problemas.

Um problema que tive foi o Eclipse rodar com JRE, que é run-time do Java para usuários finais, não para desenvolvimento. E com isso não conseguir compilar algumas coisas. Se você desconfiar que seu problema é esse, recomendo desinstalar temporariamente o JRE e deixar instalado apenas o JDK (versão de desenvolvimento do Java). Se o Eclipse não iniciar, por não achar mais o Java, abra o arquivo eclipse.ini (que fica na pasta do Eclipse) e acrescente a ele as seguintes linhas (são duas):

-vm
C:\Program Files\Java\jdk1.7.0_01\jre\bin\client\jvm.dll

O caminho do Java pode variar conforme sua configuração, principalmente a versão.

• Clique aqui para ver a apresentação do how-to e boa sorte.

Sites citados:

• Eclipse

• PlayN
  • Endereço do repositório para obter o PlayN:

    https://code.google.com/p/playn

• Plugin do Google para o Eclipse
  • Endereço para instalação de novo software no Eclipse:

    http://dl.google.com/eclipse/plugin/3.7

• Plugin de integração do Maven com o Web Tools Plataform do Eclipse
  • Endereço para instalação de novo software no Eclipse:

    http://download.jboss.org/jbosstools/updates/m2eclipse-wtp

• Plugin ADT (Android Development Tools) para Eclipse (não necessário para o tutorial acima)
  • Endereço para instalação de novo software no Eclipse:

    https://dl-ssl.google.com/android/eclipse/

Já vimos aqui como criar um game loop básico no post Game Loop com taxa constante de pulsos. Utilizaremos agora uma estrutura muito semelhante, de forma que é interessante dar uma olhada naquele post se você ainda não leu.

Nosso projeto terá duas classes apenas, a Main, que carrega o “jogo” (não é de fato um jogo…) e a classe Jogo, que possui um game loop onde ficamos verificando se alguma tecla, botão do mouse ou do joypad foi pressionada, mostrando a informação correspondente na tela.

A classe Main é simples, como podemos ver abaixo:

1
2
3
4
5
6

public class Main {
    public static void main(String[] args) {
        Jogo j = new Jogo();
        j.run();
    }
}

Basicamente ela cria um objeto do tipo Jogo e executa ele, chamando seu método “run”. A classe Jogo, então, é que contém todo o código interessante. Veremos seu código e a seguir a explicação dos pontos que usam o JInput (os demais pontos são explicados no post citado acima).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58

import java.awt.Graphics2D;
import java.awt.image.BufferStrategy;
import javax.swing.JFrame;
import javax.swing.WindowConstants;
import net.java.games.input.Component;
import net.java.games.input.Controller;
import net.java.games.input.ControllerEnvironment;
 
public class Jogo extends JFrame {
 
    BufferStrategy bs;
    Controller[] cs;
 
    public Jogo() {
    }
 
    public void initialize() {
        setTitle("Exemplo de uso do JInput");
        setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
        setSize(800, 600);
        setIgnoreRepaint(true);
        setVisible(true);
        createBufferStrategy(2);
        bs = getBufferStrategy();
 
        ControllerEnvironment ce = ControllerEnvironment.getDefaultEnvironment();
        cs = ce.getControllers();
    }
 
    public void run() {
        initialize();
        while (true) {
            update();
            render();
        }
    }
 
    public void update() {
        for (int i = 0; i < cs.length; i++) {
            cs[i].poll();
        }
    }
 
    public void render() {
        Graphics2D g = (Graphics2D) bs.getDrawGraphics();
        g.clearRect(0, 0, getWidth(), getHeight());
 
        for (int i = 0; i < cs.length; i++) {
            g.drawString(i + ". " + cs[i].getName() + ", " + cs[i].getType(), 50, 80 + i * 20);
            Component[] cmps = cs[i].getComponents();
            for (int c = 0; c < cmps.length; c++) {
                g.drawString(c + ". " + cmps[c].getName() + " = " + cmps[c].getPollData(), 50 + i * 200, 180 + c * 20);
            }
        }
        g.dispose();
        bs.show();
    }
}

Usando o JInput

Quando incluímos a biblioteca JInput no nosso projeto (veremos como fazer isso no final), temos algumas classes disponíveis para uso. Uma delas é ControllerEnvironment, que permite obter uma lista de todos controles disponíveis no sistema. Isto é feito da seguinte forma:

ControllerEnvironment ce = ControllerEnvironment.getDefaultEnvironment();
Controller[] cs = ce.getControllers();

Interessante notar que a JInput trata o teclado e o mouse como controles, de forma que o vetor acima terá pelo menos estes dois itens. Se você tiver um ou mais controle de jogo conectado ao sistema, então mais itens serão adicionados ao vetor, um para cada controle.

Cada controle é constituído de componentes. No teclado os componentes são as teclas; em um controle de jogo, os componentes são os eixos e os botões. Uma vez que temos um objeto do tipo Coltroller, podemos obter a lista de componentes que ele possui, com o código abaixo:

1
2
3
4

Component[] cmps = controle.getComponents();
for (int c = 0; c < cmps.length; c++) {
    System.out.println(cmps[c].getName() + " = " + cmps[c].getPollData());
}

Este código obtem um vetor de componentes do controle e para cada um deles exibe o nome e os dados lidos no último pooling. Estes dados correspondem ao estado do componente. Por exemplo, se for um botão, pode vir 1 (pressionado) ou 0 (solto); se for um joystick analógico, virá um valor entre -1.0 e 1.0, sendo que 0.0 significa que o joystick está no centro. São estes dados que vamos utilizar para comandar as ações do jogo.

Veja que, seguindo a melhor prática para leitura de dispositivos de entrada, o JInput não trabalha com eventos, mas sim com pooling. A diferença é que com eventos, quando uma tecla do teclado é pressionada, por exemplo, é gerado um evento que o jogo deve anteder – nem sempre será a melhor hora para fazer isso – podemos estar no meio da atualização da tela, por exemplo. Com o pooling a coisa se inverte: é o jogo que lê o estado do teclado quando desejar, verificando, então, se a tecla desejada está pressionada ou não.

Como JInput fazemos a leitura do estado de um objeto do tipo Controller chamando seu método “pool”. Veja dentro do método “update” da classe Jogo onde percorremos o vetor de controles chamando “pool” para cada um deles. Isso faz com que a cada volta do game loop os dados atualizados dos controles estejam disponíveis.

No método “render” percorremos novamente o vetor de controles e para cada um, obtermos o vetor de componentes. Então percorremos todos componentes mostrando na tela seu nome e seu estado atual.

Incluindo JInput no projeto

Finalmente, vejamos como incluir a JInput no nosso projeto. Baixe a biblioteca mais recente no site e dentro do ZIP você vai encontrar o arquivo jinput.jar, que é a biblioteca em Java, e vários arquivos dll e so, que são as partes nativas. Estas partes devem ser distribuídas junto com seu jogo e são a ponte entre o código Java que usamos acima e a manipulação de baixo nível do hardware em cada plataforma (.dll no Windows e .so no Linux).

Digamos que seu projeto esteja armazenado em uma pasta chamada MeuProjeto. Dentro dela deve ter a pasta de códigos fonte (src) e quando você compila e constrói, surgem as pastas build e dist (que é onde está o jogo pronto para ser distribuído). Se não existir, crie dentro de MeuJogo uma pasta lib e dentro dela coloque o jinput.jar. Os arquivos .dll e .so vão diretamente dentro de MeuJogo.

Agora utilize um comando do seu IDE para importar a biblioteca para o projeto. No NetBeans faça assim:

1. Clique com o botão direito do mouse no projeto;
2. No menu selecione propriedades;
3. Na janela de propriedades vá na seção “Bibliotecas” e clique em “Adicionar JAR/pasta”;
4. Localize o jinput.jar que está dentro da pasta lib e pronto, confirme tudo.

Ao construir (dar build), será criada uma pasta lib dentro de dist, com o jinput lá dentro. Mas será preciso copiar as dll e so manualmente. Então é só distribuir o conteúdo da pasta dist.

Conclusão

Usar um controle de jogo pode melhorar muito a experiência do usuário com certos jogos, principalmente nos gêneros de tiro, luta, corrida e plataforma.

Mas mesmo em jogos onde o teclado e o mouse são a melhor opção, o JInput é uma boa escolha porque facilita também o acesso a estes dispositivos. Criar do zero um pool para teclado e mouse é meio chato – demora pra dar o resultado desejado. O Jinput já tem tudo pronto.

Clique aqui para baixar o código fonte deste post.

Hoje vou falar um pouco sobre as Metaballs - que nada mais são do que modelos gráficos de aparência orgânica, usados para simular vários tipos de objetos não-sólidos, incluindo líquidos.

Para quem procura uma definição matemática formal, recomendo a leitura do artigo na Wikipedia. Para quem procura apenas uma forma simples de gerar este tipo de forma em Actionscript, mostrarei alguns passos simples para atingir resultados bastante interessantes.

O primeiro passo é criar uma instância de BitmapData. Apesar de ser possível criar Metaballs vetorialmente, utilizando os recursos desta classe torna o processo bem mais simples.

1
2

var bitmapData:BitmapData = new BitmapData(stage.stageWidth, stage.stageHeight);
addChild(new Bitmap(bitmapData));

As Metaballs são círculos em sua essência, e para criá-las vamos criar alguns em nosso bitmap.

1
2
3
4
5
6
7
8
9

var circle:Sprite = new Sprite();
circle.graphics.beginFill(0x000000);
circle.graphics.drawCircle(0, 0, 20);
 
for (var i:Number = 0; i < 100; i++){
var matrix:Matrix = new Matrix();
matrix.translate(Math.random() * stage.stageWidth, Math.random() * stage.stageHeight);
bitmapData.draw(circle, matrix);
}

Até então, temos apenas vários círculos bem definidos espalhados de forma randômica. O próximo passo é “misturá-los”, aplicando Blur.

O Blur faz com que as áreas entre os círculos próximos fiquem mais escuras. Áreas entre círculos muito próximos ficam mais escuras do as áreas entre círculos mais afastados, e é isto que cria efeito esperado.

1
2

var blur:BlurFilter = new BlurFilter(10, 10, 10);
bitmapData.applyFilter(bitmapData, bitmapData.rect, new Point(), blur);

O passo final é deixar a figura bem definida novamente, utilizando para isso a função threshold. Primeiramente a função é utilizada para transformar todos os pixels escuros para preto e posteriormente todos os pixels claros para branco, eliminando assim todos os tons de cinza.

1
2

bitmapData.threshold(bitmapData, bitmapData.rect, new Point(), ">", 0xFF666666, 0xFFFFFFFF);
bitmapData.threshold(bitmapData, bitmapData.rect, new Point(), "<", 0xFFFFFFFF, 0xFF000000);</code>

A partir daí, é só usar a criatividade. Apenas como exemplo, usei as Metaballs para simular uma espécie de lava que entra em erupção a cada 10 segundos.

Olá pessoal esse é o meu primeiro post como colaborador aqui no Abrindo o Jogo, e pra isso eu vou mostrar como funcionam os verlet points, que são bem legais de usar e tem como simular uma física legal e descomplicada, ou criar um sistema de partículas simples.

“O Integrador Verlet é um metodo numérico usado para simular a equação de movimento de Newton’s. É usada frequentemente para calcular trajetorias de particulas em simulações de dinâmica molecular e video games”.-Wikipedia

O ponto de verlet que vou mostrar aqui é um vetor onde mantem armazenada a sua ultima posição e a posição atual e a partir da diferença entre essas duas posições ele calcula sua movimentação futura,  se pensarmos na parte física, se um corpo em um momento T0 está na posição x e em um segundo momento T1 está na posição x1, o seu deslocamento no tempo-espaço D(x1-x) pode (não obrigatoriamente) ser considerado como sua velocidade de deslocamento no futuro.

Para demonstrar isto, vou apresentar a implementação em AS3 (uma linguagem que eu gosto muito de trabalhar para fazer jogos). A IDE que vou usar é o FlashDevelop e vocês podem utilizar o tutorial aqui do Abrindo o Jogo para baixar e instalar.

Essa primeira parte vai ser composta de 3 classes, a classe principal, a  classe VerletPoint, e o VerletStick uma classe criado pelo yoambulante que nessa primeira parte vai nos ajudar muito a ver o poder e simplicidade dos verlet points.

Primeiro a Classe VPoint que implementa o integrador de verlet:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

public class VerletPoint {
 
public var x:Number;
public var y:Number;
private var oldx:Number;
private var oldy:Number;
public function VerletPoint (x:Number, y:Number) {
 
setPos(x,y);
 
}
 
/* informa a posição do ponto*/
public function setPos(x:Number, y:Number):void{
this.x = oldx = x;
this.y = oldy = y;
}
 
/*Atualiza a posição do ponto, de acordo com o integrador de Verlet*/
public function refresh():void {
 
var tempx:Number = x;
var tempy:Number = y;
x += x - oldx;
y += y - oldy;
oldx = tempx;
oldy = tempy;
}
 
/* função que desenha o ponto na tela */
public function render(g:Graphics):void{
 
 g.beginFill(0xff8989);
 g.drawCircle(x,y,2);
 g.endFill();
}
 
}

E a classe que criada pelo yoambulante para limitar a movimentação entre dois pontos de verlet:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

public class VerletStick{
 
public var pointa:VPoint;
public var pointb:VPoint;
private var _lenght:Number;
 
public function VerletStick(a:VPoint, b:VPoint, lenght:Number = -1) {
 
pointa = a;
pointb = b;
 
if(lenght == -1){
var dx:Number = a.x - b.x;
var dy:Number = a.y - b.y;
_lenght = Math.sqrt(dx * dx + dy * dy);
}else{
_lenght = lenght;
}
 
}
 
public function contract():void {
 
var dx:Number = pointb.x - pointa.x;
var dy:Number = pointb.y - pointa.y;
var h:Number = Math.sqrt(dx * dx + dy * dy);
var diff:Number = _lenght - h;
var offx:Number = (diff * dx / h) * .5; // or /2
var offy:Number = (diff * dy / h) * .5;// or /2
pointa.x -= offx;
pointa.y -= offy;
pointb.x += offx;
pointb.y += offy;
}
 
public function render(g:Graphics):void {
g.lineStyle(1,0xff00ff);
g.moveTo(pointa.x,pointa.y);
g.lineTo(pointb.x, pointb.y);
}
 
}

E finalmente a nossa classe main que ira fazer a mágica

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

public class Main extends Sprite{
 
public function Main():void
{
  if (stage) init();
  else addEventListener(Event.ADDED_TO_STAGE, init);
 
}
 
private function init(e:Event = null):void{
 
removeEventListener(Event.ADDED_TO_STAGE, init);
createPoints();//função encarregada de criar os Vpoints;
addEventListener(Event.ENTER_FRAME, render);
}
 
//constante com o numero de verlets points que será gerado
private const NUM_POINTS:int = 10;
//vetor com os pontos, somente flashplayer 10+
private var pontos:Vector.VerletPoint;
private var sticks:Vector.VerletStick;
 
public function createPoints():void {
 
pontos = new Vector.VerletPoint();
sticks = new Vector.VerletStick();
for (var i:int = 0 ; i < NUM_POINTS; i++ ) {
pontos.push(new VerletPoint(25*(i+1),25*(i+1)));
}
 
for (var a:int = 1 ; a < NUM_POINTS; a++ ) {
sticks.push(new VerletStick(pontos[a-1], pontos[a]));
}
 
}
 
public function render(e:Event):void {
 
this.graphics.clear(); //limpa a tela
pontos[0].setPos(mouseX, mouseY); //seta o ponto 0 com a posição do mouse
for each(var s:VerletStick in sticks) {
s.contract(); //atualiza os sticks
s.render(this.graphics);
 
}
 
for each (var p:VerletPoint in pontos) {
p.refresh(); //atualiza os pontos
p.render(this.graphics);
 
}
 
}
 
}

A versão final em Flash vocês podem conferir aqui:

Espero que tenham gostado se alguem tiver problemas comenta que eu tento resolver o mais rápido possivel.

Até a segunda parte do nosso Integrador de Verlet.

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.

Um applet Java é uma classe derivada de JApplet, que por sua vez é um painel. Ou seja, não temos uma janela para nosso programa e sim um painel, que será embutido na janela de outro programa, no caso, um navegador da web.

Isso não nos permite obter um BufferStrategy para a janela, mas podemos ter o mesmo efeito criando um objeto do tipo Canvas, que é uma área de desenho que possui contexto gráfico, e criar um BufferStrategy para ele. Daí para frente usamos ele para fazer active rendering normalmente.

Outro ponto específico é que por rodar dentro de outro programa, não podemos trancar nossa thread principal com um loop infinito, como fizemos em outros exemplos aqui no blog. Isso é resolvido de forma simples implementando a interface Runnable na nossa classe e executando ela em uma thread separada.

Veja no código abaixo um applet simples que a cada volta do loop muda a cor da tela.

Arquivo Main.java

001package exemploapplet;
002
003import java.awt.Canvas;
004import java.awt.Color;
005import java.awt.Graphics2D;
006import java.awt.image.BufferStrategy;
007import javax.swing.JApplet;
008
009public class Main extends JApplet implements Runnable
010{
011    int x;
012    Canvas canvas;
013    BufferStrategy bs;
014
015    @Override
016    public void init()
017    {
018        canvas = new Canvas();
019        setIgnoreRepaint(true);
020        this.add(canvas);
021        Thread t = new Thread(this);
022        t.start();
023    }
024
025    public void run()
026    {
027        canvas.createBufferStrategy(2);
028        bs = canvas.getBufferStrategy();
029        while (true)
030        {
031            Thread.yield();
032            update();
033            render();
034        }
035    }
036
037    public void update()
038    {
039        if (++x > 255)
040        {
041            x = 0;
042        }
043    }
044
045    public void render()
046    {
047        Graphics2D g = (Graphics2D) bs.getDrawGraphics();
048        if (g != null)
049        {
050            g.setColor(new Color(x, x, x));
051            g.fillRect(0, 0, getWidth(), getHeight());
052            g.dispose();
053        }
054        bs.show();
055    }
056}

Em um applet não inicializamos variáveis nem criamos objetos no constructor. Isso porque a classe do applet pode ser criada muito antes de ser utilizada. Aliás, pode ser criada e acabar nem sendo utilizada porque, por exemplo, o usuário fechou o programa externo antes disso ocorrer. Carregar recursos no contructor do applet poderia levar a processamento realizado à toa nestes casos.

O que faz, então, é implementar o método ini(), herdado de JApplet, e fazer a inicialização nele. Esse método é chamado pelo programa externo quando o applet for ativado e iniciar sua execução.

No método init do exemplo acima o que fazemos é criar um objeto Canvas e adicioná-lo ao applet, além de desligar o repaint automatico do applet (porque vamos fazer active rendering). Também criamos uma thread nova para nossa classe e colocamos ela para rodar.

Quando a thread roda, ela chama o método run() da nossa classe. Nele criamos o BufferStrategy configurado para double buffering e obtemos uma referência a ele na variável “bs”. Veja que o BufferStrategy é criado para o objeto Canvas.

Em seguida entramos no loop infinito do jogo (game loop), que fica chamando update() e render(). Esse loop não possui controle de pulsos e frames, portanto vai rodar na velocidade máxima que a máquina suportar.

O método update simplesmente incrementa a variável x a cada vez que é chamado, zerando-a quando ela passa de 255. Essa variável será utilizada para determinar a cor a ser aplicada na tela.

A mudança da cor é feita no método render(), que desenha na tela utilizando o BufferStrategy obtido anteriormente. Primeiro é executado um setColor() passando para ele um objeto Color criado utilizando a variável x nas posições referentes às componentes vermelha (R), verde (G) e azul (B) da cor. Assim, teremos vários tons de ciz desde o preto (0, 0, 0) até o branco (255, 255, 255). Um fillRect() preenche com a cor selecionada a área total da tela.

O applet pode ser visualizada aqui: http://sites.google.com/site/nornberg/exemploapplet

Incluindo o applet em HTML

A seguir está um exemplo de página HTML com a tag <OBJECT>, que é utilizada para incluir o applet.

001<html>
002<head>
003    <title>ExemploApplet</title>
004</head>
005<body>
006    <center>
007        <object
008            width="640"
009            height="480"
010            type="application/x-java-applet"
011            classid="java:exemploapplet/Main.class">
012            <param name="code" value="exemploapplet/Main.class" />
013            <param name="archive" value="ExemploApplet.jar" />
014        </object>
015    </center>
016</body>
017</html>

Esta tag carrega o applet pelo menos no Internet Explorer, Mozilla Firefox e Google Chrome (últimas versões). Onde está “exemploapplet/Main.class” você pode substituir pelo caminho da sua classe (pacotes e classe separados por barra. Por ponto deve funcioanr também). O parâmetro “archive” contém o caminho para o JAR do applet (gerado pelo NetBeans com o comando “construir”).

Isso é só o básico, para dar a fundamentação a quem nunca criou um applet. Em próximos posts mostrarei como incluir imagens e sons no JAR, para utilizá-los de dentro do applet.

Baixe o código fonte deste artigo.

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.