jun 122010
 
A coordenação do curso de Especialização em Engenharia de Software com Ênfase em Padrões de Software da UECE tem o prazer de convidá-lo para a Defesa de Monografia do aluno David de Almeida Ferreira, intitulada “Catálogo de Padrões para Jogos”. A defesa ocorrerá no dia 14/06/2010 (segunda-feira) a partir das 16:00 no prédio da Pós-graduação e Pesquisa em Computação da UECE. Continue reading »
mar 042009
 

Blz?

Se você não conhece o GDJCE.com está na hora de conhecer, essas últimas semanas o site tem publicado diversos artigos do antigo site ArsLudica, quem conheceu as comunidades brasileiras de gamedev por volta de 2001 a 2002 deve lembrar dele. Foi criado quando o primeiro PDJ, o qual era mantido pelo seu fundador o Geovanni da (infomaster, senão me engano) teve alguns problemas com a sustentabilidade do site e foi forçado a fecha-lo, assim diversos membros ativos da comunidade se uniram e criaram o ArsLudica, o qual foi durante muito tempo uma ótima referencia sobre o assunto aqui no brasil, chegando a fazer parcerias importantes como por exemplo com o NeHe e com GameTutorials, onde tiveram diversos artigos traduzidos para nosso idioma.

Pois bem, a novidade agora é que o GDJCE.com que apesar de se focar em encontros locais(presenciais) está meio que ampliando seu papel e está publicando os artigos que foram esquecidos por quase 04 anos na internet. Inclusive diversos dos artigos publicados são de “figuras” conhecidas das comunidades hoje.

Só para citar olha os artigos que merecem destaque:

dez 052007
 
Blz!
Dando continuidade aos post do “GoF[1]”, estou agora publicando o exemplo utilizando o padrão “Abstract Factory[2]”.

Observando o exemplo Abaixo (Veja exemplo anterior[3])

Podemos observar que o modelo proposto tem apenas quatro classes básicas (Verde Claro), e toda a criação do labirinto é feita pela classe “MazeGame”.
O padrão Abstract Factory, permite a criação de uma família de objetos relacionados sem especificar suas classes concretas, ou seja:
Vai definir uma classe base de uma fábrica, que possui os métodos de criação de um conjunto de objetos, os quais são baseados em um ponto genérico(classe base), onde permite assim que tanto a fábrica quanto os objetos a serem construídos sejam de classe que estendam a família de classe raíz.

Observando o diagrama de classe acima, podemos notar que:

  • Foi definida como fábrica base a classe “MazeFactory“, a qual define métodos para criação dos tipos básicos “Room“,”Door“,”Wall“;
  • Foi criada a classe “BombedWall” que estende a classe “Wall“;
  • Foi criada a classe “EnchantedDoor” que estende a classe “Door“;
  • Foram criadas as classe “RoomWithABomb” e “EnchantedRoom” que estendem a classe “Room“;
  • Foram criadas duas fábricas que estendem a classe “MazeFactory“, sendo elas “BombedMazeFactory” e “EnchantedMazeFactory“;
Como podemos observar a classe fábrica base é capaz de construir as peças básicas do labirinto, já a classe fábrica “BombedMazeFactory” é capaz de construir tudo que a classe “MazeFactory” faz, além de pela sobrecarga produzir objetos do tipo “RoomWithABomb” (subclasse de “Room“) e “BombedWall” (subclasse de “Wall“).
Onde para que o usuário desta classe consiga construir labirintos de um dos três tipos “Básicos”, “ComBomba” ou “Encantado” basta ele passar para a classe “MazeGame” um objeto do tipo de fábrica desejado, como podemos ver no exemplo abaixo:

// MazeFactory factory;
// EnchantedMazeFactory factory;
BombedMazeFactory factory;

Maze * aMaze = mazeGame.create(factory);

“Mudando apenas a instância da factory produzimos o que desejamos.”
Por final o resultado produzido é o apresentado na figura abaixo:


A melhor forma de entender os padrões é conhecendo sua finalidade e motivação, além de ver sua implementação, então não se esqueça de baixar o código deste exemplo e consultar os links de referência no final deste post.

Download[4]: http://downloads.sourceforge.net/pjmoo/GoF_AbstractFactory.zip

T+!
Vida Longa e Próspera!

———————————————-

Referência
[1]http://pt.wikipedia.org/wiki/Design_Patterns
[2]http://pt.wikipedia.org/wiki/Abstract_Factory
[3]http://davidferreira-fz.blogspot.com/2007/11/gof-exemplos.html
[4]http://downloads.sourceforge.net/pjmoo/GoF_AbstractFactory.zip
[5]http://pjmoo.wiki.sourceforge.net/GoF

nov 232007
 

Blz!

Na especialização estou começando a disciplina de padrões, e como ficou acertado que para prova o livro base é nada mais nada menos que o do GoF(Padrões de Projeto)[1], então resolvi estudar de uma forma diferente.
Irei implementar os padrões tendo como base o primeiro exemplo apresentado (o labirinto), para isso tive que fazer algumas adaptações nas classes básicas e incluir alguns recursos do framework GBF[2], sendo assim além de apresentar para vocês a implementação dos padrões de quebra ainda vai a utilização do framework GBF[2].
Antes de começar a publicar os padrões, resolvi montar um exemplo base, para termos idéia de como era a implementação inicial e como ela irá evoluir com o uso dos padrões.

Sendo assim pretendo na medida do possível publicar padrão por padrão.

Lembre-se para poder melhor aproveitar o exemplo você necessita:

  1. IDE:
    1. CodeBlocks[3] (Linux e MS-Windows)
  2. Compilador
    1. Linux: GCC
    2. MS-Windows: MinGW[4]
  3. Modelagem UML
    1. BoUML[5]
  4. Bibliotecas:
    1. SDL (SDL_Image, SDL_Mixer)[6];
    2. GBF;
  5. Programar em C++
  6. Exemplo:
    1. Baixe no SourceForge[7]

Podemos observar abaixo o diagrama de classes do exemplo

  • Classes Cinzas: São do Framework GBF[2];
  • Classes Verdes: É o núcleo principal do exemplo, são as classes que dão suporte para implementação de salas, paredes e portas;
  • Classe Vermelha: É a enumeração usada para definir os lados da sala;
  • Classe Laranja: É a responsável por armazenar o labirinto;
  • Classe Amarela: É a classe que monta o labirinto;
A seguir podemos ver as classe da visão de dependência, ou seja, como é o relacionamento de fato com relação aos includes (headers) e a classe que vai executar nosso exemplo:
Essas classes seguem o mesmo código da legenda anterior, a única modificação é a inclusão da Classe Rosa, que contém o método “int main” para executar nosso exemplo.
Pois é, podemos criar uma classe que irá gerar o método main ;), digamos assim quase imitando o principio do método main da linguagem em java 😉

Abaixo podemos ver o resultado da execução do nosso exemplo:

T+!
Vida Longa e Próspera!

———————————————-

Referência
[1]http://pt.wikipedia.org/wiki/Padr%C3%B5es_de_projeto_de_software
[2]http://pjmoo.wiki.sourceforge.net/GBF
[3]http://www.codeblocks.org
[4]http://www.mingw.org/
[5]http://bouml.free.fr
[6]http://www.libsdl.org
[7]http://downloads.sourceforge.net/pjmoo/GoF.zip

nov 172007
 

Blz!

Estava estes dias revisando alguns conceitos no framework GBF[1], quando lembrei que no SpaceShooter[2] tive a necessidade de determinar em runtime de que tipo de classe pertencia um dado objeto, na época resolvi com algo muito simples, criei um método chamado “getType()” que retornava um valor de uma enum (enumeração). Porém esta solução não é genérica o bastante para poder ser reutilizada, e com alguns recursos que estou planejando implementar no framework GBF, começo a ter a necessidade de poder fazer questionamentos em runtime.
Para isso o c++ tem o que chamamos de RTTI (Run-Time Type Identification) que fornece algumas poucas opções – não se compara as capacidades reflexivas que o Java possui, nessa hora que sinto falta do java – uma delas eh por meio do dynamic_cast onde ele funciona da seguinte forma:

TipoClasse * tc = dynamic_cast(objeto)

Onde em caso de erro, ou seja do objeto não pertencer a hierarquia da classe “TipoClasse” ele retorna NULL, caso contrario um ponteiro válido para o objeto do “TipoClasse”.
Resolvi então encapsular o dynamic_cast em um recurso como o “instanceOf” do Java, para isso tive que utilizar templates(generics).

Antes de vermos o código, observemos o diagrama de classes abaixo:

Observemos a classe “ObjetoBase” ela implementa as possibilidades de uso do método “isInstance”, ou seja, funcionará assim, tendo uma instância de uma classe perguntaremos a ela se pertence a um certo tipo de classe ou se é do mesmo tipo de um outro objeto.

Abaixo podemos ver a utilização do código:

Podemos destacar alguns pontos interessantes:

Se você possui um objeto e quer saber se ele pertence a uma dada classe e não possui nenhuma instância da mesma você pode fazer como na linha 30 do código.

Exemplo 1:
sprite.isInstance <Sprite> ();

Essa construção pode parecer estranha mas é comum devido o uso de templates, outras opções são caso você possua uma instância qualquer da classe ou queira cria-la, como nas linhas 42 e 46 respectivamente.

Exemplo 2:
spritePersonagem2->isInstance(new SpritePersonagem());

spriteManager->isInstance(ObjetoManager());

Porém lembramos que estes casos necessitam de um construtor público e que uma nova instância da classe será criada, o que nem sempre é possível ou de bom agrado, por isso quando não for possível instanciar ou ter um objeto da classe utilize o primeiro exemplo.

Agora poderemos ver como de fato é feita esta implementação, observemos a figura/código abaixo:


Podemos observar que a solução é bastante simples e que o código apresentado atende a:

  1. Questionar se um objeto pertence a uma determinada classe;
  2. Questionar se um objeto pertence a mesma classe de um outro objeto;
  3. Questionar se um objeto pertence a mesma classe de um outro objeto por meio de referências;

Espero que quem tenha essas necessidades possa fazer bom uso dessas informações, e lembro que ainda é possível outras implementações, dentre as quais uma que me agradou bastante foi implementar template de funções, aparentemente ficou mais legível, porém não estaria encapsulada em uma hierarquia de classes.

Não esqueça de baixar o souce[3].

T+!
Vida Longa e Próspera!

———————————————-

Referência
[1]http://pjmoo.wiki.sourceforge.net/GBF
[2]http://pjmoo.wiki.sourceforge.net/SpaceShooter
[3]http://downloads.sourceforge.net/pjmoo/ObjetoBase.zip
[4]http://www.codeblocks.org
[5]http://bouml.free.fr

out 312007
 

Blz!

Outro dia na especialização[1], disciplina de Análise e Projeto de Software Orientado a Objetos (Prof. Araújo[2]), o professor mostrou um slide que falava de herança múltipla, e apesar de programar em c++ e já ter utilizado este recurso algumas vezes, surgiram dúvidas que eu não sabia responder e nem tinha idéia do que de fato aconteceria.

Para testar as idéias, modelei o diagrama abaixo na ferramenta BoUML[3]:

A idéia, era basicamente:
Tenho uma superclasse(Veiculo), que possui atributo(cor) e métodos, e uma linha de subclasses(Terrestre e Aquatico), que no caso vão implementar um método abstrato (imprimir) onde tal método consulta o atributo cor e vai dizer qual a cor de fato.
E utilizando o recurso da herança múltipla tenho a classe “Anfibio” que herda de “Terrestre” e “Aquatico” nesta ordem, pelo que vi isso influência na chamada do construtor das superclasses.

Logo abaixo temos o projeto na ide CodeBlocks[4]


Onde abaixo teremos o conteúdo da função main:

1-Neste bloco podemos ver que foi instanciado um objeto da classe “Anfibio”, porém ele será tratado como um objeto da classe “Terrestre”.

std::cout << “Terrestre * anfiTerrestre = new Anfibio();” <<std::endl;
Terrestre * anfiTerrestre = new Anfibio();
anfiTerrestre->imprimir();
delete(anfiTerrestre);

2-Neste bloco podemos ver que foi instanciado um objeto da classe “Anfibio”, porém ele será tratado como um objeto da classe “Aquatico”.

std::cout << “Aquatico * anfiAquatico = new Anfibio();” << std::endl;
Aquatico * anfiAquatico = new Anfibio();
anfiAquatico->imprimir();
delete(anfiAquatico);

3-Neste bloco podemos ver que foi instanciado um objeto da classe “Anfibio”, porém ele será tratado como um objeto da classe “Anfibio”.

std::cout << “Anfibio * anfibio = new Anfibio();” << std::endl;
Anfibio * anfibio = new Anfibio();
anfibio->Terrestre::imprimir();
delete(anfibio);

Como resultado da execução podemos observa a imagem abaixo:

Agora os fatos:

No caso “1”, a classe foi tratada pelo compilador como se houvesse herança apenas da classe “Terrestre”, onde inclusive pegou o valor que foi configurado no construtor da classe “Terrestre”.
No caso “2”, houve o mesmo tratamento do item “1”, porém foi para a classe “Aquatico”.
No caso “3”, parece existir na memoria da classe de forma separada os dois atributos “cor” um da superclasse “Terrestre” e o outro da “Aquatico”, e para que seja compilado deve-se informar em tempo de desenvolvimento qual atributo deve ser referenciado, para isso temos que usar a resolução de escopo, por exemplo:

Terrestre::cor

Quer dizer que quero usar o atributo cor definido no espaço de memória da classe “Terrestre”, o mesmo é válido no caso de métodos, que foi o caso do “imprimir” onde a classe “Anfibio” criou o método “imprimirNovo()”, apenas para validar a idéia, sua implementação pode ser vista abaixo:

void Anfibio::imprimirNovo()
{
std::cout << “\timprimirNovo()” << std::endl;
Aquatico::imprimir();
Terrestre::imprimir();
}

O que posso observar é que se tivermos que trabalhar com herança múltipla de uma mesma familia de classe podemos ter alguns problemas, mas que são facilmente contornados utilizando a resolução global, pelo menos no caso do compilador GCC, ele não permite compilarmos se houver algum problema de resolução, como no seguinte caso:

Anfibio * anfibio = new Anfibio();
anfibio->imprimir();

Qual imprimir deve ser chamado? afinal a classe “Anfibio” não implementou o método imprimir, o qual existe nas suas duas superclasses.

O compilador nos obriga a fazer essa construção, que pode parecer “feia” ou “estranha”, mas resolve o problema 😉

Anfibio * anfibio = new Anfibio();
anfibio->Terrestre::imprimir();

Ou seja, novamente o nosso amigo “::” (operador de resolução) entra em cena para facilitar a vida do compilador e a nossa.
Com isso eu tenho em mente que pode dá trabalho programar com herança múltipla, porém não é esse bicho de sete cabeças que ouvimos dos nossos amigos(que trabalham com linguagens que não suportam este recurso).

Trabalho com Java e já me acostumei com o uso de “Interface”, apesar de achar que algumas vezes um herança múltipla seria de grande ajuda 😉

T+!
Vida Longa e Próspera!

Observação:
Quem se interessar pode entrar em contato que mando os arquivos de projeto (bouml e codeblocks) para compilarem e brincarem a vontade. (Infelizmente não da pra fazer upload pro blog.)

Observação2:
Passei! Valeu pelo apoio dos amigos que me incentivaram a fazer a prova final da disciplina (no lugar do trabalho) 😉
Melhor nota impossível “10”, agora realmente tem nem como fazer o trabalho pra melhorar a média 😉

———————————————-

Referência
[1] http://www.pgcomp.uece.br/index.php?option=com_content&task=section&id=6
[2] http://www.secrel.com.br/araujo
[3] http://bouml.free.fr
[4] http://www.codeblocks.org

out 252007
 

Blz!

Conforme foi sugerido, um amigo perguntou o que de fato era a interface gráfica que eu havia desenvolvido, então resolvi falar um pouco sobre ela e mostrar a versão atual que agora é parte integrante do framework GBF (Gamework’s Brazilian Framework).

O GBF é um framework em C++, criado para o desenvolvimento de jogos 2D (jogos estilos: nes/snes e mega), seu foco é no uso da programação orientada a objetos além de ser multiplataforma (é compatível para compilação em ms-windows e gnu/linux) e poder ser utilizado em jogos que exijam pouco hardware, confesso que posso estar saindo deste trilho, mas por vez ou outra, volto para otimizar o framework e testa-lo no outro pc que tenho (AMD K6-II 500mhz / 192mb RAM / GeForce 2 MX 400 64 mb).

Tem algum tempo que voltei a mexer no projeto “pancada”, o qual nasceu junto com o framework (por volta de 2004) porém ficou meses(anos) parado e surgiu a necessidade de eliminar aquela codificação chata de preparar as janelas de dialogo, como aquelas telas de vitória, créditos e afins.

Sendo assim comecei a rascunhar (como pode ser visto nos links no final deste post) algumas possibilidades para criação de uma interface gráfica bem simples, que visavam só apresentar um texto dentro de uma área de tela, a qual chamei de janela, e que algumas vezes tivesse um botão “OK” para fechar, para não inchar o desenvolvimento com mil e uma possibilidades, tomei como política básica o de desenvolver/suportar apenas o que de fato é necessário, tentando assim talvez otimizar e ganhar um pouco de performance, futuramente pode ser que adicione outros botões (como os utilizados em jogos de RPG/Quests) por hora não é o foco.

Vamos para de enrolar, e mostrar logo como a coisa funciona.
Abaixo podemos ver o diagrama de classes das janelas

O que de fato acontece é que o desenvolvedor utilizando o framework faria apenas isto:

//Criando um padrão visual com janela transparente - segue o pattern Prototype (GoF)
UserInterfaceVisualImagem *uiVisualImagem = new UserInterfaceVisualImagem();
uiVisualImagem->setCorBorda(255,0,0);

//ou caso seja o desejo utilizar uma janela de cor solida (fundo de uma única cor)
//sendo necessário apenas passar para o método "setVisual".
UserInterfaceVisualSolido * uiVisualSolido = new UserInterfaceVisualSolido();
uiVisualSolido->setCorBorda(255,0,0);
uiVisualSolido->setCorFundo(100,200,100);

UserInterfaceWindowTitulo *janelaAjuda;
janelaAjuda = new UserInterfaceWindowTitulo();
janelaAjuda->setPosicao(40,50);
janelaAjuda->setDimensao(560,400);
janelaAjuda->texto.setFonte("texto");
janelaAjuda->texto.setChaveTexto("tela_ajuda_%02d");
janelaAjuda->titulo.setFonte("menu");
janelaAjuda->titulo.setChaveTexto("titulo_ajuda");
janelaAjuda->setVisual(uiVisualImagem->clone());
janelaAjuda->adicionarBotao(new UserInterfaceBotao("menu","botao_enter",SDLK_RETURN));
janelaAjuda->inicializar();

UserInterfaceVisualImagem *uiVisualImagem = new UserInterfaceVisualImagem();
uiVisualImagem->setTipoBackground(BACKGROUND_LINES);
uiVisualImagem->setCorBorda(255,0,0);

UserInterfaceWindowTitulo janelaCredito = new UserInterfaceWindowTitulo();
janelaCredito->setPosicao(40,50);
janelaCredito->adicionarBotao(new UserInterfaceBotao("menu","botao_enter",SDLK_RETURN));
janelaCredito->inicializar();
janelaCredito->setDimensao(560,400);
janelaCredito->texto.setFonte("texto");
janelaCredito->titulo.setChaveTexto("titulo_credito");
janelaCredito->setVisual(uiVisualImagem->clone());
janelaCredito->titulo.setFonte("menu");
janelaCredito->texto.setChaveTexto("tela_credito_%02d");
A classe “UserInterfaceVisualImagem”, provê o efeito do fundo da janela, o qual aparenta ser transparente, talvez até por meio do canal “alpha”, porém muito pelo contrario, a questão é muito simples, ele desenha no fundo da janela uma imagem, que possui alguns pontos que são transparentes, definido pelo que chamamos de colorkey, onde uma cor(RGB) é mapeada para não ser desenhada, no caso o mais comum é a magenta RGB(255,0,255), essa é uma técnica simples que possivelmente é mais rápida para desenhar que a utilização do canal alpha, ganhando talvez alguns pontos de performance. A figura em questão que possui alguns padrões de “transparência” pode ser vista abaixo, e a seleção de qual utilizar é baseada na enumeração “UserInterfaceVisualTipoBackground”.

Na classe “UserInterfaceWindow” e “UserInterfaceWindowTitulo” existe os atributos “texto” e “titulo” o qual possibilita a utilização do recurso de “localização”, que é a mudança de idioma nos textos de acordo com o sistema operacional do usuário(no caso o jogador), para finalizar o método “inicializar” realiza os ajustes finais para determinar algumas características que devem ser executadas apenas uma vez ou o menos possível.

Após entender assim, mesmo por cima o que deve ser feito, temos a parte importante que é “Como de fato eu uso e desenho a janela”, bem para isso vou mostrar o código:

void Jogo::menuCredito()
{
rameLayerManager::getInstance()->getFrameLayer("background")->desenhar();

janelaCredito->executar();

if (janelaCredito->isBotao(UserInterfaceWindow::BOTAO_OK)){
setMenuPrincipal();
}
Este metodo “menuCredito” é provido por meio de uma classe chamada GAT (GBF Application Template) a qual tem o uso apenas recomendado, de fato começa a oferecer uma estrutura pronta para utilização do GBF.

Neste método podemos observar uma chamada ao “FrameLayerManager” (é um singleton), no caso esta chamada é apenas pq queríamos desenhar o cenário do jogo abaixo da nossa janela. (Ver Figura 1)

O desenho de fato da janela é feito pelo método executar, o qual cuida de renderizar o que for necessário da janela e seus componentes. (Ver Figura 2)

O método “isBotao” verifica se o botão “OK”, único suportado no momento foi acionado ou não, (o botão responde pelo código das teclas definida no SDL), onde caso seja acionado executará os comandos informados (Só a título de curiosidade este método faz o sistema de máquina de estados do GAT retornar ao exibição do menu principal).

Para finalizar podemos entender que o que chamamos de janela, basicamente é uma região da tela, a qual podemos fazer alguma manipulação, no caso da GBF e do Pancada tudo que necessitamos é desenhar as bordas da janela, uma imagem de fundo com efeito de “transparência”, que seja capaz de exibir alguma mensagem(texto e título) e que possa responder ao acionamento de algum botão.

Caso tenham interesse em saber mais detalhadamente como funciona ou detalhes da implementação podem entrar em contato 😉

Figuras Anexas
Figura 1: Tela do Menu Principal

Figura 2: Tela de Crédito


T+!
Vida Longa e Próspera!

———————————————-

Referência
[1]http://davidferreira-fz.blogspot.com/2007/09/gbf-interface-grafica-v05.html
[2]http://davidferreira-fz.blogspot.com/2007/09/rascunho-de-interface-grfica.html
[3]http://pjmoo.wiki.sourceforge.net/
[4]http://pjmoo.wiki.sourceforge.net/GBF
[5]http://www.libsdl.org

set 172007
 

Blz!

Dando continuidade ao desenvolvimento da interface gráfica para as mensagens no Pancada[1], consegui um novo rascunho de classes as quais possuem uma abstração mediana, visto que resolvi especializar conforme a demanda, para não adicionar tantas classes no framework GBF[2] que acabem não sendo uteis, apresento abaixo o resultado das novas classes de interface gráfica e um pequeno exemplo do que mudou na forma de se fazer as “caixas de mensagens”, as quais são bem simples porém era chato de fazer.
//Criando um padrão visual com janela transparente - segue o pattern Prototype (GoF)
UserInterfaceVisualImagem *uiVisualImagem = new UserInterfaceVisualImagem();
uiVisualImagem->setCorBorda(255,0,0);

//ou caso seja o desejo utilizar uma janela de cor solida (fundo de uma única cor)
//sendo necessário apenas passar para o método "setVisual".
UserInterfaceVisualSolido * uiVisualSolido = new UserInterfaceVisualSolido();
uiVisualSolido->setCorBorda(255,0,0);
uiVisualSolido->setCorFundo(100,200,100);

UserInterfaceWindowTitulo *janelaAjuda;
janelaAjuda = new UserInterfaceWindowTitulo();
janelaAjuda->setPosicao(40,50);
janelaAjuda->setDimensao(560,400);
janelaAjuda->texto.setFonte("texto");
janelaAjuda->texto.setChaveTexto("tela_ajuda_%02d");
janelaAjuda->titulo.setFonte("menu");
janelaAjuda->titulo.setChaveTexto("titulo_ajuda");
janelaAjuda->setVisual(uiVisualImagem->clone());
janelaAjuda->adicionarBotao(new UserInterfaceBotao("menu","botao_enter",SDLK_RETURN));
janelaAjuda->inicializar();

Onde o uso da janela criada se da da seguinte forma:

void Jogo::menuAjuda()
{
    FrameLayerManager::getInstance()->getFrameLayer("background")->desenhar();

    janelaAjuda->executar();

    if (janelaAjuda->isBotao(UserInterfaceWindow::BOTAO_OK)){
        setMenuPrincipal();
    }
}

Para efeito de comparação logo abaixo um exemplo de como era criada a tela do menu ajuda:

void Jogo::menuAjuda()
{
    char textoFormatado[30];
    FrameLayerManager::getInstance()->getFrameLayer("background")->desenhar();

    for (int i=0; i>;11;i++){
        writeSystem->escreverLocalizado("texto",70,120+(26*i),textoFormatado);
    }

    frameworkGBF->writeSystem->escreverLocalizado("menu", 220, 88,"titulo_ajuda");

    if (desenharBotaoEnter()){
        if ((frameworkGBF->inputSystem->teclado->isKey(SDLK_RETURN))
        || (frameworkGBF->inputSystem->joystick->isButtonA())){
            setMenuPrincipal();
        }
    }
}

Logo abaixo:

  • Janela com fundo transparente
  • Janela com Fundo em cor Sólida

E para matar a curiosidade o novo rascunho do diagrama de classes “ainda não integrante do GBF” pode ser visto abaixo:

T+!
Vida Longa e Próspera!

———————————————-

Referência
[1]http://pjmoo.wiki.sourceforge.net/Pancada
[2]http://pjmoo.wiki.sourceforge.net/GBF

set 092007
 

Blz!
Faz um bom tempo que não publico nenhuma novidade sobre meus projetos, porém isso não significa que eles estão parados, muito pelo contrario, é tanta coisa pra fazer que não está sobrando tempo pra ficar atualizando.

Tem algumas semanas que voltei a trabalhar no Pancada (assim que possível publico alguma coisa sobre ele), e comecei a ter a velha dificuldade de montar aquelas telas (créditos, ajuda, sobre, final de fase, gameover e etc), então resolvi criar vergonha na cara e comecei a rascunhar componentes que facilitassem minha vida para montar uma espécie de caixa de texto, que nada mais é do que exibir um texto na tela.

Abaixo é possível ver o modelo uml (rascunho) do que vai se torna parte integrante do GBF, porém, só passa de fato para o framework após validação inicial com um projeto, o que deve acontecer nos próximos dias (ou semanas) ai então irá compor o framework e servir de base para um refatoramento das classes de interface Gráfica ou seja classes da série “UserInterface” do GBF.

T+!
Vida Longa e Próspera!

maio 282007
 

Para quem não sabe CodeBlocks[1] é uma IDE para C e C++ multiplataforma, disponível para MS-Windows e Linux.
Vale a pena uma pequena observação, apesar da IDE estar aparentemente congelada no tempo, pois o último release oficial foi em 2005, isso não quer dizer que a ferramenta esteja estagnada, muito pelo contrario nesse final de semana a revisão no controle de versão do projeto chegou na incrível marca de 4000 (quatro mil), isso mesmo quatro mil revisões num projeto, podemos concluír então que é um projeto que está em pleno vapor.
Quanto aos releases oficiais, estes foram congelados para que a equipe de desenvolvimento pudesse arrumar algumas coisas internas da ferramenta, e acredito que em breve devem lançar não mais a versão 1, e sim provavelmente a versão 2.0 ou maior pois houve muitas mudanças tanto internas quanto externas da ferramenta.
Só pra ressaltar a equipe lança quase que diariamente um build noturno[2], ou seja, todo dia ao final do trabalho, se o código estiver estável (compilavel) eles geram algumas versões do programa para o pessoal poder baixar.
No meu caso utilizo o CodeBlocks para desenvolver meus jogos, e para isso gosto de contar com a versão mais recente possível das ferramentas, sendo assim, acabo tendo que pegar o código do svn e compilar, principalmente para meu linux, pois não há builds noturnos para o Slackware.
E como esse final de semana estive atualizando meu slackware 11.0 para o current (11.1) e tive que recompilar algumas coisas, e mexendo na Internet acabei aprendendo a criar pacotes para o Slack, então agora eu disponibilizo para a Comunidade o CodeBlocks-by-FZ[3]

Arquivo Genérico (Acredito que possa ser usado em qualquer GNU/Linux)
http://codigolivre.org.br/frs/download.php/5830/codeblocks-rev_4000-i686-FZ.tar.gz

Pacote para Slackware 11.0
http://codigolivre.org.br/frs/download.php/5829/codeblocks-rev_4000-i686-6FZ.tgz

Nota:

Até o próximo final de semana devo lançar um novo pacote, enquanto isso, fiquem avisados!

O pacote para slackware instala o codeblocks com base em “/usr/local/”, por alguns problemas de tempo, não pude corrigir a instalação para que fique no local correto que seria em “/usr/”, porém não creio que seja algo que deva gerar impedimento para utilizar este pacote, basta um simples “upgradepkg” para que o problema da localização anterior seja corrigido.

T+!
Vida Longa e Próspera!

———————————————-

Referência
[1] CodeBlocks – http://www.codeblocks.org
[2] Build Noturno – http://forums.codeblocks.org/index.php?board=20.0
[3] CodeBlocks-by-FZ – http://pjmoo.codigolivre.org.br/wiki/index.php/CodeBlocks