Vão pra lá!

Haverá uma única classe nova.  Poderíamos deixar como está, mas como nossa intenção é fazer uma engine, vamos adicionar uma classe abstrata que encapsule parte do ciclo de atualização do Video, mas que tenha um método virtual que seja chamado dentro deste ciclo. Assim, o comportamento geral é aproveitado por todas as classes derivadas e comportamento específico é adicionado simplesmente sobrescrevendo um metodo.

Classes

Veremos um resumo de cada classe a seguir. Adotamos a convenção de classes auxiliares que não tenham  metodos com algoritmos complexos terão seus nomes começando com minúsculas e as demais com começam com minúsculas. métodos e atributos sempre começam com minúscula.

Classes simples que não mudarão seus atributos os deixão como public e são descritas com struct. Todas as outras usam class.

point

Esta é uma classe auxiliar, que basicamente representa uma posição no eixo (x,y) da tela. A idéia é ser o mais simples possível, então codificamos como uma struct e deixamos seus atributos públicos, para serem acessados diretamente. Não possui métodos, apenas um construtor default e um construtor que recebe o x e y.

A idéia desta classe é basicamente representar uma coordenada.

Rect

Classe que representa uma determinada area, com uma posição (x,y) e um tamanho (width, height). Atualmente a utilidade desta classe é basicamente para desenhar retangulos na tela e para copiar apenas uma parte de uma surface. Mas também pode ser útil para detectar colisões na tela. A idéia é simples, se a interseção de dois retangulos não for vazia (tiver area maior que 0), é sinal que eles colidem.

Para isso temos os métodos intersection(), que retorna a interseção entre dois Rects e empty(), que checa se area é nula (vazia). Assim, um forma de descobrir se ocorreu uma colisão seria:

if( ! (r1.intersection(r2).empty())
{
    /* colidiu */
    ...
}

Por questões de simplicidade, esta classe tem todos os atributos públicos e está escrita como uma struct. Como não planejo trasformar esta engine de 2d para 3d, esses atributos não devem mudar, o que justifica esta decisão.

color

Esta é uma classe auxiliar também. A idéia é representar uma cor no formato RGB ou RGBA.  Assim como point, esta classe é escrita como uma struct, como todos os atributos publicos.

Surface

A maior e principal classe desse módulo, representa uma surface. Uma surface é, a grosso modo, uma imagem que podemos manipular. A própria janela do programa é para a sdl uma surface. Nosso encapsulamento também vai considerar assim.

A Surface (sempre que começar em maiúsculo eu me refiro a classe) só tem um atributo, que é um ponteiro para uma SDL_Surface. Esse atributo é privado, pois vamos definir seu valor (isto a SDL_Surface para o qual aponta) no construtor. Assim no destrutor ele pode desalocar esta surface. Para garantir isso, também impedimos a construção por cópia (nada de copy constructors) e também não temos nenhum construtor público que aceite uma SDL_Surface.

Temos então dois construtores: Um que aceita uma string e carrega de um arquivo  e outro que recebe a altura, largura e bpp e Aloca ele. Ambos usam apenas as funções da biblioteca SDL. Isso implica que só podemos carregar arquivos “.bmp”. Corrigir isso é fácil se usarmos a SDL_Image, mas como me propus a usar apenas a SDL nessa primeira iteração, isso fica prar depois.

Duas funções estáticas importantes são setupScreen() e getScreen(). A primeira chama a SDL_SetVideoMode() e retorna o resultado encapsulado em uma Surface (o resultado é a prórpia tela do jogo). A segunda apeanas retorna a Surface da tela e só deve ser chamada se setupScreen() já tiver sido chamada ao menos uma vez.

Temos a função blit, que permite colar uma imagem dentro de outra. Há duas versões, uma que permite colar a imagem inteira, e outra que permite escolher uma parte da imagem.

Aí temos algumas funções básicas de manipulação de paleta, de controle de colorkey (uma cor que é ignorada na hora de desenhar), de alpha de surface (a transparencia da imagem toda). Todas são bastante auto-explicativas e por isso não vou me alongar sobre elas.

Temos funções de manipulação direta de imagem. Apesar de também serem bem auto-explicativas, temos que prestar atenção que cada função tem duas versões, uma que aceita uma unsigned e outra que aceita color. Este unsigned representa a cor no formato interno da surface, que pode variar bastante. Por isso a não ser que esteja trabalhando com paletas (8bits) é melhor evitar usar essas versões, a não ser que saiba o que esta fazendo.

E por último temos a função getInternalImageData(). Basicamente ele retorna um ponteiro para a SDL_Surface contida internamente. Se por acaso for necessário para integrar com alguma outra biblioteca, use isso.

VideoManager

Esta classe abstrata serve para administrar a sua janela. Basicamente o que ela faz é encapsular as tarefas de criar a Surface da janela (o método setup()) e de atualizar (update()) a surface. A grande utilidade desta classe está no fato do método update() chamar o método draw(screen). O método draw() é virtual puro. Isto significa que a classe VideoManager não pode ser instanciada, serve apenas como base para outra classe que só será instanciável se esta implementar o método draw.

Uma classe que herdeira que implemente draw() reaproveita o código de update, e implementa seu próprio que código de atualização, que pode incluir qualquer coisa. No core, usaremos um classe desse tipo para desenhar os objetos na tela.

Código Teste

Há um pequeno código de teste, que basicamente cria duas imagens, uma carregada de um arquivo e outra criada dinamicamente e preenchida na cor vermelha.

E a cada chamada de draw() as duas imagens são desenhadas e 1 retangulos no topo também.

Esse teste é composto de dois arquivos, “main.cpp” e “test_videomanager.h”, sendo último o principal. Ambos estão comentados em português.

Download

O código fonte e o exemplo estão aqui.

O código fonte está parcialmente comentado em inglês sofrível (é mais chique ). A partir destes comentários eu gerei uma documentação (com doxygen), só para experimentar. O resultado encontra-se aqui. Acho que é bom para consultas, mas para entender o funcionamento, é melhor olhar os fontes mesmo.

Por enquanto é só. Em breve venho aqui com o módulo de Eventos.

T+

Pensando nos componetes de um programa, normalmente temos a separação entre Lógica, e IO. Podemos utilizar está idéia, mas temos que adaptá-la pra não confundimos a lógica da engine com lógica do jogo em si. Portanto a divisão fica assim: Core contendo a lógica na engine e Resources contendo todo o tratamento de Entrada e Saída. Vamos nos concentrar nos Resources primeiro, pois sem isso não poderemos sequer testar Core.

Resource é descreve bem as tarefas testa divisão, mas podemos melhorar. Primeiro, separamos Entrada e Saida pois, em SDL, são coisas muito diferentes. A Entrada é praticamete toda coberta pelo sistema de Eventos. Por isso podemos chamar o sistema de entrada de Sistema de Eventos, que dá no mesmo. Mesmo porque na própria documentação da SDL estão agrupadas nessa categoria todas as funções básicas de entrada, mesmo aquelas que não necessáriamente precisam usar o sistema de eventos (como checar a posição do mouse ou quais teclas estão pressionadas).

Já o sistema de saída é mais complexo, uma vez que estamos falando de multimídia. Então, para não complicar, vamos separar a Saída em Vídeo e Som. Assim, cada um usa encapsula as funções da SDL que lhes diz respeito.

As funções da SDL para vídeo são bastante completas, por isso não acho que usarei nenhuma biblioteca auxiliar na primeira iteração. Já na questão do Som, devo utilizar a SDL_mixer pra tudo, pois esta auxiliar é muito completa e mais simples do que as funções de Audio da própria SDL.

Finalmente temos o Core. não há muito o que falar sobre este. ele é composto de Sprites e Cenas, e deve ter algum suporte a efeitos e transições. Questões que detalharemos quando chegar a hora de codificar.

Quanto ao desenvolvimento, a idéia é utilizar um ciclo de iterações. Eu não gosto muito dessa parte de ciclo de vida, etc, eu vou utilizar apenas idéia basica. Isto é, primeiro criamos uma versão funcional, mas bem simples. Após isto, faremos novas versões incrementando as funcionalidade já existentes e adicionando novas.

Segundo minha antiga professora de Engenharia de Software, temos que ter um plano mostrando cada fase e etc. Como eu nunca gostei muito de processos em geral, o plano vai ser bem simples:

1. Criar toda a base da engine, mas usando apenas a SDL. Isso quer dizer que o módulo de audio não será implementado na primeira interação . Mas deve ser possível fazer nem que seja um Asteroids, sem som mesmo.
2. Implementar Som
3. Implementar melhorias no Vídeo com bibliotecas auxiliares.
4. Daqui por diante eu decido depois

A organização dos arquivos vai ser simples, similar à maioria das bibliotecas: headers na pasta include, implementação na pasta source. Quanto aos módulos, vão ser inicialmente Video, Events, Core, Audio. Cada um deles vai ter um próprio namespace com seu nome.

Glosário

namespace:

Uma forma de agrupar classes e funções e evitar duplicidade de nomes. Funciona de forma parecida com o packages de Java. Os namespaces respeitam hierarquias, isto é se um namespace for declarado dentro de outro.

Qualquer item dentro de um namespace pode ser acessado da forma N::I, onde  N é o namespace e I é o item. Usando a expressão using namespace N; pode-se acessar os itens sem ter que colocar o N::, o que normalmente vai ser usado.

Então porque colocar namespaces? Simples, caso exista dois itens que tenham o mesmo nome, daria erro de compilação. Mas se estiverem dentro de namespaces, podemos acessa-los pelo namespace. Como N::I e  M::I. Logo o programa vai compilar sem problemas. Melhor que a solução antiga de C, que era colocar prefixos (como “SDL_” ), que precisam ser usados sempre, enquanto os namespaces só precisam ser lembrados quando há colisões de nome.

iteração:

Uma rodada de produção de um software. No final de uma iteração é produzido um programa funcional, mesmo que incompleto. No caso será produzida versões inclompetas da biblioteca no ínicio, que vão ficando menos incompletas no final.

Em softwares que utilizam esse método, tem que apenas que tomar cuidado para manter cada componente extensível e bem encapsulado, para evitar propragar as alterações pelo código (isto, evitar que aconteça que ao alterar A, tenha que mexer em B e C, e ao mexer em B, ter que alterar D e E, e assim sucessivamente até a loucura).

É um pouco mais complicado de começar do que um cascata (onde cada fase faz uma coisa e só segue adiante após terminá-la), mas a longo prazo, a facilidade de manutenções compensa e muito.

—-

Por enquanto é só. Se alguém tiver alguma dificuldade com algum termo do texto, é só me avisar que incluo no glosário. Este post vai ser alterado ao longo do tempo para corrigir erros de percepção e planejamento que certamente ocorrerão. Mas, estará restrito à primeira iteração. A segunda terá um post próprio que provavelmente será copiado e colado deste .

T+

Se esse tutorial do ponto V é tão bom, pode-se perguntar por que eu quero fazer outro. A resposta é simples, eu quero mostrar o forma que utilizo, mostrando algumas alternativas que podem ser úteis na escolha da configuração. Então vamos lá.

Baixando o Code::Blocks

Primeiramente eu recomendo que você vá ao site do Code::Blocks (http://www.codeblocks.org/) e procure é versão mais recente para download. Sempre há links para a versão estável e para uma versão nightly build, que são compiladas toda a noite. Infelizmente, talvez devido a sobrecarga de acesso procurando essas versões, o site costuma ficar fora do ar de ve em quando.

De qualquer forma, recomenda-se baixar a versão estável, que pode ser encontrada em http://www.codeblocks.org/downloads. Se o site estiver fora do ar, você pode ir direto à página deles no sourceforge que é http://sourceforge.net/projects/codeblocks/.

Dê preferencia para a versão que vem com o mingw. Na outra opção, o compilador não é baixado junto, sendo necessário instalá-lo separadamente depois. Essa opção só é útil se você já tiver um compilador instalado, como o Visual C++ da microsoft, senão escolha a versão com mingw que vai lhe poupar muito trabalho.

Instalando

Após baixar o Code::Blocks, a instalação é rápida. A maior parte pode ser feita usando o principio NNF (Next, Next, Finish), mas para uma melhor configuração, peço-lhe que dê uma paradinho quando chegar na seguinte tela:

Essa tela permite escolher o que vai ser de fato instalado junto com o Code::Blocks. Como todas as opções estão contidas no instalador e não é necessário fazer nenhum download adicional, você pode escolher “Full: Al Plugins, all tools, just everything” e ser feliz.

Se você quiser ser mais criterioso e economizar algum espaço no HD, você pode personalizar a instalação. Novamente cito esse post, que mostra uma boa configuração. O que eu não recomendo é usar as configurações Minimal ou Standard.

Dito isso volte ao lema NNF e termine a instalação. Você pode testar a instalação abrindo o Code::Blocks. Ele deve exibir uma tela para escolher o compilador a ser usado, mas se tiveres seguido os passos corretamente, a opção Mingw vai aparecer como “Detected”. Então é só colocar OK e seu code::blocks estará pronto para uso. Recomendo que você brinque um pouco com a interface, criando um hello world em modo Console mesmo, só para ir se acostumando com a interface, que de início não parece tão acolhedora como a do velho Dev-Cpp.

Baixando a SDL

Esse aqui é mais fácil, apenas vá ao site http://www.libsdl.org/, Procure a seção download, na categoria SDL 1.2. Você deve baixar uma das Development Libraries. Se você tiver instalado conforme o texto acima, você deve baixar o SDL-devel-1.2.X-mingw32.tar.gz, onde X é numero da versão atual (enquanto escrevo este post, X = 14).

O download é rápido, e após isto basta extrair o arquivo. Porém, precisamos extrair para algum lugar, o qual vamos discutir na próxima seção.

Mas antes disso, uma recomendação, a SDL foi feita para que pudessemos  abstrair as particularidades de cada sistema, criando uma plataforma comum para desenvolvimento de aplicativos multimídia (eu sei, esse é um nome muito anos 90, mas infelizmente é o que melhor se encaixa). Logo, por se dedicar a isso, ela deixa de lado algumas características de alto nível que fazem bastante falta. Obviamente isso não foi simplesmente deixado de lado, há bibliotecas construídas em cima da plataforma SDL que executam muito bem essas funcionalidade.

Eu destaco as bibliotecas SDL_image, SDL_mixer, SDL_ttf, SDL_gfx e Guichan, as quais uso bastante. As três primeiras são fáceis de instalar, mas requerem alguma aten;’ao. As duas últimas são mais difíceis, pois precisam ser compiladas. Por todas necessitarem algum nível de atenção especial, serão descritas em artigos posteriores.

Criando um Ambiente para o Desenvolvimento

Você poderia extrair o arquivo baixado na seção anterior em qualquer lugar. Mas você não deveria fazer isso. Obviamente o ideal colocar em um lugar de fácil acesso, de preferencia próximo onde os seus próprios projetos estarão, para facilitar uso posterior, já que vários projetos devem usar esta biblioteca. A ideia geral é criar uma pasta contendo tanto as bibliotecas como os projetos. O ideal é que esta fique na raiz da partição, para evitar problemas com ferramentas que ainda se atrapalham com nomes contendo espaço. No meu caso, esta pasta está localizada em D:\dev.

Não está no C:\ porque eu divido meu computador em 2 partições e deixo a primeira apenas para a instalação de programas. Muitas pessoas usam seu hd desse jeito, mas se você usar tudo num só, não tem problema algum usar algo como C:\dev, não precisa se preocupar em reparticionar seu hd, ou coisa parecida .

Após criar esta pasta, você pode tanto criar duas subpastas “libs” e “projetos”, ou colocar tudo na própria D:\dev mesmo. Eu utilizo a segunda opção, pois simplifica os paths, e é muito difício confundir uma lib com um projeto mesmo.

Após essa escolha, finalmente extraia o SDL-devel-1.2.X-mingw32.tar.gz para a dev (ou dev\libs). Feito isso, está na hora de abrir o Code::Blocks.

Após abrí-lo (e fechar o tip of the Day) clique File->New->Project…

Aparecereá uma tela como esta:

Escolha SDL_Project (circulada em vermelho) e clique em Go.

Então aparecerá uma tela de boas vindas, que você passar direto e ir para a tela de escolha de nome do Projeto.

Dê um nome qualquer, como TestOne no exemplo e certifique-se que o Folder seja a pasta que você criou (o \dev\) então clique em next. Agora vai aparecer uma tela perguntando a localização da SDL. O valor inicial vai ser $(#sdl). Deixe este valor.

Se for a primeira vez que você usa este Wizard, após clicar next deve aparecer uma tela como a seguir, que é o editor de Variáveis Globais. Você deve apenas informar a localização exata da sua biblioteca, como na figura:

Pode-se perguntar porque  definimos isso globalmente, e não no próprio wizard do projeto. O motivo é que isso nos poupa trabalho, pois nos próximos projetos, não necessitamos definir isto novamente, apenas deixamos aquele indicador de variável global mesmo (o $(#sdl) ).

Outra vantagem, é que se atualizarmos para uma versão mais nova, ou simplesmente mudarmos a biblioteca de lugar só precisamos ir em Settings->Global variables e atualizar valores.

Ah, usando isto também facilita a utilização do projeto em mais de um computador, pois sem isso a localização da biblioteca teria que ser exatamente a mesma, mas com isto você simplesmente abstrái a localização da bibliotecas do ponto de vista do projeto, o que pode evitar brigas entre membors de equipe que simplemente gostam de colocar suas bibliotecas em lugares diferentes. É, concordo que é um motivo meio estúpido para se birgar, mas nunca se sabe, né .

Enfim aparecerá está tela:

Simplesmente deixe como está e click finish. E então você verá que ocorrerá… Nada. Mas só aprentemente, pois se você olhar para a barra na lateral esquerda você notará que agora ha um projeto carregado. Então clique no [+] ao lado da “Pasta” source e vocÊ verá o arquivo main.cpp.

Dê dois clique nesse arquivo e ele irá se abrir. Esse arquivo contém um código genérico que carrega uma imagem e a exibe no centro da tela. O código é completo e se você tentar ele deve compilar sem problemas. Mas se tentar rodar, você verá uma mensagem de erro contendo um texto mais ou menos como esse:

O erro é simples de entender. Ele tá dando falta da DLL. E também é simples de resolver, basta copiar da pasta da SDL para a pasta do projeto. Na minha instalação ela se encontra em D:\dev\SDL-1.2.14\bin. Se você criou seu projeto com o nome de TestOne, o destino da cópia é D:\dev\TestOne.

Sim, isto é meio chato de fazer, e deve ser feito em cada projeto. Para todas as dlls que seu projeto usar (tipo, bibliotecas auxiliares, como sdl_mixer e sdl_image têm suas próprias dlls). Isso poderia ser evitado se colocássemos todas as dlls em uma única pasta e adicioná-la ao path do sistema. O artigo do Ponto V ensina a fazer isso (aqui, denovo).

Mas para programadores desorganizados e esquecidos (como eu ) têm certa dificuldade em lembrar de copiar as dlls necessárias desta pasta para a pasta do projeto, antes de distribuí-lo, o que pode resultar em um motim de jogadores raivosos em sua direção, portanto, prefiro continuar copiando dlls.

Depois de copiar a dll, basta voltar ao code::blocks e compilar o programa. Vá ao menu Build->Build and Run. Ou simplesmente pressione [F9]. Agora deve aparecer uma janela como esta:

Após isso, clique no [X] ou pressione [ESC] para sair, se tiver um console na tela, pressione qualquer tecla que ele some. E pronto, compilamos no primeiro programa em SDL.

Realmente ele não faz muita coisa de útil, mas já dá para fazer algum estudo em cima disto, pois ele carrega imagens, exibe-as e responde a eventos, que o que nós realmente faríamos em um jogo, só que em menor escala. E no próximo tutorial faremos isto, dissecaremos esse pequeno programa e entenderemos o que ele de fato faz.

Até lá.

T+

1. Escrever Tutorial de Como criar um ambiente para Criação de Jogos com SDL no Code::Blocks. Como o próprio nome sugere, apenas mostrarei como instalar o Code::Blocks e deixá-lo pronto para compilar programas usando SDL.

2. Mostrar Passo a Passo a criação de uma engine de jogos 2d. A página MiniEngine já contem um resumo da idéia, que deve ser expandida em posts e páginas em breve. A idéia é simplesmente documentar o estudo que eu estou fazendo no momento. A engine fundalmentalmente servirá para futuros projetos meus. Porém se o resultado ficar bom, a intenção é deixá-la livre para qualquer um que queira estudá-la ou mesmo usá-la.

3. Re-upar e colocar links aqui dos meus projetos do blog. Não prometo liberar o código fonte de imediato, pois a maioria está muito ruim, mas em algum momento devo mostrá-los. De qualquer jeito, o executável destes jogos serão disponibilizados soba a categoria Portfólio com ou sem código fonte.

—

Outra coisa que gostaria de comentar, é que eu coloquei uma licença Creative Commons. Mais informações no link no finzinho da barra lateral, ou na página Sobre. Não que eu queira burocratizar isso aqui, mas sim evitar dores de cabeça no futuro. Não quero nunca ter que recorrer a isso, mas como diz o ditado, o seguro morreu de velho…

E só por enquanto…

T+

Este é, na verdade, a motivação deste blog, ser um local onde possa escrever sobre minhas experiencias no desenvolvimento de jogos. A idéia é colocar aqui idéias, projetos, demonstrações tutoriais, etc.

Os assuntos devem variar um pouco, mas em geral devo falar games 2d com SDL, pois possuo uma experiencia relevante neste assunto. A pouco tempo estudei um pouco da Javar ME junto com amigos, enquanto tínhamos um pequeno projeto de jogo para celulares. O projeto tá parado no momento por vários motivos, mas é possível que eu ainda escreva algo sobre o assunto.

Um dos motivos desta parada, é que nos juntamos a um outro projeto, desta vez em XNA. Eu não tenho a menor experiencia em desenvolvimento 3d, então dificilmente falarei desse assunto, até porque, além da minha falta de conhecimento, estamos mantendo um certo sigilo.

Por fim, como já disse, eu devo realmente me focar em SDL. Entre as experiencias que tive, eu incluo alguns jogos simples. Estes jogos estão no meu antigo blog, com o tempo eu os postarei aqui, pois a maioria dos links estão quebrados, mas se alguém quiser tentar a sorte, o link é este.

Antes que alguém pergunte, eu mudei de blog por causa do nome. A falta de criatividade do antigo me desanimava até para postar, quanto mais divulgá-lo

T+