Quem gosta de CUDA e Linux, sabe que não existe (a não ser que você procure na internet) suporte para CUDA nas autotools. Bom, eu procurei a um bom tempo atrás e criei um template para iniciar todos os meus projetos de CUDA e agora, não apenas estou liberando ele como um template, mas também estou criando um repositório completo sobre CUDA no meu SVN onde obviamente esse é o primeiro projeto.
Sem demoras, é possível efetuar o download e entender um pouco mais do projeto na página do projeto.
PS: Saiu a versão 3.1 com suporte a printf() em interfaces Fermin

Bom, todos nós sabemos que rand() nos retorna uma distribuição uniforme de números aleatórios, na realidade praticamente todos os geradores de números aleatórios nos retorna uma distribuição uniforme, o problema é como utilizamos. Procurando sobre isso, encontrei esse artigo que explica o motivo do “erro” de utilização e como corrigir o mesmo.
Enquanto ele não resolve o problema para geração de números aleatórios em paralelo (minha mais nova paixão), ele dá boas dicas de como solucionar isso, e provavelmente como solucionar também em paralelismo (já que o problema está na utilização e não no algorítmo).
Vale a pena dar uma lida, esse é um assunto muito importante para todos, principalmente para quem ainda gera os números dessa forma:

srand(time(NULL));
int num = rand()%max;

De acordo com essa notícia do Slashdot, a nova especificação do C++ (C++0X) será adiada para 2010 ou depois. O motivo é a sua mudança principal chamada “concepts”, que visam deixar os templates mais robustos. Honestamente eu não vi muito de C++ ainda para discutir a fundo templates, herança, polimorfismo, ou qualquer outra coisa, mas uma nova especificação sempre é bem vinda (quando bem feita, que aparentemente é o caso), e pelo que li sobre “concepts” realmente é uma coisa bem complexa, que esta sendo desenvolvida a mais de 7 anos e ainda não está pronta. Como ela será o motivo principal do atraso, ela será retirada e a nova especificação irá se focar em outras coisas (como paralelismo por exemplo).

Observers são um patrão de design muito utilizado, principalmente quando você quer que camadas superiores do seu software saibam o que aconteceu nas camadas inferiores. O Ogre usa isso para renderizar Frames por exemplo, utilizando FrameListener. Pois bem, curioso como sou resolvi ir um pouco mais a fundo e ver como se faz isso na unha em C++, descobrindo o quão simples isso é, os passos são esses:

1. Criar uma simples interface com um método que será chamado a toda atualização
2. Criar um objeto singleton que pode ser observado, adicionando as interfaces em uma lista (ou pilha, whatever), que irá chamar o método de atualização de todos as interface quando obtiver uma mudança
3. Criar um objeto que implementa sua interface.
4. A cada atualização, notificar todas as interfaces.

O código mostrado aqui (apenas trechos) está disponível via svn em:

http://svn.geekvault.org/cpp/ObserverExample

Parece mais complexo do que realmente é, a mágica toda está em básicamente dois métodos (e obviamente na organização de listener mostrada):

• InputListener::notify()
• Listener::notify()

O nome dos métodos pode variar, mas a idéia básica é que cada objeto que implementar a interface Listener, será obrigado a implementar o método notify(), que será chamado pelo Singleton InputListener.
Vamos ao código:

InputListener::notify(void)

std::set<Listener*>::iterator itr;
for( itr = listeners.begin(); itr != listeners.end(); ++itr)
(*itr)->notify();

InputFilter::notify()

unsigned int qtdChars = 0;
if(&m_sInput!=NULL)
{
std::cout << "We have the string: " << m_sInput->c_str() << std::endl;
std::cout << "That is " << m_sInput->size() << " chars wide\n";
for(unsigned int i = 0; i < m_sInput->size(); i++)
{
if((*m_sInput)[i]=='a') qtdChars++;
}
std::cout << "And we found " << qtdChars << " of the 'a' character\n";
}

InputFilter é uma classe que implementa a “complexa” interface Listener:

class Listener
{
public:
virtual void notify() = 0;
};

Onde InputFilter será definida como (no nosso caso):
class InputFilter : public Listener
{
public:
InputFilter();
~InputFilter();
void addString(std::string& str);
private:
void notify();
InputListener* input;
std::string *m_sInput;
};

E sua utilização (também chamada como main())

int main(void)
{
string str;
InputFilter* filter = new InputFilter();
do
{
cout << "Please type something:";
getline(cin,str);filter->addString(str);
InputListener::getInstance()->notify();
}while(str.compare("quit")!=0);
return 0;
}

Acreditem, não fica mais complexo do que isso. A grande sacada de Listener (ou Observers, é a mesma coisa) é que você pode criar um Singleton e não se preocupar em avisar várias classes sobre sua atualização, faça-as implementares a interface Listener, e apenas as adicione no Listener criado, quando você quiser atualizar todos, chame o método de atualização do Listener, simples assim.

Have fun.

Zarnick

Bom, eu sei que faz tempo que não aparecem trechos de códigos por aqui, culpe a falta de tempo.
Mas nada são más notícias, eu tenho um trecho aqui de um Menu 3D, com alfabeto e tudo mais Ainda estou trabalhando na documentação, mas se você possui Linux e OGRE, pode brincar um pouco já, a idéia é bem básica, existem um Zip com os .mesh representando o alfabeto (por falta de vocação em 3D e vontade, temos apenas de A-Z e 0-9), criei (estou aperfeiçoando) uma classe para cuidar de mostrar o alfabeto em um ambiente 3D e, uma classe de Menu, que utiliza esse alfabeto e umas animações bem básicas mesmo.
Esse projeto eu vou fazer um pouco diferente, vou trabalhar no mesmo até conseguir entregar um binário de exemplo para Linux e Windows e, fazer com que esse binário rode em qualquer um desses SOs, com ou sem Ogre instalado.
Para ver como está indo, o link do SVN é:

http://svn.geekvault.org/ogre/MenuFramework

Abraços, e até a próxima.
Zarnick

Bom, como prometido, temos algo do Ogre aqui

Repito que não vou fazer um tutorial sobre isso, para isso vejam a Wiki do Ogre.
Antes de mais nada, como já foi dito anteriormente, o Ogre por sí só é uma engine gráfica 3D, o que quer dizer que sim, você pode fazer seu jogo nela, mas irá faltar no mínimo iteração com o usuário, som e física (verdade, alguns jogos não precisam de física, mas ficam muito melhores com;). Quando você instala o Ogre ele vem com a parte de iteração, utilizando agora o OIS (antigamente era a SDL) e para ter uma GUI, ele utiliza a CEGUI. Com isso você já consegue fazer um jogo quase completo (isso e muita paciência), ou um aplicativo, que é o que vou mostrar aqui.

Antes de mais nada,  vamos falar um pouco sobre onde estou desenvolvendo e exatamente o que estou desenvolvendo.

Estou fazendo um programa para aprender direito como o Ogre funciona, o programa se chama OgreViewer, sua documentação pode ser encontrada aqui, ele serve basicamente para carregar uma Mesh no Ogre, iluminar, animar, testar vários materiais nela, checar performance, posicionamento, e outras coisas que é possível fazer com o Ogre. Até agora temos uma aplicação Ogre que carrega uma Mesh, ilumina, possibilita a utilização de materiais customizáveis e deixa a Mesh rotacionando para ver o efeito da luz no material. Já é um começo.
O ambiente de desenvolvimento utilizado (apesar do SVN conter um projeto do tipo Autotools para Linux), é o Code::Blocks, pois é um ambiente OpenSource que roda em Windows, Mac e Linux assim como o Ogre (a única grande alteração para rodar um aplicativo é sua inicialização na função main(), que eu não vou tratar aqui, nossos aplicativos são desenvolvidos em Linux).

Bom, antes de mais nada, você pode baixar o código fonte do programa via Subversion, em http://svn.geekvault.org/ogre/greViewer. Caso você não esteja conseguindo compilar o código, provavelmente está faltando alguma biblioteca, a única biblioteca extra que utilizo é a OgreAL, um wrapper da OpenAL para o Ogre, baixe-a, instale-a e tudo deve funcionar.

Uma vez com o código em mãos, vamos falar um pouco sobre como o Ogre funciona. O Ogre possui uma arquitetura baseada em plugins, e essa é a grande sacada deles, a grande maioria das engines gráficas utilizam apenas uma arquitetura de herança, complicando o código e tirando sua portabilidade. No Ogre, se você precisa de uma cena que utiliza BSP, basta carregar o plugin que permite isso, configurar sua cena para aceitar informações do tipo BSP e você está pronto, detalhe, isso pode ser feito em run-time.
Outra característica importante do Ogre são os Listeners, sendo que o mais importante deles é sem dúvida o FrameListener. Apesar de eu não falar sobre Padrões de Projetos, um Listener é basicamente uma classe que “ouve” por mudanças e ações nela e toma suas devidas ações. No caso do FrameListener ele possui duas funções básicas, frameStarted() e frameEnded() executam antes e após cada frame ter sido renderizado, útil para animações e tratamento de inputs .
Isso tendo falado, já podemos explicar o processo de inicialização, vamos ver a função OgreStartup::go(void)

void OgreStartup::go(void){
startLog();
createRoot();
defineResources();
setupRenderSystem();
createRenderWindow();
setupScene();
createCamera();
setupViewport();
initializeResourceGroups();
setupAudioSystem();
setupCEGUI();
setupInputSystem();
createScene();
createFrameListener();
startRenderLoop();
}

Ela é intuitiva não? Vamos passo a passo:

1. startLog(). Essa função inicia o log do Ogre
2. createRoot(). A classe Root do Ogre é a classe que controla o Ogre, precisamos iniciá-la antes de mais nada
3. defineResources(). Como o Ogre utiliza plugins e recursos externos (Meshs, texturas, particulas, etc), precisamos saber onde eles estão, essa função faz isso e os pré-carrega na memória
4. setupRenderSystem(). Aqui escolhemos se utilizamos DirectX ou OpenGL.
5. createRenderWindow(). Uma vez escolhido o sistema de renderização, criamos a nossa janela principal.
6. setupScene(). Escolhemos o plugin para construir a nossa cena, BSP, genérico, Outdoor, etc.
7. createCamera(). Criamos uma camera principal para podermos ver a cena.
8. setupViewport(). A camera precisa de um Viewport para renderizar o que ela vê, aqui criamos esse Viewport default.
9. initializeResourceGroups(). Lembra dos recursos externos no passo 3? Aqui inicializamos os mesmos na memória da GPU ou do PC.
10. setupAudioSystem(). Um jogo sem audio é bem chato não? Inicializamos o OgreAL.
11. setupCEGUI(). Inicializamos a GUI default que o Ogre utiliza.
12. setupInputSystem(). Inicializamos o OIS para termos ações do teclado, mouse e joystick.
13. createScene(). Criamos a cena para mostrar, essa função é puramente virtual, já que cada cena é diferente da outra, não temos uma cena única.
14. createFrameListener(). Cria os Listeners, também é puramente virtual, pois normalmente você terá n Listeners.
15. startRenderLoop(). Inicia o processo de renderização de cada frame.

Por hoje é só, na próxima parte eu vou explicar função por função como ela faz, e na parte 3 irei explicar como criar uma cena básica e um FrameListener básico para podermos movimentar a camera e sair do programa.

Até lá.

Bom, falar que fiquei pasmo com essa engine OpenSource de física é o mínimo. Ao procurar uma boa engine de física que rode com o Ogre de uma forma fácil e seu desenvolvimento seja voltado para o Linux, descobri Bullet. Apenas para ter uma ideia do quão ela é importante, o Blender a utiliza na sua última versão (2.48), como a engine física default para sua game-engine. Entre outras coisas que você pode ver em sua página de download (Google code) ela suporta soft-bodies, como por exemplo roupas e cordas.

Definitivamente vale a pena dar uma olhada

Ola pessoal, calma que minha faculdade está quase no fim, reta final!

Enquanto isso, gostaria de apresentar um novo projeto meu, a liblogger. Em quase todas as aplicações que eu faço eu preciso de um log, a maioria das pessoas precisa, e depois de copiar tantas vezes o mesmo código, resolvi inaugurar uma seção no meu domínio com algumas apps e APIs e, essa será a primeira a ser disponibilizada!

Todas as APIs terão uma documentação feita via Doxygen, um site via Joomla, tutoriais, e um espaço em packages.geekvault.org. Caso contrário ela estará no Sourceforge e provavelmente com sites mais personalizados, alias, esperem novidades nesse aspecto .Bom, vamos falar um pouco sobre a liblogger então.

Resumindo o óbvio, é uma API em C que estou desenvolvendo de acordo com as minhas necessidades para poder efetuar um log de qualquer aplicação ou API. O principal motivo que estou fazendo isso no lugar de utilizar alguma já existente é o aprendizado, estou usando esse projeto para aprender direito como funcionam as autotools e, assim, criar projetos portáveis para quaisquer ambientes UNIX.

As features da liblogger até a presente data são:

• Logar a data
• Logar os milisegundos
• Logar em um arquivo
• Logar em stderr
• Configuração da API via flags
• Interceptação do que iria para stderr

As próximas features que pretendo desenvolver serão:

• Logar em banco de dados MySQL
• Enviar a mensagem de log via HTTP GET, ou HTTP POST para um web-service
• Criar um conjunto de funções para ler os logs antigos

Como a ideia do projeto é estudar portabilidade, sua compilação não deverá ser mais complexa que o clássico: ./configure ; make ; make install. Sua utilização também é simples, e possui um código exemplo no site oficial e a ideia é manter a simplicidade.

A idéia toda é poder criar tanto um wraper para perror() quanto logs utilizando a mesma sintaxe de um simples printf().

Como sempre, eu não posso garantir que a ferramenta está perfeita (por exemplo, parece que ela possui um memory leak de 568 bytes, criado ao abrir o arquivo de log, talvez ela não esteja fechando o arquivo, mesmo chamando fclose() no final. Certamente outros bugs irão aparecer, para isso conto com a compreensão de enviar um email para zarnick@geekvault.org, com o subject [libtool - bug].

Bom, é isso, espero que essa ferramenta seja útil para vocês assim como está sendo para mim

Demorou, vou assumir, mas finalmente eu programei mais uma estrutura de dados simples, a árvore. Vou preparar uma explicação sobre o que é uma árvore em computação (essa pode ser um pouco complexa) e assim que eu tiver eu posto aqui, mas por enquanto vocês podem ver o código no svn (http://svn.geekvault.org/c/trees)

Have fun.

Certo dia eu estava conversando com um amigo meu sobre C e ele me falou que a coisa que ele mais odiava era ter que tomar cuidado com a ordem dos include que ele fazia quando iniciava um projeto em C. Ora, vamos pensar um pouco, se você incluir duas vezes o cabeçalho stdio.h por exemplo, em dois arquivos diferentes, e incluir os dois, não da erro certo?

O que eu quero mostrar é isso:
[arquivo1.h]
#include <stdio.h>
.
.
[arquivo2.h]
#include <stdio.h>
.
.
[main.c]
#include “arquivo1.h”
#include “arquivo2.h”
#include <stdio.h>
.
.
Claramente estamos incluindo 3 vezes o mesmo cabeçalho, como C não aceita re-declaração, isso deveria acusar um erro, porém não acusa. Cosa você esteja pensando que deve ser algo extremamente complicado, pense novamente, tudo que difere na stdio.h para os seus cabeçalhos .h é o inicio e o final. É um simples “hack” utilizando diretivas de compilação #ifndef, #define, e #endif. Siga esse modelo de cabeçalho:
[arquivo.h]
#ifndef __ARQUIVO_H
#define __ARQUIVO_H
.
.
#endif
A diretiva #ifndef checa se __ARQUIVO_H já foi definido ou não, caso não tenha sido, inclui o código até encontrar #endif, caso já tenha sido, não inclui nada até #endif. Dessa forma, contanto que __ARQUIVO_H sejá único, os problemas de redeclaração de cabeçalhos estão resolvidos.
Fica a dica.