No segundo post da série UML na Prática – Diagrama de Classe, vamos falar sobre os relacionamentos entre as entidades. Os relacionamentos básicos possíveis são as associações, generalizações e dependências.

1. Associações

As associações são relacionamentos entre as classes e podem definir seus comportamentos. Estas relações fazem com que as classes tenham conexões fisicamente ou conceitualmente, e alterações refletem na programação diretamente.

Quando construímos as associações estamos definindo os conceitos que irão definir como nosso código será estruturado e interligado. É importante saber que as associações se comportam de uma forma na teoria, mas na prática podem se comportar de outra forma se o programador não tomar cuidado para respeitar o UML.

1.1. Agregação( é parte de , todo/parte , consiste em, contém, é contida)

Tipo de associação onde um objeto faz parte de outro objeto maior( o todo ), sendo que esta parte não é totalmente dependente do todo, isto é, a parte sobrevive sem a existência do todo. Na literatura você pode encontrar tipos de agregação, mas estes tipos mantém a idéia básica, eles apenas especificam comportamentos especiais/específicos.

Na agregação o todo pode ser uma classe que representa um objeto composto por outros objetos, como uma vila pode ser composta de construções.

Agregação

#include<iostream>
#include<Modelo.h>
...
void Vila::adicionar(Construcao* obj) {
...
   construcoes.add(obj);
...
}
...

1.2. Composição(está contida, faz parte, pertence)

Este relacionamento é similar ao anterior, só que mais forte. Nesse caso, a parte só existe e faz sentido com o todo.  A parte é criada e destruida com o todo, como por exemplo um objeto 3D pode ser formado por um conjunto de Nós. Cada nó, pertencente ao objeto, só existe se o objeto existir.

Composição

#include<iostream>
#include<Modelo.h>
...
void Modelo::carregar() {
...
   No* no = new No();
...
   nodos.add(no);
...
}
...

2. Generalizações

as generalizações são formas de permitir que certos objetos sejam mais específicos. No caso, podemos ter uma classe Objeto que possuí os métodos básicos de um objeto da cena, mas podemos criar um objeto mais específico como ObjetoVoador onde podemos definir novas características.

Desta forma é possível manter compatibilidade na adição de novas classes mais especializadas e permite um controle maior do universo, como no exemplo anterior onde poderíamos definir limites diferentes de deslocamento para objetos voadores.

Generalização

#include<iostream>
#include<Modelo.h>
...
class Objeto {
...
};

class ObjetoAquatico: public Objeto {
...
};

class ObjetoAereo: public Objeto {
...
};

class ObjetoTerrestre: public Objeto {
...
};
...

As generalizações são as famosas heranças, podendo ser simples ou composta. A herança simples acontece quando um objeto herda características de apenas um outro objeto, já na composta as características são herdadas de dois ou mais objetos.

3. Dependências

As dependências são relacionamentos utilizados para informar e alertar o desenvolvedor. Esse tipo de relação alerta que a alteração de uma classe ou módulo pode afetar o funcionamento de outra. Ela informa porque diz ao desenvolvedor que uma classe faz uso de alguns serviços fornecidos por outra, deixando claro a necessidade de algum teste da existência da classe que fornece os serviços.

Dependência

No caso acima o pacote Gráfico utiliza serviços do pacote Utils, estes serviços podem ser manipulação de arquivos, plugins e etc. Caso o pacote Utils não exista, o pacote Gráfico não poderá funcionar 100%, nesse caso seu funcionamento pode ficar comprometido ou limitado. O tratamento de erros e validações pode variar conforme o caso, de um simples if até simplesmente o não funcionamento do pacote.

Para exemplificar melhor, vamos supor que o pacote Gráfico utilize o pacote Utils para fazer leitura de arquivos dos objetos 3D. Caso o pacote Utils não exista pode acontecer os seguintes casos:

1. Os objetos 3D nos arquivos não são carregados e apenas objetos já em formato de código são carregados, o programa continua sendo executado.
2. É exibido um erro e o programa não continua sua execução.

Perceba que no caso acima a falta do pacote Utils pode gerar dois resultados, onde o programa continua sua execução no primeiro caso ou termina sua execução no segundo. Por este motivo este tipo de relacionamento deve ser especificado durante o planejamento de sua arquitetura, o que acontece quando a relação de dependência não é satisfeita?  Essa pergunta deve ser respondida antes da implementação.

O Frame Rate

Um ponto delicado nos jogos e aplicações é o frame rate. Para muitos, valores altos significam maior qualidade, mas as coisas não são fáceis assim.

O frame rate é o tempo que a placa leva para exibir uma cena na tela. Como este tempo pode ser absurdamente pequeno, o frame rate é calculado em segundos. Então, quanto mais cenas renderizadas e exibidas por segundo maior será o frame rate. Por usar os segundos para medir a quantidade de cenas renderizadas usamos o termo frame rate per secund, ou apenas FPS.

Então, o motivo pelo qual algumas pessoas acreditam que quanto maior o FPS melhor está associado a questão de velocidade, quanto mais FPS mais rápido é o hardware, e quanto mais rápido melhor.

Nem sempre necessitamos de altas taxas de FPS, na realidade o FPS é utilizado para medir a fluidez da ação. Num jogo de cartas, não existe a necessidade de um FPS muito alto o tempo todo, pode-se utilizar um fps maior nas animações de embaralhar cartas e distribuir. Em outros jogos, como de ação, a quantidade de FPS exigida é maior devido a uma constante atualização da cena.

Então, quando alguém falar que seu jogo deve ter 60fps, leve em consideração a quantidade de atualizações na cena, este tipo de cuidado pode aperfeiçoar sua aplicação e garantir tempo livre do processador, sem contar trabalho desnecessário para gerar cenas iguais.

Arquitetura e funções

Ao escolher uma placa é importante conhecer a arquitetura básica e suas funcionalidades. Nós vimos anteriormente que as placas modernas suportam openGL da mesma forma que o Direct3D. Por uma simples razão: o pipeline 3D é o mesmo, não importando qual API é utilizada. Portanto, as características técnicas das placas 3D são válidas para as duas APIs. Vamos lá, vamos começar a analisar nosso hardware.

O primeiro de tudo, vamos olhar um esquema de hardware simplificado que está presente nas placas de vídeo. Este esquema é válido para todas as placas. Pode-se distinguir 3 componentes principais: A GPU, a memória ram do vídeo e o RAMDAC(em desuso).

O RAMDAC

Vamos entender o que é o RAMDAC (Random Access Memory Digital Analogic Converter). O RAMDAC permite converter dados numéricos do frame buffer em dados analógicos para serem enviados para a tela. O desempenho do RAMDAC, dado em Mhz, deve ser estudado com cuidado. A freqüência de funcionamento do RAMDAC é calculada levando em consideração a resolução final e a freqüência vertical do monitor na seguinte relação: Freq RAMDAC= largura * altura * Vfreq * 1.32

A largura e a altura são, respectivamente, a largura e altura em pixels da tela (1024×768, 1280×1024, etc.), a Vfreq é a freqüência de atualização da tela e 1.32 é um fator que leva em conta a inércia dos tubos de raios catódicos. Vale lembrar que os monitores LCDs não utilizam este componente.

A memória de Vídeo

Agora, vamos dar uma olhada na memória de vídeo. Esta memória tem como principal função armazenar dados para o processador gráfico, a GPU. Então a quantidade de memória pode ser um fator importante? Não necessariamente. Mas quais os dados armazenados exatamente?

Para aplicações clássicas, como editores de texto, os únicos dados armazenados são o conteúdo das telas. Estes dados ficam em uma área particular chamada frame buffer. Nossas telas de computador permitem visualizar o conteúdo do frame buffer diretamente(para telas numéricas como o LCD).

Vamos supor que estamos utilizando uma resolução de 1600×1200 no modo true color, isto quer dizer que cada pixel é mostrado na tela com 3 bytes (1 byte para cada componente de cor RGB, Red Green e Blue). A quantidade de memória necessária para o frame buffer é: 1600 x 1200 x 3. O resultado é pouco mais de 5.6MB. Então vem a pergunta, é necessária uma placa de vídeo com 256MB? Mas e se estivermos usando para aplicações gráficas?

Quanto trabalhamos com aplicações 3D a memória é utilizada com maior freqüência, e não só para armazenar a tela, mas para outras funcionalidades. Para isto a memória é dividida em zonas. Existem 5 grandes zonas:

• O Frame Buffer: Aqui é onde a imagem definitiva é exibida na tela. Alguns chamam essa área de color buffer.

• Back Buffer: é a área da memória onde armazenamos a cena enquanto estamos trabalhando nela. Quanto terminamos sua renderização o back buffer torna-se o frame buffer e vice-versa. Esta técnica é conhecida como double buffering. O back buffer tem o mesmo tamanho do frame buffer.

• Os buffers depth, stencil e accumulation: Os buffers depth e stencil são fundamentais para a renderização de cenas 3D. O primeiro, depth buffer, é capital, é graças a ele que podemos exibir objetos 3D de forma adequada, ou seja, os objetos mais distantes não são exibidos na frente dos mais próximos da camera. O depth buffer é também chamado de Z-Buffer, sendo responsável por armazenar informações de profundidade da cena. O stencil buffer é muito empregado para todos os tipos de efeitos gráficos dos quais se destacam o volume por sombra. O accumulation buffer, é usado principalmente para efeitos de soft-focus em tempo real. O tamanho do depth buffer depende da sua precisão de teste, 16 ou 32 bits. No último caso, o tamanho do buffer de profundidade(z-buffer) é calculado pela altura x largura x 4.

• O vertex buffer: Área da memória onde os vértices dos objetos 3D são armazenados (VBO ou Vertex Buffer Object no openGL). Seu tamanho é variável.

• O texture buffer: Esta área é a maior porque é nela que todas as texturas usadas pela aplicação 3D serão armazenadas. Quando se sabe que uma textura de 2048×2048 em 24 bits ocupa cerca de 12Mb, é fácil entender porque o texture buffer tem uma cota maior da memória de vídeo.

Com estas informações podemos calcular o quanto de memória uma aplicação 3D usando 4 texturas de 2048×2048 de 24 bits, mostrada numa resolução de 1600×1200 em 24 bits, e usando a técnica de double buffer ocupa.

mem_occupada = 2048*2048*3*4 + 1600*1200*3*2 + 1600*1200*4

men_ocupada = 60MB

Então sabemos porque as placas estão aumentando a quantidade de memória ram, mas também aprendemos que a quantidade não está relacionda a capacidade de placa, afinal uma FX5200 com 1G nunca será superior à uma FX5900 com 512M.

A GPU

A GPU é o principal componente das placas de vídeo. Ela é responsável pelos cálculos 3D realizados, de transformações à efeitos. Também é na GPU que os triângulos são transformados em pixels no formato do frame buffer.

Mas, por que triângulos? A resposta é simples, 3 pontos sempre irão formar um triangulo no espaço 3D, e essa garantia torna desnecessária a criação de código para validar a forma, tornando-a mais rápida de se desenhar. Imagine se no lugar de triângulos fossem usados quadrados.

Quatro pontos não definem um quadrado

Como pode ser visto na imagem acima, 4 pontos no espaço não necessariamente formam um quadrado. Para usar quadrados seria necessário um código para validar sua forma e garantir que sempre seria um quadrado.

A GPU é responsável por diversas funções, e para identificar quais funções elas são capazes de realizar é necessário conhecer a nomenclatura dada por cada fabricante, ou olhar as especificações da placa.

Agora que conhecemos o básico das placas de vídeo, nos próximos tutoriais sobre o assunto vamos abordar a programação da GPU.

ciao

Neste post vou tentar transcrever um antigo post de um sitio que não me recordo mais. Então fica registrado que o texto abaixo é baseado na lembrança de um post de outro local que tentarei localizar mais tarde.

O Papel da Placa de Vídeo

Para o 3D em tempo real a renderização de cenas é a parte mais importante, este processo deve ocorrer com o máximo de credibilidade possível. Esta credibilidade é associada, atualmente, com a realidade e a fluidez da cena renderizada. A realidade está associada as texturas e técnicas de iluminação utilizadas, e a fluidez à quantidade de frames por segundo (FPS) em que a cena é exibida.

Para alcançar maior credibilidade, programadores são obrigados a escreverem códigos cada vez mais complexos, e com maior necessidade de processamento, para que estes efeitos sejam cada vez melhores e com o mínimo de perda no desempenho.

Antigamente este processamento gráfico era feito pelas CPUs. Nos anos 90 a Nvidia, então conhecida pelos chipsets RIVA, mudou a forma como as coisas funcionavam e introduziu sua placa GeForce 256 no mercado. A mudança trazida pela nVidia foi a retirada dos cálculos gráficos da CPU e transportada para outra central de processamento, a GPU (Graphics Processing Unit, Unidade de Processamento Gráfico). Pouco tempo depois a ATI, empresa concorrente da Nvidia, lançou suas placas com o conceito de VPU (Visual Processing Unit, Unidade de Processamento Visual). O acrônimo sobrevivente foi o GPU da nVidia.

A novidade trazida pela GeForce 256 foi a T&L, ou Transform & Ilumination (módulo de Transformação e Iluminação). A T&L é uma pequena unidade de cálculo, seu único papel é assumir a carga de cálculos necessários para a transformação dos vertices e a iluminação aplicada aos mesmos. Os cálculos realizados pela T&L são vetoriais e de bitmap. A idéia, portanto, foi transferir os cálculos para uma placa especializada, a de video.

Os Shaders Programáveis

No início, as funções T&L e os módulos de texturização eram implementados e gravados em chips de silício e acoplados ao hardware, tudo de forma definitiva. Rapidamente os desenvolvedores notaram que apesar das diferentes texturas utilizadas nos jogos, o contexto gráfico geral das cenas continuava igual. Isto acontecia porque as técnicas de renderização e texturas eram sempre as mesmas, as que acompanhavam as placas. Os resultados gráficos obtidos começavam a desagradar os desenvolvedores, porque impedia a diferenciação gráficas dos jogos, otimizações e personalização nos jogos(dentro do contexto das operações realizadas pelas placas) comprometendo a credibilidade das cenas e identidade dos jogos.

Para resolver este problema, foi dada a possibilidade de se programar as funções que antes eram imutáveis. Esta solução permitiu que os desenvolvedores 3D (principalmente os programadores de engines 3D) alterassem um conjunto de partes do pipeline 3D. Claro que reprogramar a T&L e o módulo de texturas não é uma tarefa tão fácil, mas os resultados obtidos foram recompensadores.

A reprogramação destas funções introduziu dois novos nomes no mundo 3D: o vertex shader, e o pixel shader. O papel do vertex shader é ser um caminho mais curto para o módulo T&L e o pixel shader para o módulo de texturização. Hoje em dia se fala muito sobre programação de shaders, tornando-se uma verdadeira febre.

Mas nem tudo eram flores. No início, a programação de pixel e vertex shaders era feita no assembler usado pelas GPUs (como a ARB da openGL ) e com o passar do tempo, e evolução, os algoritmos começaram a ficar complexos e de difícil manutenção. Para resolver este problema foi introduzida linhagens de alto nível como a HLSL(High Level Shading Language) para DirectX e GLSL para OpenGL.

Para entender a diferença entre programar no assembler da GPU e em uma linguagem de alto nível, veja o exemplo de um código para normalizar um vetor H.

Assembler:

DP3 result.w, vector, vector;
RSQ result.w, result.w;
MUL result.xyz, result.w, vector;

HLSL ou GLSL:
normalize(result);

Os Drivers

A guerra das empresas de vídeo pela hegemonia do mercado não está limitado ao hardware. O software produzido por estas empresas também ganhou atenção especial dos usuários.

Os drivers são softwares produzidos e distribuídos junto com as placas de vídeo. Eles permitem que aplicações utilizem os recursos destas placas. Apesar de toda placa possuir funcionalidades básicas, e todo sistema operacional conhecer estas funcionalidades, para um maior proveito é necessário drivers específicos.

Apesar dos benefícios de se utilizar os drivers, podemos ficar limitados a necessidade da placa X ou Y que implementa a funcionalidade que desejamos usar. Mas como utilizar as funcionalidades das placas por meio dos drivers?

Nós utilizamos através de dois padrões mundialmente conhecidos e utilizados, o OpenGL e o Direct3D. Atualmente todas as placas de video, e seus drivers, tem suporte à estes dois padrões. Então, quando executamos em nossa aplicação rotinas do OpenGL ou Direct3D estamos apenas passando informações para o driver poder se comunicar com a placa de video.

OpenGL e Direct3D

Uma vez os drivers instalados, o programador de aplicações 3D pode finalmente controlar a GPU e fazer a manipulação dos pixels na tela. A o fazê-lo, nos usamos dois padrões oferecidos que torna a programação a mesma, indiferente de placa: OpenGL e Direct3D.

Estes dois padrões são implementados nos drivers gráficos pelos criadores das placas (nVidia e ATI, por exemplo).

O OpenGL foi a primeira API criada com este propósito, desenvolvida pela Silicon Graphics no inicio dos anos 90: IrisGL. Esta API se tornou popular graças a atitude dos desenvolvedores da SGI que resolveram torná-la um padrão aberto. Usada em diversos sistemas operacionais e tipos de hardware (suportada em ambientes linux, windows, macos e outros).

No final dos anos 90, a Microsoft viu-se obrigada a reagir de forma a atrair o maior número de desenvolvedores de jogos para sua plataforma Windows. O principal problema era que o openGL estava funcional e sendo utilizada, mas o Windows estava longe de suportar programação gráfica operacional, nesta época o openGL era utilizado em maior escala na indústria.

Com o objetivo de inverter esta situação a microsoft desenvolveu o DirectX , um conjunto de APIs que permitiam a manipulação multimídia na sua plataforma. Por este motivo o DirectX está presente apenas em plataformas da microsoft( Windows, XBOX e outras).

Opengl e direct3d estão sendo desenvolvidas e evoluem a cada nova versão. Os 2 padrões propostos praticamente possuem as mesmas funcionalidades par a manipulação das placas 3D e são amplamente aceitos pelas placas gráficas do mercado. Atualmente o openGL está na sua versão 3.0 e o direct3D na versão 10.

Mas não vamos esquecer que os drivers servem apenas para tornar as funcionalidades das placas gráficas acessíveis de forma padronizada. Isto significa que se a placa não tiver estas funções (por exemplo, tolerância a vertex e pixel shader) o driver não poderá fazer nada. Portanto, dependendo da aplicação que você deseje usar a escolha da placa 3D e ter os drivers atualizados pode fazer a diferença.

No próximo post vamos continuar falando das placas de vídeo e suas funcionalidades e componentes. Até a próxima.

A 2ª edição da Game Indie Magazine está disponível. A revista, que possui formato digital, aborda o mundo dos jogos casuais e indies. Leitura recomendada para quem deseja estar informado.

Ainda não joguei, com a promessa de muita emoção em pistas na escala de 1:1 e bons gráficos o jogo Ski Challenge é uma opção grátis de jogo.

O jogo parece ser uma promoção do esporte patrocinado por algum canal de TV(essa é minha teoria).

Se você gosta de jogos de esportes e não tem medo de desafios, pelo menos dentro dos jogos, não perca este.

O jogo pode ser baixado daqui(44.6M o tamanho).

Olá pessoal! Seguindo a dica de um leitor,

Se você é como eu, gosta de bons jogos, sabe que muitos destes não rodam mais nos novos sistemas operacionais, mas nem tudo está perdido. Dentro do universo dos emuladores (os de video-games devem ser os mais famosos) existe um grande número de emuladores de DOS que nos ajudam a executar os games antigos (par quem não é da época, o DOS é um sistema operacional da Microsoft que até o Windows 95 estava presente nas máquinas de muitas pessoas e a plataforma para muitos jogos da época).

Dentro deste grupo de emuladores, o DosBox é um dos mais conhecidos e usados. Na página do projeto, pois ele é um projeto opensource, você pode conferir os jogos suportados e as plataformas onde ele roda (windows, linux, etc).

Agora é só baixar e voltar a jogar os clássicos que inspiram as novas gerações de jogos. Se você não é da época do DOS, mas quer ser um gamedev (seja qual for a área) é uma obrigação jogar os clássicos.

Valeu, até a próxima.

O governo promete incentivos de mas de 1 milhão de reais, sendo divididos em duas categorias de apoio financeiro. O primero, destinado a pessoas físicas, no valor de 70 mil reais e outro para empresas no valor de 160 mil reais.

mais detalhes podem ser encontrados aqui

Pois é, meu computador mais uma vez está pedindo arrego. Não posso mais trabalhar direito num computador que uma semana fica em casa e um mês na assistência. Isso significa que meus trabalhos de gamedev estão pausados até segunda ordem. Enquanto isso eu vou relembrando dos jogos que eu era viciado, na época do meu 486.

Tela de Apresentação do jogo.

Um dos melhores jogos de estratégia que já joguei, Syndicate foi desenvolvido pela Bullfrog em 1993, tendo uma segunda versão chamada Syndicate Wars lançada em 96. O jogo é ambientalizado em um mundo dominado por Corporações, e você faz parte de uma delas. O mundo de Syndicate pode ser visto na imagem abaixo.

Mapa do Mundo

As cores indicam a qual corporação cada território pertence, Seu objetivo é dominar o maior número destes, e para isto você deve cumprir missões específicas por território. Após cumprir com sucesso a missão o território em questão passa a pertencer à sua Corporação.

Tela do Jogo.

As missões são ambientadas dentro de cidades, sendo que o objetivo vai desde assassinar até persuadir. Para cumprir as missões você conta com agentes treinados, mas tome cuidado, bons agentes não se encontram facilmente. Você pode selecionar até quatro agentes por missão, sendo que é sua responsabilidade equipá-los.

Agente

Além dos equipamentos disponíveis é possível destinar recursos para pesquisas, estas pesquisas podem descobrir novas armas e armaduras. Depois de pesquisadas estas armas e armaduras ficam disponíveis para compra, mas tome cuidado ao gastar com armaduras, quando um agente seu morre você perde o investimento e elas custam caro.

Para finalizar, existem rumores sobre uma nova versão de Syndicate, agora é esperar e torcer por uma nova versão deste jogo. Só espero que a essência do jogo continue.

No Windows eu tive que compilar todas as libs que a SGE utilizava (SDL e suas derivadas, libpng, libz e por aí vai), quando consegui compilar tudo eu pensei na dificuldade que iniciantes teriam para compilar todas estas libs, algumas necessitavam instalação de aplicações externas ao visual c++ para poderem compilar.

Tendo um cenário cheio de dependências resolvi abandonar o projeto da SGE utilizando opengl e SDL. A versão windows da SGE será construida com DirectX, com isso a dependência a libs fica restrita, inicialmente, ao directx.

Mas um problema continua, eu sempre trabalhei com openGL e nunca utilizei DirectX, isso significa que os progressos da SGE irão ser mais lentos que imaginei. Um novo desafio está pela frente, agora é só começar a programar.