Allan Yoshio Hasegawa. Framework C++ multiplataforma para desenvolvimento de jogos de alto desempenho em dispositivos móveis

Transcrição

1 Allan Yoshio Hasegawa Framework C++ multiplataforma para desenvolvimento de jogos de alto desempenho em dispositivos móveis Joinville 2012

2 UNIVERSIDADE DO ESTADO DE SANTA CATARINA BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO Allan Yoshio Hasegawa FRAMEWORK C++ MULTIPLATAFORMA PARA DESENVOLVIMENTO DE JOGOS DE ALTO DESEMPENHO EM DISPOSITIVOS MÓVEIS Trabalho de conclusão de curso submetido à Universidade do Estado de Santa Catarina como parte dos requisitos para a obtenção do grau de Bacharel em Ciência da Computação Alexandre Gonçalves Silva Orientador Joinville, Novembro de 2012

3 FRAMEWORK C++ MULTIPLATAFORMA PARA DESENVOLVIMENTO DE JOGOS DE ALTO DESEMPENHO EM DISPOSITIVOS MÓVEIS Allan Yoshio Hasegawa Este Trabalho de Conclusão de Curso foi julgado adequado para a obtenção do título de Bacharel em Ciência da Computação e aprovado em sua forma final pelo Curso de Ciência da Computação Integral do CCT/UDESC. Banca Examinadora Alexandre Gonçalves Silva - Doutor (orientador) Alexandre Gonçalves Silva - Doutor André Tavares da Silva - Doutor Gilmário Barbosa dos Santos - Mestre

4 Resumo Com o atual mercado mundial de smartphones em alta, consumidores estão cada vez mais conectados ao sistema operacional Android, resultando em uma grande demanda de aplicativos para tais dispositivos. Videogames estão entre os aplicativos mais acessados, porém as principais tecnologias para desenvolvimento de jogos para o Android utilizam scripting ou linguagem Java, o que não é ideal para jogos com grande demanda de processamento. Este projeto propõe modelagem, implementação e documentação de um framework open-source multiplataforma em código nativo, em C++, que implemente funcionalidades essenciais para a fundamentação de game engines ou jogos 2D para a plataforma Android. O projeto suporta duas plataformas, Web e Android, por meio de um único sistema de compilação e interfaces genéricas. Para testar a eficiência deste trabalho, uma aplicação que gera modelos dinâmicos 3D foi desenvolvida em duas versões. A primeira usando este framework e em C++, e a segunda usando a biblioteca libgdx com a linguagem Java. Essa aplicação provou que a linguagem C++ consegue um melhor desempenho de processamento do que a Java na plataforma Android. Palavras-chaves: android, PC, videogame, framework, C++

5 Abstract With today s successful smartphones global market, consumers are even more connected to the operation system Android, resulting on a high demand of applications for that platform. Games are the most accessed type of application, however, the main technologies for game development to Android are not suitable for intense processing. This project proposes the design, implementation and documentation of a open-source multi-platform framework in native code, C++, that implements essential functionalities to be used as foundation by Android developers in 2D games and game engines. This project supports two platforms, Android and Web, through a single build system and generic interfaces. To test the efficiency of this work, an application that generates dynamic 3D models was developed in two versions. The first using this framework and C++, and the second using libgdx with the Java language. This application proved that the C++ language achieve better processing performance than Java on the Android platform. Keywords: android, PC, videogame, framework, C++

6 Lista de Figuras 2.1 Principais componentes da plataforma Android Ciclo de vida de uma Android Activity Um exemplo de rendering pipeline usando OpenGL Diagrama do processo de rasterização do OpenGL Exemplo da representação de uma região em Quadtree. a) Região. b) Representação em matriz de binários da região. c) Decomposição da região em blocos. d) Representação em Quadtree Um objeto simples representado com Octree. a) Sequência das células e legenda dos valores da árvore. b) Representação do objeto em forma de árvore Modelo 2D, em forma de elipse, que será aproximado usando o princípio básico do algoritmo Marching Cubes Modelo 2D, em forma de elipse, que será aproximado usando o princípio básico do algoritmo Marching Cubes. a) Pontos que pertencem ao objeto em amarelo. c) Vértices que aproximam a fronteira em vermelho Modelo 2D, em forma de elipse, aproximado usando o princípio básico do algoritmo Marching Cubes Os 15 templates únicos do algoritmo Marching Cubes Android View sendo usada no videogame Logo Quiz, de J-ROEN Hierarquia de classes para acesso de uma câmera através de uma interface genérica Requisitos do projeto Furai para o ambiente de desenvolvimento Requisitos de funcionalidades do projeto Furai Organização do projeto Furai

7 4.4 [CD01] Diagrama da Arquitetura do Projeto Furai [CD02] Diagrama do pacote core do Projeto Furai [CD03] Diagrama do pacote storage do Projeto Furai [CD04] Diagrama do pacote io do Projeto Furai [CD05] Diagrama do pacote graphic do Projeto Furai [CD05a] Diagrama do pacote g2d do Projeto Furai [SD01] Diagrama de Sequência da inicialização do framework [SD02] Diagrama de Sequência de um projeto mínimo implementado pelo ponto de vista do usuário Chamadas OpenGL, usando Pepper API, na thread secundária Estrutura hierárquica dos diretórios Sequência de diretórios que o sistema de compilação percorre Exemplo de uma redução de memória ao usar Adaptive Octree. Legenda: V = Vazio, P = Parcial e C = Cheio. a) Estado da árvore inicial. b) Estado da árvore após inserção de um voxel na última célula do segundo nível da árvore Operação realizada para criação do modelo 3D usado na aplicação de testes Modelo 3D gerado pela aplicação de testes para uma Octree de tamanho Tempo total da aplicação libgdx dividido pelo tempo total obtido com Furai para a plataforma Android

8 Lista de Abreviaturas SDK JNI API JVM 2D 3D GPU JIT UI PC IDE RTTI DOM MC Software Development Kit Java Native Interface Application Programming Interface Java Virtual Machine Duas dimensões Três dimensões Graphics Processing Unit Just-in-Time User Interface Personal Computer Integrated Development Environment Run-time type information Document Object Model Marching Cubes

9 Lista de Tabelas 2.1 Relação de API Level com versões da plataforma Android a partir da Comparação entre as ferramentas para desenvolvimento de videogames para a Android Comparação entre as ferramentas para desenvolvimento de videogames para a Android Resultados dos testes realizados comparando libgdx e Furai na plataforma Android para diferentes resoluções da Octree. Os resultados que não apresentam tempo de processamento indicam que a aplicação falhou execução por falta de memória Resultados dos testes realizados com o framework Furai na plataforma NaCl. 77

10 Sumário Lista de Figuras 3 Lista de Abreviaturas 5 Lista de Tabelas 6 1 Introdução Motivação Problema Objetivos Estrutura deste documento Referencial Teórico Game Engine A Plataforma Android e sua Arquitetura Arquitetura Android Android Activity DalvikVM Android SDK Android NDK OpenGL e OpenGL ES OpenGL OpenGL ES Native Client Java JNI

11 2.6 Árvore 8-ária Hierárquica Octree Marching Cubes Estado da Arte Comparação de Desempenho entre Java e C na Plataforma Android Aplicação Java portada parcialmente para C Ferramentas para Desenvolvimento de Videogames para Android Android SDK Android NDK Game Engines com Suporte a Plataforma Android Tabelas Comparativas Sistema de compilação para aplicações C/C++ multiplataforma O Projeto Requisitos O Ambiente de Desenvolvimento A Arquitetura Core System Storage System Input/Output System Graphic System Diagramas de Sequência Desenvolvimento Diferenças entre Android e NaCl Ciclo de Vida da Aplicação EGL e Pepper API Pepper API fora da thread principal

12 5.1.4 Sistema de Log Sistema de Compilação Multiplataforma Aplicação Usada nos Testes Criação do Modelo 3D em Octree Implementação do Algoritmo Marching Cubes Criação da Malha Poligonal Testes e Resultados 74 7 Considerações Finais 78 Referências 80

13 10 1 Introdução Este trabalho estuda e implementa uma solução de alto desempenho para desenvolvimento de videogames 1 2D otimizados para a plataforma Android. O código fonte open-source do projeto está disponível de forma online no endereço Motivação Os smartphones são produtos eletrônicos de consumo que estão em alta no mercado mundial atual. Com taxas de vendas crescentes, estão a cada ano mais presentes na vida das pessoas (GARTNER, 2012). Um dos principais sistemas operacionais para esses dispositivos é o Android da Google (NPD, 2012). O crescimento nas vendas e a boa aceitação dessa tecnologia pelos consumidores refletem em maior uso de aplicativos desenvolvidos para essa plataforma, fazendo com que o número total de downloads cresça de forma acelerada, chegando a mais de 10 bilhões de instalações por meio do Google Play 2. Dentre esses 10 bilhões, a categoria que mais obteve acessos foi a de videogames, contribuindo com um total de 25,6% de downloads 3. Porém, ao produzir aplicações para a plataforma Android, desenvolvedores enfrentam dois desafios técnicos, o primeiro sendo a heterogeneidade entre os diversos hardwares suportados pelo Android, e o segundo sendo a limitação de recursos e processamento presentes nesses dispositivos (RATABOUIL, 2011). Android suporta um número de dispositivos cada vez maior 4, com diferenças de hardware significativas, deixando inviável o desenvolvimento de aplicações específicas para cada um. Para facilitar a portabilidade, engenheiros da Google montaram uma máquina virtual, acoplada a um framework completo, para executar programas em uma das linguagens de programação de maior crescimento atualmente, a Java (RATABOUIL, 1 Videogame é um software interativo com fim recreativo, acoplado a um dispositivo para exibição visual de dados e a um outro dispositivo de entrada de dados, o que permite ao usuário interagir com o mesmo (MICHAELIS, 2012). 2 Google Play: 3 CHU, E.; A Closer Look at 10 Billion Downloads < (Acesso 07/11/2012). 4 Atualmente a Google reconhece oficialmente 2152 dispositivos diferentes para um aplicativo requisitando touchscreen e tela horizontal, além de API Level 4+.

14 1.2 Problema ). A combinação da linguagem Java, com a DalvikVM 5 e o framework completo, ou seja, Android SDK, provém uma ferramenta poderosa para construção de aplicações para os diversos dispositivos Android, assim amenizando a dificuldade do primeiro desafio técnico. Uma desvantagem de programar aplicações Android puramente em Java é a falta de meios para utilizar todo o poder computacional do dispositivo de forma eficiente, assim dificultando ainda mais o segundo desafio técnico. Entretanto, a plataforma Android permite que aplicações Java invoquem métodos nativos por meio da Android NDK, e com isso, porções de códigos complexos podem obter maior desempenho usando C (LEE; JEON, 2010). 1.2 Problema O problema é a falta de bibliotecas open-source e de alto desempenho especializadas em videogames para a plataforma Android. Atualmente as bibliotecas apresentam uma das seguintes características: implementada em Java, comercial, para uso geral (não projetada para videogames) ou portada direto da versão para PC sem otimizações para sistemas embarcados. Enquanto a adoção da linguagem Java pela plataforma Android traz benefícios para aplicações de uso geral, a indústria de videogames pode se beneficiar usando código nativo com C ou C++. Além do ganho em desempenho, técnicas já maduras para solucionar a heterogeneidade dos dispositivos podem ser portadas para a plataforma Android. 1.3 Objetivos O principal objetivo deste trabalho é desenvolver um framework open-source em C++ para a produção de videogames 2D para a plataforma Android. Para acelerar o ciclo de desenvolvimento da aplicação, essa solução suporta multiplataformas, Windows PC e Android. Um sistema único de compilação foi desenvolvido para facilitar a construção dos executáveis de cada plataforma. O framework oferece comandos em alto nível para: Controle e gerência de diretórios e arquivos; 5 Máquina virtual Java presente no Android

15 1.4 Estrutura deste documento 12 Gerenciar recursos do videogame, como texturas e textos, de forma síncrona; Auxiliar na restauração do estado anterior da aplicação caso ela seja terminada pelo sistema operacional; Tratamento de interação com o usuário (mouse, tela sensível ao toque e acelerômetro); Controle de câmera ortogonal e especificação da área visível ao usuário; Transformações espaciais de objetos; Projeção de texturas. Além de oferecer comandos de alto nível, o framework também disponibiliza acesso a instruções de baixo nível para o contexto OpenGL ES, permitindo que usuários avançados ou game engines possam fazer uso deste framework como fundamentação de seus softwares. O código fonte do framework está disponível de forma online no endereço Estrutura deste documento O Capítulo 2 apresenta informações essenciais para compreensão do problema e da solução descrita neste trabalho. Primeiramente é colocada a definição e arquitetura de uma game engine. Depois a plataforma Android é estudada e seus principais componentes, detalhados. Uma introdução a OpenGL é feita em seguida, descrevendo uma rendering pipeline típica e depois apresentado a OpenGL para sistemas embarcados (OpenGL ES). Em seguida é estudado o projeto Native Client, que é usado para execução de código nativo em aplicações web. A tecnologia Java JNI, que é um método para aplicações Java executar códigos nativos, é explicada. As duas últimas seções descrevem dois algoritmos usados na aplicação implementada para testar a eficiência deste trabalho, esses são Octree e Marching Cubes. O Capítulo 3 mostra trabalhos relacionados ao tema de desenvolvimento de videogames para a plataforma Android e desempenho em aplicações nativas. O Capítulo 4 detalha os requisitos da solução deste trabalho, o ambiente de desenvolvimento e finalmente a arquitetura do projeto.

16 1.4 Estrutura deste documento 13 O Capítulo 5 apresenta as dificuldades e soluções adotadas para a implementação deste projeto. O Capítulo 6 mostra os resultados obtidos quando este trabalho é comparado com outra tecnologia usando Java. Uma discussão sobre os resultados é feita. O Capítulo 7 apresenta as considerações finais sobre o projeto.

17 14 2 Referencial Teórico Este capítulo aborda conceitos teóricos necessários para a compreensão deste trabalho. A Seção 2.1 descreve o que é uma game engine e apresenta uma arquitetura típica. A Seção 2.2 analisa a plataforma Android, estudando seus principais componentes. As APIs OpenGL e OpenGL para sistemas embarcados (OpenGL ES) são apresentadas na Seção 2.3. O projeto Native Client é introduzido na Seção 2.4. A tecnologia Java JNI, que é um método para aplicações Java se comunicarem de forma eficiente com códigos nativos, é introduzida na Seção 2.5. As Seção 2.6 e 2.7 apresentam dois algoritmos usados na aplicação desenvolvida para realizar os testes, esses sendo Octree e Marching Cubes. 2.1 Game Engine Um videogame é um software complexo, composto por diversos sistemas trabalhando de forma unificada, como som, sensores, animação, física, inteligencia artificial, sistema de entrada, entre outros. Até meados dos anos 90 era comum a reimplementação desses diversos componentes, porém uma nova abordagem começou a ficar popular com o lançamento e sucesso de Doom 1, um videogame produzido pela id Software. A arquitetura de Doom inseriu uma nova ideia para design de jogos, onde o núcleo do software, como sistema gráfico e de input por exemplo, fica separado da arte, da descrição dos mundos e das regras. Essa separação foi importante por que desenvolvedores puderam lançar novos videogames mudando apenas essa camada de arte e regras, fazendo apenas pequenas alterações no núcleo do sistema, assim agilizando a produção de jogos. O núcleo desse sistema pode ser definido como game engine (GREGORY, 2009). De forma simples, uma game engine é um conjunto de componentes de software usados por diversos videogames, necessitando nenhuma ou poucas modificações. Game engines são modeladas em camadas e fazem uso de software de diversas áreas, como projeção gráfica, simulação física e inteligencia artificial por exemplo, e são portanto consideradas softwares grandes. Game engines multiplataformas possuem camadas que são dependentes das plataformas, e outras que não são. As camadas mais 1 Doom é um videogame de tiro em primeira pessoa lançado em 1993 pela id Software.

18 2.2 A Plataforma Android e sua Arquitetura 15 abaixo são consideradas dependentes de plataformas, pois elas conhecem o hardware e/ou o sistema operacional, e implementam códigos específicos para eles, além de abstrair as diversas implementações para cada plataforma das camadas superiores. É comum encontrar uma camada no centro da game engine, e independente de plataforma, onde ficam bibliotecas úteis para as camadas superiores. Essa camada geralmente é chamada de core, ou núcleo, e contém classes para realizar funções matemáticas, testes, profiling, gerência de arquivos, entre outras funcionalidades. Acima da camada núcleo ficam sistemas de áudio, efeitos visuais, física, animação, entre outras, e quanto mais acima for a camada, mais específica para um videogame ela será. 2.2 A Plataforma Android e sua Arquitetura Android é um sistema operacional para dispositivos móveis criado pela Android Inc. e adquirido pela Google em Em 2007, um grupo chamado Open Handset Alliance 2, liderado pela Google, foi formado para desenvolver uma plataforma transparente para dispositivos móveis. Esse grupo então continuou o desenvolvimento da plataforma Android (KOMATINENI; MACLEAN; HASHIMI, 2011), e lançou ela com a licença de código aberto Apache 2.0. A plataforma Android é um conjunto de softwares unificados, incluindo sistema operacional, um middleware e aplicações essenciais. Esse conjunto de softwares é melhor descrito na Seção 2.2.1, onde a arquitetura desta plataforma é analisada. A Seção descreve a Android Activity, e como é o ciclo de vida de uma aplicação nesse sistema operacional. Oficialmente a Google suporta duas ferramentas para desenvolvimento de aplicações Android. Para a linguagem Java é usada a Android SDK, que será abordada na Seção Já para a linguagem C++ a Google oferece a Android NDK, a qual será apresentada na Seção Arquitetura Android A Figura 2.1 apresenta o diagrama com os principais componentes do sistema operacional Android, analisando de baixo para cima, esses são: 2 Open Handset Alliance. < (Acesso 07/11/2012).

19 2.2 A Plataforma Android e sua Arquitetura 16 Linux: Android é construído em cima do kernel do Linux, o qual tem como função abstrair e dar suporte aos diversos hardwares usados pela plataforma Android; Bibliotecas em C: Em cima do kernel fica um conjunto de bibliotecas C/C++ (KO- MATINENI; MACLEAN; HASHIMI, 2011), como OpenGL ES, libc, SQLite e outras; DalvikVM: Android oferece um conjunto de bibliotecas que apresentam a maioria das funcionalidades das bibliotecas essenciais da linguagem Java. Aplicações Android são executadas em seus próprios processos e em cima da máquina virtual Dalvik, como descrito na Seção 2.2.3; Bibliotecas em Java: As aplicações para Android podem fazer uso de diversos serviços e sistemas. Como Android oferece uma arquitetura aberta e livre, desenvolvedores têm a habilidade de construir aplicações ricas e inovadoras. Desenvolvedores estão livres para usar todo potencial de hardware do dispositivo, acessar informações de localização, rodar serviços em segundo plano, configurar alarmes, entre outras. Essas funcionalidades estão disponíveis por meio da Android SDK e pela linguagem Java. Mais detalhes sobre a essa camada pode ser visto na Seção 2.2.4; Aplicações: Android é acompanhado de aplicações essenciais, como , calendário, navegador de internet, lista de contatos, e outras. A instalação de novas aplicações Android, inclusive as da camada da Android SDK, é feita por meio de arquivos de extensão.apk. APK, ou Android application package file, agrupa diversos arquivos, incluindo arquivos executáveis da DalvikVM (.dex), arte, som, especificações, textos, certificados, manifest, e outros. Um arquivo essencial em um.apk é o Android Manifest File. Este arquivo apresenta diversas funcionalidades, incluindo a listagem de permissões da aplicação, qual API Level mínimo necessário, quais recursos de software/hardware necessários, bibliotecas necessárias, e outras. Esse arquivo precisa estar na parta raiz do.apk, e nomeado como AndroidManifest.xml. Aplicações externas, como a Google Play, podem usar tal arquivo para filtrar aplicações disponíveis para um determinado dispositivo, assim impedindo que aplicativos que necessitam de multi-touch sejam instalados em aparelhos sem essa funcionalidade por exemplo.

20 2.2 A Plataforma Android e sua Arquitetura 17 Figura 2.1: Principais componentes da plataforma Android. Fonte: Adaptada de (KOMATINENI; MACLEAN; HASHIMI, 2011) Android Activity Para que uma aplicação Android apresente algo em uma tela, e com ela fazer a interação com o usuário, a plataforma Android oferece a Activity. Com ela é possível iniciar uma janela para desenhar a interface do usuário. Geralmente uma aplicação é composta por diversas atividades, sendo uma delas a atividade main, a qual é apresentada ao usuário ao iniciar a aplicação. Essa Activity pode iniciar outra Activity. Cada vez que uma Activity é iniciada, a anterior é parada, mas o sistema mantém ela em uma pilha, assim, quando a atual Activity for terminada, a anterior será retirada da pilha e ganhará foco. Como a plataforma Android é desenvolvida para dispositivos com recursos computacionais limitados, ela apresenta maior controle sobre suas aplicações do que sistemas operacionais para PC. Por exemplo, se o usuário abrir uma aplicação, e logo em seguida abrir outra paralelamente, essa última aplicação, que mantém o foco, pode requisitar mais memória, e caso o sistema operacional não consiga achar essa quantidade livre, ele pode terminar a aplicação anterior, sem avisar o usuário, para entregar essa memória para a aplicação que mantém o foco. Uma aplicação também pode perder o foco e ir para segundo plano ao receber chamadas telefônicas por exemplo, assim deixando que o sistema operacional decida se a aplicação será parada ou não. Para que a aplicação tenha

21 2.2 A Plataforma Android e sua Arquitetura 18 um comportamento aceitável nessas situações, ela precisa implementar o ciclo de vida da Activity. Uma Activity pode existir em três estados, esses são: Resumed ou Running: Activity em primeiro plano; Paused: Outra Activity está em primeiro plano, porém essa ainda está visível. Essa Activity ainda permanece na memória, mas poderá ser terminada pelo sistema em casos críticos de falta de memória; Stopped: Essa Activity não é vista pelo usuário, e agora está em segundo plano. Ela ainda continua na memória, mas poderá ser terminada pelo sistema quando memória é requisitada em outro lugar. A Figura 2.2 apresenta os caminhos que uma Activity pode percorrer entre suas mudanças de estados. Os retângulos apresentam métodos que desenvolvedores podem implementar para que a aplicação se comporte de uma maneira esperada. O sistema operacional Android pode apenas terminar aplicações após elas terem executado ao menos um desses métodos: onpause(), onstop() ou ondestroy(). Tal comportamento é importante pois permite que o desenvolvedor trate a mudança de estado da aplicação de forma desejável, como salvando em memória secundária atributos chaves por exemplo, assim, ao reabrir a aplicação, o algoritmo pode realocar esses atributos e permitir que a aplicação continue sua execução do estado onde tinha parado DalvikVM DalvikVM, ou máquina virtual Dalvik, é a máquina virtual da plataforma Android. A Dalvik é otimizada para sistemas embarcados, e consegue reutilizar fragmentos duplicados de diversos arquivos executáveis, assim reduzindo o espaço necessário pela metade quando comparado a um arquivo.jar tradicional. Porém, essa máquina virtual não executa arquivos no formato Java byte code, mas sim arquivos executáveis do formato Dalvik Executable (.dex) (KOMATINENI; MACLEAN; HASHIMI, 2011). A compilação just-in-time, ou JIT, é suportada pela plataforma Android a partir da versão 2.2. Com o uso de JIT, aplicações conseguem um ganho de até cinco vezes a mais de desempenho quando comparada a aplicações sem JIT. A Dalvik também

22 2.2 A Plataforma Android e sua Arquitetura 19 Figura 2.2: Ciclo de vida de uma Android Activity. Fonte: Traduzida de (GOOGLE, 2012). apresenta otimizações em seu coletor de lixo e um gerador de código Assembly diferente, capaz de gerar menos instruções (KOMATINENI; MACLEAN; HASHIMI, 2011). Todas as aplicações na plataforma Android são executadas em seus próprios processos, e cada uma inicia uma nova instância da máquina virtual Dalvik, incluindo aplicações nativas.

23 2.2 A Plataforma Android e sua Arquitetura Android SDK A Android SDK 3 é um conjunto de ferramentas e APIs para o desenvolvimento de aplicações, usando a linguagem Java, para a plataforma Android. A lista de ferramentas inclui: Android Virtual Device (AVD): Ferramenta para configurar parâmetros do emulador do Android, assim especificando características de hardware/software que serão emuladas, como por exemplo a versão da plataforma Android que será usada e quanto de memória o dispositivo terá. Múltiplas AVD podem ser criadas, e a gerência delas pode ser feita de maneira gráfica usando a AVD Manager; Android Developer Tools (ADT): ADT é um plugin para a IDE Eclipse. Ela oferece interface gráfica para execução de diversas ferramentas da Android SDK que são disponíveis apenas por linha de comando. ADT também oferece ferramentas para design de UI para prototipagem rápida e construção da interface com o usuário. Além das vantagens de usar uma IDE já bem estabelecida como a Eclipse, com a presença de editores de XML e Java, o ADT oferece automação de diversos fluxos de trabalhos, incluindo o empacotamento de arquivos.apk e instalação em dispositivos para testes; Android Debug Bridge (adb): adb é uma ferramenta, em linha de comando, que permite a comunicação com o emulador ou algum dispositivo rodando a plataforma Android. Entre suas funcionalidades, a adb consegue requisitar quais dispositivos Android estão conectados, instalar aplicações, transferir arquivos, executar comandos shell, controle de banco de dados e coletar/visualizar logs usando logcat. ADT suporta a adb; Dalvik Debug Monitor Server (DDMS): DDMS é uma ferramenta de depuração, a qual oferece funcionalidades de captura de tela, informações sobre threads e heap, profiling de métodos, logcat, processos, emulação de SMS e serviços de localização e outros. DDMS faz uso do adb para se comunicar com dispositivos Android e é compatível com a ADT. 3 Android SDK Android Developers. < (Acesso 07/11/2012).

24 2.2 A Plataforma Android e sua Arquitetura 21 Tabela 2.1: Relação de API Level com versões da plataforma Android a partir da 2.3 Versão da Plataforma Android API Level Android Android Android 4.0, 4.0.1, Android Android 3.1.x 12 Android 3.0.x 11 Android 2.3.4, Android 2.3.2, 2.3.1, Fonte: < (Acesso 07/11/2012) Além das ferramentas, a Android SDK oferece diversas APIs para desenvolvimento de aplicações Java. Essas API fazem parte da camada Bibliotecas em Java da arquitetura Android, como visto na Figura 2.1, e elas têm como função abstrair as camadas inferiores das aplicações. Atualizações na SDK acontecem, e são projetadas para serem compatíveis com versões anteriores. São poucos os casos onde não há compatibilidade entre as atualizações, mas esses existem para garantir a segurança do sistema. Cada versão da plataforma Android lança uma nova versão da SDK, a qual recebe um número inteiro para identificação, esse chamado de API Level, como mostrado na Tabela 2.1. Aplicações Android podem especificar quais versões da plataforma Android elas suportam usando esta numeração Android NDK Android NDK 4 é um conjunto de ferramentas para adicionar pedaços de código nativo em aplicações Android. Todas as aplicações Android executam sobre a máquina virtual Dalvik, como visto na Seção 2.2.3, entretanto, com a Android NDK é possível fazer com que essa aplicação Java, sendo executava na Dalvik, chame porções de códigos nativos escritos em C ou C++. Essa característica permite que aplicações Android possam reusar códigos legados já existentes e em alguns casos aumentar seu desempenho. 4 What is the NDK? Android Developers. < (Acesso 07/11/2012).

25 2.3 OpenGL e OpenGL ES 22 A NDK inclui: Conjunto de ferramentas e arquivos de construção usados para gerar bibliotecas nativas a partir de códigos fontes escritos em C/C++; Meios para inserir essas bibliotecas nativas em arquivos.apk; Conjunto de cabeçalhos e bibliotecas nativas do sistema, como versões estáveis da libc, libm, OpenGL ES, interface JNI e outras; Documentação, exemplos e tutoriais. Diferentemente da Android SDK, que faz uso de Java, e gera aplicações para todos dispositivos Android, a Android NDK compila para um conjunto de instruções de máquina específico. Atualmente a NDK suporta compilação dos seguintes conjuntos de instruções: ARMv5TE, ARMv7-A e MIPS. Cada compilação precisa ser feita independentemente, porém uma aplicação Android pode incluir bibliotecas compiladas para diversos alvos. 2.3 OpenGL e OpenGL ES OpenGL OpenGL 5, ou Open Graphics Library, é uma API gráfica multiplataforma que define uma interface de software padronizada para processamento gráfico 3D em hardware. A OpenGL foi projetada para definir apenas comandos essenciais para a especificação de objetos, e operações, necessárias para produzir aplicações 3D (SHREINER, 2010), resultando assim em uma API que apresenta apenas saída de processamento de forma gráfica. Outra característica da OpenGL é sua presença em diversas linguagens de programação, como por exemplo o projeto Java OpenGL 6, ou JOGL, o qual oferece OpenGL para aplicações Java, e o projeto PyOpenGL 7, o qual possibilita o uso da OpenGL na linguagem de programação Python. 5 OpenGL - The Industry s Foundation for High Performance Graphics. < (Acesso 07/11/2012). 6 JOGL - Java binding for the OpenGL API. < (Acesso 07/11/2012). 7 PyOpenGL The Python OpenGL Binding.. < (Acesso 07/11/2012).

26 2.3 OpenGL e OpenGL ES 23 Para que a OpenGL converta um modelo em uma imagem gráfica, ela precisa executar uma sequência de operações. Essa sequência é conhecida como rendering pipeline. Os comandos da OpenGL são usados para inserir dados no sistema, ou para modificar o comportamento de cada operação da rendering pipeline. Como a OpenGL é uma API de baixo nível, e procedural, o programador precisa descrever todos os passos necessários à projeção da cena, assim aumentando a complexidade da aplicação, mas ao mesmo tempo oferecendo liberdade para implementação de diferentes técnicas. Por causa disso, cada aplicação pode apresentar diferentes implementações dessa pipeline, por isso, o modelo estudado neste trabalho usa a abordagem de Shreiner (SHREINER, 2010), como visto na Figura 2.3, pois essa sequência apresenta uma demonstração confiável das capacidades da OpenGL. Os itens a seguir descrevem a funcionalidade de cada operação presente na Figura 2.3: Display lists: Armazenamento temporário de dados, esses podem ser usados imediatamente, ou armazenados para uso posterior; Evaluators: Transforma funções polinomiais para produzir vértices, normais, coordenadas de texturas e cores (SEGAL; AKELEY, 2011); Per-vertex operations: Converte vértices nos tipos primitivos da OpenGL, como pontos, segmentos de linhas e polígonos. Por exemplo, coordenadas espaciais presentes no mundo 3D são projetadas para uma tela 2D. Essa etapa pode também fazer mapeamento de textura e realizar cálculos de iluminação no vértice; Primitive Assembly: Elimina porções geométricas que estão fora de uma região especificada. Esta etapa também pode aplicar perspectiva, controle do viewport e operações no eixo z; Pixel operations: Transferir pixels para a memória de texturas, geralmente presente em hardwares específicos, como GPU. Outras operações dessa etapa pode incluir a decodificação do formato original do pixel e manipulações como escala; Texture assembly: Mapeia imagens em objetos geométricos; Rasterization: Converte primitivas em uma imagem 2D. Essa etapa pode ser dividida em duas partes, a primeira mapeia a primitiva em uma janela contendo um conjunto de quadrados, e a segunda parte define as cores e profundidade desses quadrados (SEGAL; AKELEY, 2011). A Figura 2.4 apresenta o diagrama desta etapa;

27 2.3 OpenGL e OpenGL ES 24 Fragment operations: Cada quadrado gerado pelo processo de rasterização pode ser chamado de fragmento, e cada fragmento corresponde a um pixel no framebuffer. Porém, antes do fragmento chegar ao framebuffer, ele pode sofrer algumas operações. Alguns exemplos de operações são: texturização, cores, névoa, transparência e blending. Após aplicar todas as operações dessa etapa, o fragmento não será mais modificado, e definirá um pedaço do resultado final. Figura 2.3: Um exemplo de rendering pipeline usando OpenGL. Fonte: (SHREINER, 2010). Figura 2.4: Diagrama do processo de rasterização do OpenGL. Fonte: (SEGAL; AKELEY, 2011). Para maior controle da rendering pipeline, a OpenGL ARB 8 criou a GLSL, ou OpenGL Shading Language, assim permitindo que desenvolvedores obtenham controle direto da rendering pipeline. GLSL é uma linguagem de shading de alto nível, disponível 8 OpenGL ARB, ou Architecture Review Board, propõe e aprova mudanças em especificações, novos releases e testes de conformidade.

28 2.3 OpenGL e OpenGL ES 25 na OpenGL a partir da versão 2.0. A sintaxe adotada pela GLSL é baseada na linguagem de programação C. Essa técnica de alterar a rendering pipeline programando é também conhecida como shading, e o programa gerado por ela pode ser chamado de shader. Como a OpenGL é independente de plataforma, ela não suporta a manipulação de janelas, por isso ela precisa sempre estar acompanhada de outras API para criar e gerenciar seu contexto gráfico. Para o sistema operacional Windows, a API WGL 9 existe para resolver este problema. A WGL está documentada e armazenada no OpenGL Extension Registry (KHRONOS, 2012c), documento onde as especificações de diversas extensões para OpenGL são distribuídas de forma online (SEGAL; AKELEY, 2011). As especificações presentes neste documento são definidas por fornecedores, grupo de fornecedores ou pela OpenGL ARB. Outra API, que também faz parte da padronização da OpenGL, é a GLU, ou OpenGL Utility Library. A GLU é construída em cima da OpenGL, e oferece um conjunto de funções de alto nível (SHREINER, 2010), como: mipmaps, controle de matrizes de projeções, NURBS, primitivas geométricas, transformação das coordenadas do sistema para coordenadas do dispositivo, entre outras OpenGL ES OpenGL ES, ou OpenGL Embedded System, é uma versão reduzida da OpenGL. Esse subconjunto da OpenGL foi desenvolvido para sistemas embarcados, baixando o número de chamadas redundantes da API e com foco no baixo consumo de poder computacional (SMITHWICK, 2011) e de armazenamento. OpenGL ES é atualmente gerenciada pelo consórcio Khronos Group e já está presente em diversas plataformas, como Android, ios, Nintendo 3DS, Playstation 3 e WebGL. Como na versão tradicional da OpenGL, a OpenGL ES não suporta controle da janela da aplicação. Uma forma padronizada de resolver este problema é implementando a EGL, uma interface que atua entre as API do Khronos Group, como a OpenGL ES, e o sistema de janelas da plataforma. A EGL API está disponível no Khronos Registry (KHRONOS, 2012a), documento que funciona de forma similar ao OpenGL Registry. A API OpenGL ES suporta texturas compactadas, assim exigindo menos 9 WGL and Windows Reference. < (Acesso 07/11/2012).

29 2.3 OpenGL e OpenGL ES 26 memória nos dispositivos, e melhor aproveitamento da largura de banda da memória. Porém, a OpenGL ES não define formatos de compressão de texturas, apenas mecanismos para carregá-las em memória. Geralmente são os fabricantes que desenvolvem formatos de compressão otimizados para seus dispositivos(munshi; GINSBURG; SHREINER, 2008). Atualmente as versões mais comuns da OpenGL ES são a OpenGL ES 1.X e OpenGL ES 2.0. Mais detalhes sobre cada uma nas próximas subseções. No dia 6 de agosto de 2012 o grupo Khronos publicou a especificação da OpenGL ES 3.0 (KHRONOS, 2012b), porém, nenhum dispositivo no mercado suporta essa nova API 10. OpenGL ES 1.X Duas especificações estão publicadas na OpenGL ES Registry para a OpenGL ES 1.X. A primeira é a versão OpenGL ES 1.0, a qual foi definida usando a OpenGL 1.3 como referência, e teve como enfase apenas projeção da cena via software e uma aceleração gráfica via hardware básica. Como a OpenGL ES 1.0 contém um subconjunto de comandos e operações da OpenGL 1.3, aplicativos desenvolvidos com a OpenGL ES 1.0 são facilmente portados para OpenGL 1.3, porém o inverso pode não ser verdade. Já a versão OpenGL ES 1.1 é baseada na OpenGL 1.5, e seu foco é na aceleração gráfica via hardware. A versão 1.1 é totalmente compatível com a versão 1.0, e apresenta todas as funcionalidades da versão anterior além de novas. A combinação das versões 1.0 e 1.1 é normalmente chamada de OpenGL ES 1.X. A principal característica da versão OpenGL ES 1.X é seu suporte a hardware com o rendering pipeline fixo. Isso faz com que essa API seja mais fácil de se usar quando comparada com a OpenGL ES 2.0, pois ela acompanha bibliotecas auxiliares que fazem boa parte da computação de luzes, cores e shading (SMITHWICK, 2011). Porém, essa facilidade pode custar a flexibilidade na hora de se trabalhar com ela, pois aplicações com demanda de funções gráficas avançadas, como em videogames, pode sofrer limitações. 10 Khronos Conformant Products. < 07/11/2012). (Acesso

30 2.4 Native Client 27 OpenGL ES 2.0 A OpenGL ES 2.0 foi definida baseada na OpenGL 2.0. Essa versão suporta o rendering pipeline programável, porém todas as operações envolvendo o rendering pipeline fixo foram removidas, assim resultando em uma API que não é totalmente compatível com versões anteriores. A OpenGL ES 2.0 está disponível para a plataforma Android a partir da versão 2.2 (Froyo), entretanto, apenas para dispositivos reais. O emulador Android começou a suportar a OpenGL ES 2.0 só após a versão (Ice Cream Sandwich). Para a plataforma Windows, apenas a AMD confirmou oficialmente drivers para a OpenGL ES 11, porém o projeto Angle traduz a GLSL, e as funções da OpenGL ES em instruções da DirectX. O suporte a OpenGL ES na plataforma Linux é feito por meio do Mesa Driver 12. Wrappers 13 ligando a OpenGL ES 2.0 a OpenGL 2.0 não são triviais, pois há diferenças de implementações entre as duas API, principalmente na linguagem de shading. De acordo com dados estatísticos coletados pela Google, 90,8% dos dispositivos Android suportam a OpenGL ES 2.0 e 1.X, contra 9,2% de dispositivos suportando apenas a OpenGL ES 1.X Native Client Native Client, ou NaCl 15, é um sistema para incorporar código nativo x86 em aplicações web. Ao usar código nativo em vez de uma linguagem interpretada, a NaCl se torna útil em extensões computacionalmente intensas, especialmente em domínios de simulações físicas, processamento de linguagens e aplicações gráficas de alto desempenho (YEE et al., 2009), como videogames. Essa tecnologia funciona criando um ambiente de execução isolado para o código nativo, de forma que ele não fique ligado diretamente ao sistema operacional. Isso 11 OpenGL ES 2.0 Coming to a Desktop Near You. < (Acesso 07/11/2012). 12 The Mesa 3D Graphics Library. < (Acesso 06/11/12). 13 Wrappers consistem em uma camada fina de código que traduz a interface de uma biblioteca em outra compatível. 14 OpenGL ES Versions Android Developers. < (Acesso 07/11/2012). 15 Native Client - Google Developers. < (Acesso 07/11/2012).

31 2.4 Native Client 28 significa que a NaCl não permite que a aplicação web em código nativo invoque funções do sistema de forma direta, assim impedindo-a de acessar espaços de memória proibidos e arquivos ou dispositivos do sistema sem autorização. Caso a aplicação tente executar uma instrução não permitida, ela é automaticamente destruída. A compilação de uma aplicação usando NaCl usa um conjunto de ferramentas especiais, em que apenas uma variação do compilador GCC é suportado (YEE et al., 2009). Ao usar NaCl, a aplicação web consegue desempenho próximo a aplicações nativas em Linux, com uma perda de desempenho média de 5% (YEE et al., 2009). Testes simulando ambientes físicos usando a biblioteca Bullet 16 se mostraram apenas 2% mais lentos usando NaCl quando comparada a uma aplicação Linux. Já ao testar com o Quake, que é um videogame com gráficos, som, input, física, inteligência artificial e outros, a NaCl obteve uma diferença de menos de um quadro por segundo de processamento (YEE et al., 2009). Uma aplicação web usando Native Client geralmente é composta de JavaScript, HTML, CSS e um módulo NaCl escrito em alguma linguagem suportada pela NaCl. Atualmente a NaCl SDK suporta apenas C e C++ oficialmente, porém essa tecnologia já foi portada para ser usada com Lua e awk (YEE et al., 2009). A parte em JavaScript/CS- S/HTML da aplicação é responsável pela interação com o usuário e tratamento de eventos, além de declarar o documento HTML e se necessário uma parte da computação. O módulo NaCl geralmente é usado para tarefas com processamento intenso, manipulação de grandes quantidades de dados e também pode tratar eventos usando APIs. A comunicação entre o navegador e o módulo NaCl é feita por meio da Pepper Plug-in API, ou simplesmente Pappi. Essa API oferece funções para acesso e download de arquivos, gerência da janela da aplicação, comunicação com o código Javascript e gerência do contexto OpenGL. Chamadas a funções da Pappi devem ser obrigatoriamente feitas pela thread principal criada pelo navegador, com exceção da função pp::core::callonmainthread() 17. Além dessa limitação, a NaCl faz a manipulação de arquivos apenas após a aplicação retornar o controle de execução ao navegador, fazendo com que não seja possível o uso de operações bloqueantes pelo programador. Com isso, a NaCl não consegue simular operações síncronas para manipulação de arquivos, além da 16 Game Physics Simulation. < (Acesso 07/11/2012). 17 Application Structure - Native Client? Google Developers. < (Acesso 07/11/2012).

32 2.5 Java JNI 29 aplicação apresentar um comportamento diferente ao bloquear a thread principal. Uma proposta de solução para este problema é discutida e apresentada na Seção A visualização da cena é feita por meio da OpenGL ES 2.0 no projeto NaCl, assim sendo compatível com a API gráfica presente na Android NDK. A Native Client SDK faz a abstração das chamadas da OpenGL ES para o sistema operacional em execução. No caso do Windows por exemplo, as chamadas a OpenGL ES 2.0 são traduzidas em instruções da DirectX. Atualmente a NaCl é suportada apenas pelo navegador Chrome da Google, e pode ser executada nas plataformas Windows, Linux e Mac OS. 2.5 Java JNI A JNI, ou Java Native Interface, é uma poderosa ferramenta da plataforma Java, onde sua principal função é fazer a integração de aplicações Java com códigos escritos em outras linguagens, como C/C++. Aplicações Java são programadas utilizando a linguagem de programação Java, e então compiladas em classes binárias independentes de máquina. Essas classes podem ser executadas em qualquer dispositivo equipado com uma máquina virtual Java, ou JVM, assim seguindo a ideia de WORA 18. Já aplicações nativas são programadas utilizando linguagens de programação nativas, como C/C++ por exemplo, e são compiladas em formatos binários para uma máquina específica. A função da JNI é prover uma interface de duas vias entre essas aplicações, onde implementações Java ganham a capacidade de invocar códigos nativos, e vice-versa (LIANG, 1999). Essa característica de interface de duas vias da JNI cria duas formas de implementação: Aplicação Java invoca métodos nativos: JNI é usada para definir métodos nativos em aplicações Java, assim permitindo que essas acessem bibliotecas nativas. Os métodos nativos apresentam uma pequena variação na sua definição, porém as chamadas a eles são iguais as dos métodos tradicionais; Aplicação nativa invoca métodos da JVM: JNI oferece meios de embarcar a JVM 18 Slogan criado pela Sun Microsystems para ilustrar a capacidade multiplataforma da linguagem Java: Write Once, Run Anywhere.

33 2.6 Árvore 8-ária Hierárquica Octree 30 em aplicações nativas. Essas aplicações nativas são ligadas a uma biblioteca nativa que implementa a JVM, assim permitindo a invocação de métodos, por meio de uma interface, presentes na parte Java do software. Ao usar JNI, aplicações Java passam a se comunicar com aplicações nativas compartilhando o mesmo processo, assim permitindo a troca de informações entre as implementações de forma mais eficiente quando comparada com soluções que usam dois, ou mais processos, como Socket 19 por exemplo, pois anula o tempo extra de processamento para cópia e transmissão de um bloco de memória. Essa característica faz com que a JNI seja útil em cenários onde a API Java não suporta certas características de uma máquina, ou quando o desenvolvedor deseja implementar seções de alto desempenho usando linguagens de baixo nível, como Assembly. Porém, aplicações Java que fazem uso da JNI apresentam características não multiplataforma, pois elas dependem que a parte nativa funcione no mesmo ambiente de execução (LIANG, 1999). 2.6 Árvore 8-ária Hierárquica Octree Uma Octree é uma estrutura de dados em forma de árvore 8-ária hierárquica (MEAGHER, 1982), onde os dados são armazenados de forma espacial 3D. A versão análoga 2D de uma Octree é a Quadtree (PHAM; KIM; KO, 2007), a qual será mostrada nesta sessão por simplicidade. A Quadtree faz parte do grupo das estruturas de dados hierárquicas, e com isso mantém o princípio de decomposição recursiva. Esse tipo de estrutura é geralmente usado para pontos, curvas, regiões, superfícies e volumes (SAMET, 1984). O modelo de Quadtree mais usado para representação de regiões é baseado em subdivisões sucessivas da área em quatro partes de tamanhos iguais. Um exemplo de Quadtree é visto na Figura 2.5. A região da Figura 2.5(a) é mapeada em memória usando uma matriz, como na Figura 2.5(b). Essa matriz em Quadtree pode ser vista na Figura 2.5(c). A área B da Figura 2.5(c) não apresenta subdivisões pois ela contém apenas um tipo de informação, porém a área composta por F, G, H e I é subdividida por causa do conteúdo misto. O nível máximo da árvore é usado apenas para representações que requerem maior nível de precisão. A Figura 2.5(d) mostra, em forma de árvore, as subdivisões deste exemplo. 19 Uma ponta de um link de comunicação entre dois programas sobre uma rede.

34 2.6 Árvore 8-ária Hierárquica Octree 31 Figura 2.5: Exemplo da representação de uma região em Quadtree. a) Região. b) Representação em matriz de binários da região. c) Decomposição da região em blocos. d) Representação em Quadtree. Fonte: (SAMET, 1984). A Octree segue o mesmo princípio da Quadtree, porém com um eixo cartesiano a mais, assim, em vez de executar subdivisões sucessivas da área em quatro partes, ela é dividida em oito partes. A Figura 2.6 apresenta um exemplo de um simples objeto representado usando Octree. Para este exemplo, a ordem em que as células da Octree são organizadas na árvore é ilustrada na Figura 2.6(a). Já a Figura 2.6(b) mostra a estrutura da árvore gerada para armazenar um objeto simples. O nível 0 da árvore é a raiz, e essa engloba toda a Octree. Como esse nível contém células vazias e células cheias, ele é dividido em oito partes iguais, assim criando o nível 1. No nível 1, todas as oito células são analisadas e caso uma delas apresente conteúdo parcialmente cheio, essa será subdividida em oito partes de tamanhos iguais e assim gerando um nível 2. Esse processo é repetido até que as folhas da árvore contenham apenas células vazias ou cheias, como visto na Figura 2.6(b). Geralmente se estuda a Octree como uma árvore, porém, a representação dela em memória, e a computação de suas operações, podem ser implementadas de diferentes formas. Uma Octree pode ser organizada na forma clássica, em árvore, na memória

35 2.6 Árvore 8-ária Hierárquica Octree 32 Figura 2.6: Um objeto simples representado com Octree. a) Sequência das células e legenda dos valores da árvore. b) Representação do objeto em forma de árvore. Fonte: Traduzida e adaptada de (MEAGHER, 1982). (MEAGHER, 1982), onde um nó raiz contém oito nós filhos, onde cada nó filho terá outros oito nós filhos e assim até chegar na base da árvore. Outro método usado para organizar uma Octree é o de Z-Order, ou Morton Ordering. Neste método, a árvore é estruturada em um array unidimensional, e a localização das células nesse espaço é feita através de um algoritmo de ordenação de Morton (WARREN; SALMON, 1993). Cada método de estruturação da Octree apresenta vantagens e desvantagens. Uma variação do modelo clássico é a Adaptive Octree, que apresenta um menor consumo de memória, pois somente nós da árvore que apresentam conteúdo parcialmente cheio são subdivididos, como no exemplo da Figura 2.6(b). Porém, o acesso a esses dados precisam passar por vários níveis intermediários da árvore (LEE; MEI, 2012). Já o método Z-order consegue acesso aos dados com complexidade O(1), porém precisa de um espaço contínuo

36 2.7 Marching Cubes 33 na memória de acordo com o tamanho da Octree (WARREN; SALMON, 1993), ou seja, a implementação desse método do exemplo da Figura 2.6(b) iria subdividir os oito nós do nível 1 da árvore, assim aumentando o consumo de memória desse exemplo em 2,6 vezes. 2.7 Marching Cubes O algoritmo Marching Cubes, ou MC, foi desenvolvido para modelagem geométrica de alta resolução de imagens médicas. A função principal do algoritmo é a construção de uma representação poligonal de superfícies usando dados presentes em matrizes 3D. O modelo 3D resultante pode ser projetado em um plano 2D usando métodos convencionais (LORENSEN; CLINE, 1987). O princípio básico do algoritmo Marching Cubes é a subdivisão do espaço em uma série de pequenos cubos, para então marchar, como diz o nome do algoritmo, sobre todos os cubos procurando a fronteira do modelo, e substituindo esses cubos por conjuntos de polígonos adequados. A união de todos os polígonos será uma aproximação do modelo original. Para melhor compreender o princípio básico do algoritmo Marching Cubes, uma versão 2D do algoritmo é analisada. A Figura 2.7 apresenta o modelo, em forma de ellipse, que será aproximado. Além do modelo, uma grade está sobre ele, a qual representa os quadrados usados na marcha do algoritmo. O primeiro passo do algoritmo é identificar quais cantos dos quadrados estão dentro do objeto. A Figura 2.8(a) ilustra esse processo destacando tais pontos com a cor amarela. O segundo passo é a criação dos vértices, os quais estão destacados na Figura 2.8(b) com a cor vermelha. Essa etapa é executada assumindo que a fronteira do modelo fica aproximadamente entre os pontos que indicam seu interior e exterior. O último passo é a geração dos polígonos, porém, como esse exemplo usa apenas duas dimensões, a fronteira do objeto é representada por linhas, como visto na Figura 2.9. A implementação do algoritmo Marching Cubes em 3D funciona de maneira similar à versão 2D, com algumas diferenças. A primeira alteração é na malha de quadrados, pois agora passa a ser uma malha de cubos, e assim, ao contrário de quatro cantos do quadrado, o cubo apresenta oito. Cada canto do cubo pode apresentar dois estados, dentro ou fora do modelo. Assim, com oito cantos, um cubo apresenta 256 configurações

37 2.7 Marching Cubes 34 Figura 2.7: Modelo 2D, em forma de elipse, que será aproximado usando o princípio básico do algoritmo Marching Cubes. Fonte: Produção do próprio autor. diferentes levando em consideração os estados dos seus cantos. A primeira etapa do algoritmo 3D, que é a identificação dos cantos que estão dentro do modelo 3D, é executada, assim encontrando qual dos 256 estados cada cubo apresenta. As etapas de geração dos vértices e criação da malha poligonal é então executadas, substituindo o cubo sendo analisado por um conjunto de polígonos pré-definidos. A escolha de qual conjunto usar na substituição é feita de acordo com o estado dos cantos do cubo, assim, como há 256 estados distintos, há 256 conjuntos de polígonos pré-definidos. O problema é que a criação manual dos 256 conjuntos de polígonos prédefinidos é uma tarefa que pode inserir erros no sistema. Para evitar a triangulação manual desses 256 casos, Lorensen, et. al (1987) propõem o uso de 15 padrões únicos, ou também chamados de templates únicos, para geração automatizada dos outros casos. A Figura 2.10 ilustra os 15 templates únicos, incluindo o template vazio. Esses padrões únicos são inseridos no sistema manualmente, porém, cada um deles faz uso das propriedades simétricas do cubo e assim gerando todas as possibilidades de estados desses cantos. Cada um dos 256 casos é chamado de template de MC e armazenado em memória. Após a substituição de todos os cubos pelos templates de MC, a malha poligonal estará pronta para ser usada.

38 2.7 Marching Cubes 35 Figura 2.8: Modelo 2D, em forma de elipse, que será aproximado usando o princípio básico do algoritmo Marching Cubes. a) Pontos que pertencem ao objeto em amarelo. c) Vértices que aproximam a fronteira em vermelho. (a) (b) Fonte: Produção do próprio autor.

39 2.7 Marching Cubes 36 Figura 2.9: Modelo 2D, em forma de elipse, aproximado usando o princípio básico do algoritmo Marching Cubes. Fonte: Produção do próprio autor. Figura 2.10: Os 15 templates únicos do algoritmo Marching Cubes. Fonte: Adaptada de (LORENSEN; CLINE, 1987).

40 37 3 Estado da Arte Neste capítulo, trabalhos relacionados a este projeto são detalhados. A Seção 3.1 apresenta três pesquisas sobre a diferença de desempenho entre a Android SDK e a Android NDK. O trabalho da Seção 3.2 implementa parcialmente uma aplicação Android real em código nativo para obter melhor desempenho. Já a Seção 3.3 apresenta, descreve e compara as principais ferramentas para desenvolvimento de videogames para a plataforma Android. Por último, a Seção 3.4 descreve um sistema de compilação para aplicações C/C++ multiplataforma. 3.1 Comparação de Desempenho entre Java e C na Plataforma Android Os autores Lee e Jeon (2010) publicaram um trabalho comparando o desempenho de aplicações Android ao usar a linguagem C/C++ e Java. Foram usados um conjunto de algoritmos para testar diferentes aspectos, incluindo o tempo de comunicação entre a aplicação Java e o código nativo ao usar JNI, cálculos com números inteiros e reais e o tempo para acessar a memória principal. Este trabalho concluiu que o tempo gasto na comunicação da aplicação Java com o código nativo é insignificante. Os outros testes mostraram que os algoritmos em C são sempre mais rápidos que os executados apenas em Java na DalvikVM. O teste que se mostrou mais eficiente em código nativo foi o de acesso a memória, onde a aplicação usando apenas Java executou o algoritmo 26 vezes mais lentamente que as aplicações com códigos nativos. Já no teste usando operações com números reais, a aplicação usando código nativo apresentou um ganho de 24% no tempo de execução, assim sendo o teste com menor diferença. Os resultados foram obtidos usando o emulador Android, Android SDK 2.1 (API Level 7) e Android NDK R3, assim podendo não refletir de maneira correta os resultados se fossem repetidos atualmente com as ferramentas atualizadas, pois, por exemplo, JIT foi apenas introduzido a máquina virtual Dalvik após a Android SDK 2.2. Em 2011, outro trabalho (LEE; LEE, 2011) realizou testes similares ao trabalho

41 3.2 Aplicação Java portada parcialmente para C 38 de Lee e Jeon (2010). Os testes executados em tal trabalho incluem tempo de acesso JNI, cálculos com números inteiros e reais, tempo de acesso a memória e operações com strings. O tempo de acesso a JNI foi de apenas 1,14 microssegundos. O uso de código nativo obteve melhor desempenho em quase todos os testes, principalmente no acesso a memória. Porém, a linguagem Java apresentou um desempenho superior na manipulação de strings, pois strings em Java são diferentes do que em C, necessitando de uma conversão a cada chamada JNI. Estes testes foram executados usando a Android SDK 2.3, ou seja, já fazendo uso da JIT, porém ainda usando o emulador Android. O trabalho de Lin et al. (2011) fez uso de dispositivos reais, e não emuladores, para testar Java contra C++ na plataforma Android. O trabalho deles testou oito tipos de algoritmos distintos, incluindo cálculos numéricos, geração de números aleatórios, polimorfismo, recursão e operações com strings. Usando a média dos resultados obtidos, o trabalho concluiu que o desempenho da NDK é 34,2% mais eficiente. Os testes foram executados usando um aparelho HTC Desire A8181, com a plataforma Android 2.2. Versões mais recentes da arquitetura Android receberam atualizações aprimorando seu desempenho 1, com isso, ao executar esse teste usando uma versão atual da plataforma Android, os resultados podem ser diferentes do trabalho de Lin et al. (2011). 3.2 Aplicação Java portada parcialmente para C O artigo de Son e Lee (2011) descreve um trabalho onde a Android NDK foi usada para obter ganho de desempenho em uma aplicação implementada puramente em Java. objetivo desse trabalho é de acelerar o processamento da biblioteca NyARTooIKit, que é multiplataforma e escrita 100% em Java, na plataforma Android. Apenas uma tradução parcial da aplicação é feita, e para achar qual a região que mais demanda processamento, os autores Son e Lee (2011) usaram a ferramenta DDMS da Android SDK, descrita na Seção 2.2.4, para localizar qual método consome maior tempo de processamento. Esse método então foi traduzido para código nativo, acompanhado de algoritmos para mapear os tipos de dados Java para tipos de dados C. O método traduzido para a linguagem C se mostrou 63 vezes mais eficiente que sua versão em Java na plataforma Android. Já a aplicação como um todo, incluindo 1 Android 3.0 Platform. < (Acesso 07/11/2012). O

42 3.3 Ferramentas para Desenvolvimento de Videogames para Android 39 os métodos Java restantes, foi acelerada em 1,869 vezes. 3.3 Ferramentas para Desenvolvimento de Videogames para Android Android SDK A Android SDK oferece ferramentas para desenvolvimento de aplicações gerais, inclusive aplicações de entretenimento como videogames. Para a construção de um jogo, o desenvolvedor Android precisa criar uma Android View para fazer a comunicação de sua aplicação com o usuário. Caso ele queira desenhar objetos não presentes na Android SDK, o programador pode fazer uso da Android Canvas, pois ela pertmite trabalhar com funções de alto nível para exibição de gráficos 2D. Para as projeções de cenas mais avançadas, o desenvolvedor pode fazer uso da Android GLSurfaceView para chamar funções da OpenGL ES. As técnicas Android View, Android Canvas e Android GLSurfaceView são descritas com mais detalhes nas próximas subseções. Android View Android View 2 é uma classe presente na Android SDK. Essa classe representa a base para construção de componentes que fazem a comunicação com o usuário, seja por meios gráficos, ou tratando eventos. Assim, os diversos componentes que fazem a interação com o usuário são especializações da View. Entre esses componentes estão botões, campos de texto, barras de progresso e teclado na tela. Como a Android View apresenta bastante flexibilidade e a Android SDK oferece um conjunto de componentes já prontos e funcionais, é possível desenvolver um videogame usando essa tecnologia, como pode ser visto na Figura 3.1, com o jogo Logo Quiz 3, de J-ROEN. Neste jogo, a Android View é utilizada para mostrar um campo de texto na tela do dispositivo, além de tratar eventos de toque na tela com o teclado virtual. Porém, a Android View não foi projetada para desenhar interfaces gráficas dinâmicas e 2 View - Android Developers. < (Acesso 07/11/2012). 3 Logo Quiz. < (Acesso 07/11/2012).

43 3.3 Ferramentas para Desenvolvimento de Videogames para Android 40 complexas, por isso seu uso geralmente se limita a videogames com pouca demanda de animações, como por exemplo jogos de tabuleiro ou jogos que têm ações executadas em turnos. Figura 3.1: Android View sendo usada no videogame Logo Quiz, de J-ROEN. Fonte: Videogame Logo Quiz, de J-ROEN. Um videogame que queira usar componentes da Android View pode fazer isso sem ter que usá-los exclusivamente. Por exemplo, é possível usar campos de textos e botões da Android SDK em cima de uma cena sendo desenhada em OpenGL ES. Porém, ao usar Android View, esta parte do videogame será exclusiva para a plataforma Android, assim dificultando a portabilidade do aplicativo. Como a Android SDK disponibiliza os mesmos componentes para desenvolvedores de aplicativos em geral, o uso deles em videogames pode causar a perda da imersão do jogador com o mundo virtual do jogo caso o componente seja mal implementado, pois ele terá a mesma aparência quando usado em aplicações gerais.

44 3.3 Ferramentas para Desenvolvimento de Videogames para Android 41 Android Canvas A Android SDK oferece funções de alto nível para gráficos 2D por meio da Android Canvas 4. Além de carregar imagens 2D em memória, e desenhá-las na tela, a tecnologia Canvas também suporta a rasterização de formas geométricas, como linhas, círculos e retângulos, a partir de métodos de alto-nível. O uso da Android Canvas por desenvolvedores é facilitado ao oferecer funções de alto nível para trabalhar com gráficos 2D. Mas quando esta tecnologia é usada em conjunto com outras APIs presente na Android SDK, ela fica ainda mais acessível. Um desenvolvedor, com conhecimentos sobre como programar aplicações Android usando a SDK consegue se adaptar de forma rápida a tecnologia Canvas, pois basta alterar uma View de sua aplicação para fazer a integração da Android Canvas aos diversos outros sistemas necessários para a programação de um videogame (som, eventos de toque, sensores, ciclo de vida do aplicativo). A partir da API Level 11 (Android 3.0), a tecnologia Canvas suporta aceleração em hardware em algumas operações gráficas 5. Com isso, instruções visuais são executadas em GPU, ajudando a entrega de uma aplicação mais rápida. OpenGL ES e GLSurfaceView A Android SDK também oferece meios de invocar métodos OpenGL ES diretamente. Para isso, o desenvolvedor precisa iniciar o contexto OpenGL, que pode ser feito usando a classe GLSurfaceView. Essa Android View tem diversas funcionalidades, incluindo gerenciar uma janela usando EGL, separar a thread da interface gerada pela Android SDK da thread contendo o contexto OpenGL, e facilitar a integração da OpenGL ES com o resto da aplicação Android. A API OpenGL ES 1.X, em Java, está disponível a partir da Android 1.0. A Android SDK implementa uma API OpenGL ES similar a definida no documento J2ME JSR239 6, mas desenvolvedores podem escolher utilizar a API padrão. Já a API OpenGL 4 Canvas and Drawables. < (Acesso 07/11/2012). 5 Android 3.0 Hardware Acceleration. < (Acesso 07/11/2012). 6 Java Specification Requests JSR# 239. < (Acesso 07/11/2012).

45 3.3 Ferramentas para Desenvolvimento de Videogames para Android 42 ES 2.0 está disponível na Android SDK a partir da versão 2.2 (API Level 8), e segue apenas a API definida em JSR239. Como visto na Seção 2.3.2, a OpenGL ES suporta texturas compactadas. No caso do Android, não existe um formato de compressão de textura usado por todos os dispositivos Android, porém, algumas técnicas estão disponíveis para contornar tal problema. A primeira é requisitar, em tempo de execução, as capacidades OpenGL suportadas pelo dispositivo, incluindo quais formatos de compressão de texturas ele entende. O desenvolvedor pode criar rotinas, e recursos, para cada formato conhecido. Caso se queira suportar apenas um conjunto de formatos, é possível especificar no arquivo Android manifest os formatos que a aplicação usa, ou o desenvolvedor pode optar em não utilizar compressão de texturas. Assim como a Android Canvas, a GLSurfaceView também é facilmente acessível a desenvolvedores Android, pois, como ela é uma extensão da classe View, e tem um comportamento similar a outros componentes da Android SDK, a sua adaptabilidade é rápida. Videogames famosos, como Replica Island 7, foram desenvolvidos usando esta ferramenta, porém, ela é bastante dependente de recursos da Android SDK, assim dificultando a portabilidade da aplicação Android NDK A Android NDK também pode ser usada para desenvolvimento de videogames, porém, ela não oferece nenhum suporte além do acesso a OpenGL ES. Ao usar a Android NDK, com a linguagem de programação C/C++ em vez da Java, desenvolvedores conseguem otimizar melhor seus códigos para a plataforma Android, além de poder usar uma quantidade maior de bibliotecas úteis em videogames, e sem wrappers, como a Box2D 8, que é uma biblioteca especializada em simulações físicas 2D, originalmente escrita em C++. 7 Replica Island. < (Acesso 07/11/2012). 8 box2d - A 2D Physics Engine for Games. < (Acesso 07/11/2012).

46 3.3 Ferramentas para Desenvolvimento de Videogames para Android Game Engines com Suporte a Plataforma Android Unity3D A game engine Unity3D 9 é uma ferramenta comercial rica em recursos e funcionalidades para desenvolvimento rápido de videogames 3D em múltiplas plataformas alvo. Ela suporta construção de terrenos, luzes, simulação de materiais e substâncias, troca de mensagens e sincronização via rede, áudio, simulações físicas e programação em Javascript, C# e Boo. Mesmo aceitando programação via Javascript, a Unity3D afirma que esse código é compilado antes da execução, assim alcançando um desempenho similar ao de códigos nativos 10, como C++ por exemplo. Além do software que faz a execução do videogame, a Unity3D oferece um editor. Esse editor é capaz de gerenciar os recursos do videogame, executar pedaços do código, alterar a lógica do videogame em tempo de execução, construir cenários, construir sistemas de partículas, e outras funcionalidades. O desenvolvedor pode trabalhar com a Unity3D na plataforma Windows ou MAC OS, porém, seus videogames podem ser entregues nas seguintes plataformas: Windows, Mac, XBOX 360, PlayStation 3, Wii, ipad, iphone e Android. A licença para a plataforma Android começa custando a partir de 400 dólares 11. Unreal Engine 3 A UE3, ou Unreal Engine 3 12, é uma game engine 3D comercial com suporte a diversas funcionalidades para construção de videogames de vários gêneros. A lista de funcionalidades inclui animação, inteligencia artificial, áudio, sistema de partículas, cinemáticas, luzes, terreno, shaders, rede, física, computação distribuída e interface gráfica. O desenvolvimento de videogames com a UE3 pode ser feito inteiramento usando o editor incluído na game engine. A programação pode ser feita por meio da linguagem Unreal Script, que é uma linguagem de alto nível orientada a objetos similar a Java. Funções de código nativos podem ser chamadas por meio da Unreal Script, porém 9 Unity - Game Engine. < (Acesso 07/11/2012). 10 UNITY: Programming. < (Acesso 07/11/2012). 11 UNITY: Store. < (Acesso 07/11/2012). 12 Game Engine Technology by Unreal. < (Acesso 07/11/2012).

47 3.3 Ferramentas para Desenvolvimento de Videogames para Android 44 a linguagem em si não é traduzida para código nativo. Além de suportar a plataforma Android, a UE3 também entrega aplicações para as plataformas: ios, MAC OS, XBOX 360, Playstation 3, Playstation Vita e Windows. Corona Corona SDK 13 é uma game engine 2D comercial com foco em aplicações para dispositivos móveis, suportando as plataformas ios e Android. A lista de funcionalidades que ela suporta inclui anúncios, animação, áudio, criptografia, banco de dados, sistemas de entrada/saída, integração com Facebook, rede, loja virtual dentro da aplicação e física. A licença para a plataforma Android da Corona SDK custa a partir de 199 dólares por ano para desenvolvedores independentes 14. AndEngine AndEngine é uma game engine 2D open-source para produção de videogames exclusivos para a plataforma Android. Ela esconde completamente a OpenGL ES do desenvolvedor, tornando fácil a representação de sprites e atribuindo-lhes comportamentos e modificadores. A AndEngine acompanha várias classes utilitárias para manipular multi-touch e controles virtuais na tela do dispositivo, tile maps, parallax backgrounds, som e música, sistema de partículas, física, entre outras. AndEngine é programada usando a linguagem Java e as aplicações produzidas por ela são executadas em cima da máquina virtual Dalvik. libgdx A biblioteca libgdx é definida por seus criadores como um framework de alto desempenho e multiplataforma, e não uma game engine, ou seja, esta biblioteca é projetada para ser usada como fundamentação de game engines e videogames. O seu bom desempenho se dá pelo fato de usar código nativo em regiões de alto processamento e permitir que o 13 Ansca Mobile s cross-platform mobile app development tools. < (Acesso 07/11/2012). 14 Corona SDK Subscription Pricing. < (Acesso 07/11/2012).

48 3.3 Ferramentas para Desenvolvimento de Videogames para Android 45 desenvolvedor controle a OpenGL para melhor otimização de sua aplicação, sendo assim consideravelmente mais rápida que a AndEngine 15. A sua característica multiplataforma, além de permitir a disponibilidade do jogo a um público maior, permite baixar drasticamente o tempo do ciclo de construção/instalação/testes, pois o desenvolvimento e testes podem ser feitos no PC e exportados para a plataforma Android apenas para testes finais. CatCake CatCake 16 é uma game engine 3D multiplataforma construída para ser fácil de usar e de alto desempenho. Ela oferece suporte a plataformas Windows, Linux e Android. Entre suas principais funcionalidades, estão a projeção de modelos 3D, som, gerência de dispositivos de interface com o usuário, luzes, GLSL, fontes e gerência de memória, além de suportar programação de videogames em C++. Essa game engine não suporta o ciclo de vida da atividade Android, o que pode ser justificado por esta ser continuação do projeto Pogolyn 17, o qual não apresenta suporte a plataforma Android. A CatCake implementa seu próprio mapeamento entre OpenGL e OpenGL ES, onde a OpenGL é usada em Windows e Linux, e a OpenGL ES é usada no Android. Nenhuma versão da OpenGL é acessível ao desenvolvedor. O ambiente de desenvolvimento suportado pela CatCake em Windows usa a ferramenta comercial Visual C++, porém o projeto é distribuído sob a licença open-source MIT, e de acordo com o site do projeto, a última atualização no seu código foi feita no dia 24 de abril de jpct-ae A game engine 3D jpct-ae 18 Android. é uma versão da jpct traduzida para a plataforma Ela apresenta diversas funcionalidades para um desenvolvimento rápido de videogames 3D por meio da linguagem Java. 15 ZECHNER, M; Libgdx, Andengine & Rokon Micro-Benchmarks < (Acesso 07/11/2012). 16 catcake - An Open Source Graphics Engine. < (Acesso 07/11/2012). 17 Pogolyn. < (Acesso 07/11/2012). 18 jpct-ae - a free 3D engine for Android. < (Acesso 07/11/2012).

49 3.3 Ferramentas para Desenvolvimento de Videogames para Android 46 Como esse projeto é exclusivo para a plataforma Android e faz uso da linguagem Java, ele é de fácil integração com a Android SDK, assim facilitando o acesso aos recursos oferecidos pela SDK, como interface com o usuário e sensores por exemplo. A game engine jpct-ae usa uma licença própria, porém permite uso gratuito dela em aplicações open-source e comerciais Tabelas Comparativas A Seção 3.3 apresentou diversas ferramentas para o desenvolvimento de videogames destinados a plataforma Android. Essas ferramentas são então comparadas em seguida. A Tabela 3.1 apresenta uma comparação entre as tecnologias, levantando atributos como suporte a 2D/3D, para quais plataformas a ferramenta gera aplicações e qual a linguagem de programação que ela entende. Para uma ferramenta aparecer com suporte a 2D ou 3D, ela precisa oferecer funcionalidades de alto nível para tal tecnologia, por exemplo, é possível desenvolver aplicações em 2D usando a Unity3D, porém na Tabela 3.1 o suporte a 2D não aparece pois, para conseguir isso, o desenvolvedor precisa usar soluções não triviais. A Tabela 3.2 compara as ferramentas da Seção 3.3 com foco na plataforma Android. O primeiro atributo apresenta se a ferramenta gera código nativo para Android, o segundo mostra a capacidade de desenvolver e testar aplicações no PC sem ter que enviá-las para o dispositivo Android e o último atributo compara as licenças de software aplicadas nestas ferramentas. Ambas tabelas presentes nessa seção mostram como as principais ferramentas para desenvolvimento de videogames para a plataforma Android atualmente não cumprem todos os objetivos deste trabalho. Game engines complexas como Unity3D e UE3 não são otimizadas para a plataforma Android e são privadas. Ferramentas comerciais como a Corona SDK não são inteiramente acessíveis à comunidade open-source e bibliotecas como AndEngine, libgdx e jpct-ae usam a linguagem de programação Java. Game engines como a CatCake não suportam totalmente a plataforma Android. O uso das ferramentas Android SDK e NDK diretamente torna a aplicação exclusiva para a plataforma Android e também não oferecem funcionalidades específicas para desenvolvimento de videogames.

50 3.3 Ferramentas para Desenvolvimento de Videogames para Android 47 Tabela 3.1: Comparação entre as ferramentas para desenvolvimento de videogames para a Android. Solução Suporte a 2D/3D Plataformas Linguagens Suportadas Canvas Somente 2D Android Java GLSurfaceView Não Android Java Unity3D Somente 3D Web, Flash, PC, Mac, Wii, PS3, XBOX360, ios e Android Javascript, C# e Boo U3 Somente 3D Windows, Mac, XBOX360, PS3, Flash, ios e Android UnrealScript Corona Somente 2D ios, Android, Nook e Kindle Fire Lua AndEngine Somente 2D Android Java libgdx Somente 2D Android Java CatCake Somente 3D Windows, Linux e Android C++ jpct-ae Somente 3D Android Java Android NDK Não Android C/C++ Fonte: produção do próprio autor. Tabela 3.2: Comparação entre as ferramentas para desenvolvimento de videogames para a Android. Solução Código Nativo Depuração em PC Licença p/ Android Canvas Não Por emulador Apache 2.0 GLSurfaceView Não Por emulador Apache 2.0 Unity3D Sim Sim A partir de $1900 U3 Não Sim Privada Corona Sim Sim $199/ano AndEngine Não Não LGPL libgdx Não Sim Apache 2.0 CatCake Sim Sim MIT jpct-ae Não Não Livre Android NDK Sim Por emulador Apache 2.0 Fonte: produção do próprio autor.

51 3.4 Sistema de compilação para aplicações C/C++ multiplataforma Sistema de compilação para aplicações C/C++ multiplataforma Aplicações C/C++ podem ser desenvolvidas em diferentes plataformas e ambientes de desenvolvimento (IDEs). Além disso, uma única base de código pode ser construída com a finalidade de compilar em instruções de máquina específicas para cada plataforma alvo. O trabalho de Wojtczyk et al. (2008) apresenta um ambiente para desenvolvimento desse tipo de aplicação. Wojtczyk et al. (2008) argumentam que diferentes plataformas, como Windows, Mac OS e Linux, usam diferentes ambientes de desenvolvimentos, como Microsoft Visual Studio, XCode e GNU Autotools com Makefiles. Cada ambiente apresenta formas diferentes para descrição do projeto, e com isso, a manutenção pode ser elevada, principalmente quando se adiciona novos arquivos. Para auxiliar essa manutenção, Wojtczyk et al. (2008) fazem uso do projeto open-source CMake 19, pois ele providencia suporte a uma linguagem textual, e independente de plataforma e compilador, para descrição do projeto, facilitando a sincronização entre os ambientes. A ferramenta CMake consegue fazer uma separação completa entre os arquivos referentes ao código-fonte do projeto, dos arquivos referentes ao ambiente de desenvolvimento. Com uma única base de código, mais a descrição do projeto usando a linguagem do CMake, a ferramenta consegue gerar projetos para as diferentes IDEs, além de também suportar diferentes compiladores e compilação cruzada. No entanto, essa base de código precisa suportar as diferentes plataformas. Para facilitar o uso das diferentes APIs, e acesso ao hardware em diferentes sistemas operacionais, em uma única base de código, Wojtczyk et al. (2008) usam o design pattern AbstractFactory, que encapsula códigos específicos de uma plataforma em classes especializadas, e oferece-os por meio de uma classe abstrata. Essa classe abstrata funciona como uma interface genérica com o usuário. A Figura 3.2 apresenta um diagrama da implementação feita por Wojtczyk et al. de uma interface genérica para acesso a uma câmera. A camada inferior, composta pelas classes LinuxDC1394Camera, MacDC1394Camera e WindowsCMU1394Camera, apresenta códigos específicos para cada plataforma. A classe FirewireCamera oferece uma interface independente de plataforma 19 CMake - Cross Platform Make. < (Acesso 07/11/2012).

52 3.4 Sistema de compilação para aplicações C/C++ multiplataforma 49 para o usuário. O método FirewireCamera::createCamera() cria uma nova instância de FirewireCamera, usando uma classe da camada inferior apropriada de acordo com a escolha da plataforma alvo. Figura 3.2: Hierarquia de classes para acesso de uma câmera através de uma interface genérica. Fonte: (WOJTCZYK; KNOLL, 2008).

53 50 4 O Projeto Este capítulo descreve o projeto do framework deste trabalho. Durante as fase de design, implementação e testes que antecedem o primeiro release do projeto, o codinome Furai 1 será usado para referenciar este projeto, e assim facilitar a construção e explicação de documentos. A estrutura deste capítulo é composta de três seções. A Seção 4.1 declara e descreve os requisitos do sistema. A Seção 4.2 apresenta as ferramentas usadas no desenvolvimento, a organização dos arquivos e como o projeto Furai, como um todo, é dividido em projetos menores para atender ao requisito de cross-platform. Já a Seção 4.3 analisa o framework, apresentando a arquitetura do sistema por meio de diagramas de classes e de sequência. 4.1 Requisitos O projeto Furai apresenta dois tipos de requisitos. O primeiro tipo agrupa requisitos relacionados ao ambiente de desenvolvimento que é usado para desenvolver este projeto. O segundo tipo de requisitos reúne as necessidades e funcionalidades que são suportadas e implementadas pelo projeto Furai. A Figura 4.1 apresenta os requisitos para o ambiente de desenvolvimento. Cada requisito apresenta um valor alfanumérico único entre colchetes que é usado para identificação deste requisito neste documento. Ao analisar o conteúdo da Figura 4.1, alguns desafios são notáveis. O primeiro desafio é a compilação cruzada do requisito [RQ06], ou seja, a característica de um aplicativo Android ser compilado na plataforma PC. O segundo desafio é o requisito [RQ05], pois ele implica na simulação de uma aplicação Android na plataforma PC. O último desafio está presente no requisito [RQ04], pois envolve o uso de duas linguagens de programação em uma única base de código. O requisito [RQ07] é uma consequência do requisito [RQ05], pois, ao desenvolver uma aplicação para a plataforma Web, ela estará disponível para PC. A Seção 4.2 descreve o ambiente de 1 Furai significa voar na língua japonesa

54 4.1 Requisitos 51 desenvolvimento implementado para solucionar esses requisitos. Figura 4.1: Requisitos do projeto Furai para o ambiente de desenvolvimento. Fonte: produção do próprio autor. Os requisitos de funcionalidades do projeto Furai estão expostos na Figura 4.2. Essas funcionalidades são agrupadas em quatro categorias, essas são: gráfico, sistema de entrada, armazenamento e gerência de recursos. Na categoria gráfica, o requisito [RQ10] apresenta a necessidade de uma janela para uma aplicação usando OpenGL ES. Os requisitos [RQ11-14] demandam funções de alto nível para manipulação de câmera, projeção de texturas e de suporte a Bitmap Fonts. As soluções adotadas para os requisitos da categoria gráfica estão descritas na Seção O projeto Furai também trata a interação com o usuário por meio de sistemas de entrada e saída. Os dispositivos suportados são os citados nos requisitos [RQ16-18]. As soluções adotadas para os requisitos da categoria de sistemas de entrada estão descritas na Seção Funcionalidades de armazenamento persistente também estão presentes no projeto Furai. A persistência de dados em uma aplicação Furai é conseguida por meio de arquivos, por isso os requisitos [RQ20-21] apresentam as funções de gerência de arquivos necessárias. As soluções adotadas para os requisitos da categoria de persistência de dados estão descritas na Seção Suporte à gerência de recursos, como texturas e fontes, também está definido no projeto Furai. Tais recursos são carregados em memória por meio de métodos síncronos, [RQ22-23]. Quando um recurso é invalidado pelo sistema operacional Android, o mesmo será restaurado quando o usuário achar melhor usando o suporte ao ciclo de vida da atividade do projeto Furai, [RQ24].

55 4.2 O Ambiente de Desenvolvimento 52 Figura 4.2: Requisitos de funcionalidades do projeto Furai. Fonte: produção do próprio autor. 4.2 O Ambiente de Desenvolvimento A usabilidade do projeto Furai é complexa devido aos requisitos de multiplataforma, compilação cruzada e simulação/depuração da aplicação em PC. A característica multiplataforma aumenta o código fonte, dividindo o projeto em mais de uma parte, além de aumentar o número de bibliotecas dependentes. Compilações manuais desse framework se tornam inviáveis pois o número de chamadas ao compilador e a lista de argumentos de tais chamadas aumentam o suficiente para deixar o processo lento e com alta probabilidade de falhas humanas. Por isso, o projeto Furai adota ferramentas maduras para programação e construção de um sistema de compilação automática. Esta seção descreve a organização das partes que compõem o projeto Furai, as ferramentas usadas para a compilação do framework e codificação C/C++/Java em um mesmo projeto. O framework desenvolvido neste projeto suporta duas plataformas, Web e Android. Uma parte da implementação é feita independente de plataforma, ou seja, o mesmo código pode ser usado para ambas. Porém, alguns componentes precisam ser programados para uma plataforma específica, tornando-se incompatíveis com a outra plataforma. O projeto Furai separa essas implementações em três partes, como visto na Figura 4.3. Uma parte faz a implementação independente de plataforma, porém deixa em vazio componentes específicos de qualquer plataforma. Duas backends implementam códigos específicos para sua respectiva plataforma. Quando uma função é chamada, e a

56 4.2 O Ambiente de Desenvolvimento 53 parte independente de plataforma não contém a implementação, o sistema irá procurar a implementação na backend apropriada. Para o desenvolvimento de um videogame usando o framework, o usuário precisa implementar três aplicações distintas, como visto na Figura 4.3. A Aplicação Furai contém o código e todos os recursos de imagem, áudio, vídeo, etc, necessários. Toda a implementação da lógica do videogame é codificada na Aplicação Furai, porém ela não é executável. Para execução e depuração do projeto, o usuário implementa uma Aplicação Web e/ou uma Aplicação Android. Ambas aplicações contém o mínimo de códigos necessários para iniciar uma janela e assim executar a Aplicação Furai. Figura 4.3: Organização do projeto Furai. Fonte: produção do próprio autor. A descrição do sistema de compilação do projeto Furai é feita para a ferramenta CMake. Cada backend, Android e Web, e aplicações de usuários, geram um projeto separado, porém esses mantêm uma dependência entre eles. Para melhor controlar

57 4.3 A Arquitetura 54 essas dependências é usado um ambiente de desenvolvimento integrado, ou IDE, chamado Eclipse 2. A ferramenta Eclipse não só suporta a integração dos projetos do framework, como também suporta a linguagem C/C++, Java, e arquivos de configurações CMake, além de oferecer facilidades na execução do GNU Make e GNU Debugger. 4.3 A Arquitetura Esta seção descreve a arquitetura do projeto Furai por meio de diagramas. Cada diagrama contém um código de identificação alfanumérico único entre colchetes, e presente no início da descrição da sua figura. Os diagramas demonstram de forma simplificada a organização da implementação do projeto, e como os componentes se comunicam entre si. Interfaces são implementáveis por usuários, e classes abstratas representam que necessitam de implementação específica para cada plataforma. Durante a fase de design da arquitetura, diversos protótipos de software foram desenvolvidos para cobrir casos críticos do projeto Furai, onde cada caso crítico representa alguma dúvida quanto a implementação ou design. Com os casos críticos resolvidos, o design da arquitetura presente nesta seção apresenta a garantia que não precisará de mudanças para que o framework funcione, porém futuras mudanças na arquitetura podem acontecer para melhorar o desempenho ou a usabilidade, além das mudanças necessárias para adicionar novas funcionalidades. A Figura 4.4 mostra o diagrama da arquitetura do framework em uma visão geral. O framework é composto por cinco pacotes principais. O primeiro pacote, backends, agrupa as implementações específicas de plataforma. O pacote io contém objetos relacionados a dispositivos de entrada e saída que fazem interação com o usuário e ele está detalhado na Seção O pacote storage é analisado na Seção A parte gráfica do framework está implementada no pacote graphic, descrita na Seção O último pacote, core, implementa funções gerais do framework, e seu detalhemento está presente na Seção Dois diagramas de sequências, ilustrando a interação de diversos objetos do framework entre si estão presentes na Seção Eclipse - The Eclipse Foundation open source community website.. < (Acesso 07/11/2012).

58 4.3 A Arquitetura 55 Figura 4.4: [CD01] Diagrama da Arquitetura do Projeto Furai Core System Fonte: produção do próprio autor. O diagrama do pacote core, [CD02], é visto na Figura 4.5. Neste pacote está contido a classe abstrata Application. Essa classe tem como função inicializar a aplicação, instanciando os sistemas gráfico, de entrada e saída e de armazenamento persistente, além de abrir uma janela para o contexto OpenGL ES e gerenciar as mudanças de estado da atividade Android.

59 4.3 A Arquitetura 56 Figura 4.5: [CD02] Diagrama do pacote core do Projeto Furai. Fonte: produção do próprio autor. A interface ApplicationListenerI define os métodos que a Aplicação Furai, da Figura 4.3, deve implementar. Esses métodos são chamados pela classe Application quando algum evento acontece na plataforma de execução. A lista dos métodos, e como eles são executados, segue a baixo: oncreate: executado ao iniciar a aplicação; onresize: executado ao iniciar a aplicação, e toda vez que a janela mudar de tamanho. No caso da plataforma Web, a janela do navegador pode ser alterada pelo usuário, e no caso da plataforma Android, ao rotacionar o dispositivo, a tela pode alterar do modo retrato para paisagem, ou vice-versa; onpause: toda vez que a atividade na plataforma Android for para segundo plano, esse método será chamado. Na plataforma Web esse método será ignorado, ao menos que o usuário chame-o manualmente; onresume: caso a atividade Android que está em segundo plano ganhe foco novamente, este método será executado; onrenderloop: sempre que o dispositivo estiver pronto para desenhar um quadro da cena, este método será executado. Como as chamadas a OpenGL ES precisam ser feitas na mesma thread de seu contexto, esse método deve conter todos os comandos visuais;

60 4.3 A Arquitetura 57 ondestroy: método executado ao sair de uma atividade Android, ou fechar a janela do navegador Web. A classe abstrata Managed é implementada por objetos gerenciados pelo framework. Ao gerenciar um objeto, o framework garante que esse objeto não sofrerá com as mudanças de estados da aplicação Android, pois, espaços de memória da GPU da aplicação Furai podem ser apagados ou alterados quando ela entra em segundo plano pelo sistema operacional Android Storage System O pacote storage do framework tem como função oferecer persistência de dados para a aplicação. Neste projeto, a persistência é suportada por meio de arquivos. A Figura 4.6 apresenta o diagrama do pacote storage, [CD03], e as classes para gerência de arquivos. Figura 4.6: [CD03] Diagrama do pacote storage do Projeto Furai. Fonte: produção do próprio autor. A classe abstrata FileSystem é implementada em cada plataforma, porém, ela é usada como uma fábrica que instancia objetos do tipo File, os quais são usados independente de plataforma Input/Output System A interação com o usuário é feita com as classes presentes no pacote io. A visualização delas pode ser vista na Figura 4.7 com o diagrama [CD04].

61 4.3 A Arquitetura 58 Figura 4.7: [CD04] Diagrama do pacote io do Projeto Furai. Fonte: produção do próprio autor. A classe abstrata IOSystem é implementada por cada plataforma, e ela tem como função abstrair a captura/envio de dados de dispositivos de entrada/saída para a Aplicação Furai. Quando essa classe recebe um evento, como um botão do mouse sendo apertado por exemplo, ela irá traduzi-lo para um listener apropriado Graphic System O pacote graphic, do diagrama [CD05] visto na Figura 4.8, é dividido em dois níveis. O primeiro nível contém classes gerais referente a parte gráfica, já o segundo nível, encapsulado no pacote g2d, diagrama [CD05a] na Figura 4.9, contém apenas classes usadas para manipulação de gráficos 2D. A classe GraphicSystem, declarada no primeiro nível do pacote graphic, é implementada em cada plataforma, e é instanciada pela classe Application. Sua principal

62 4.3 A Arquitetura 59 Figura 4.8: [CD05] Diagrama do pacote graphic do Projeto Furai. Fonte: produção do próprio autor. função é criar uma janela para o contexto OpenGL ES, além de disponibilizar a interface da OpenGL ES 2.0 ao usuário quando requisitada. Ainda nesse nível se encontra funções para manipulação da câmera, e duas classes gerenciadas pelo framework, Texture e ShaderProgram. Ambas apresentam porções de memória alocadas na GPU, por isso precisam ser restauradas ao perder seu contexto. A classe Texture tem como função abrir um arquivo de imagem e carregá-lo na GPU. Já a classe ShaderProgram recebe o programa de shading e o compila para execução pela GPU. O pacote g2d, que agrupa classes especializadas em efeitos visuais exclusivamente 2D, contém as classes BitmapFont, Sprite, TextureRegion e SpriteBatch. Como o nome sugere, a BitmapFont oferece suporte a bitmap fonts para o framework. A classe Sprite, em conjunto com a TextureRegion, apresenta um meio conveniente para lidar com

63 4.3 A Arquitetura 60 Figura 4.9: [CD05a] Diagrama do pacote g2d do Projeto Furai. Fonte: produção do próprio autor. texturas, e permitindo que uma textura contendo diversas imagens possa ser dividida logicamente. Já a classe SpriteBatch faz a projeção de texturas no plano 2D em massa, contendo códigos especializados para esse tipo de operação para melhor desempenho Diagramas de Sequência Esta seção apresenta dois diagramas de sequência mostrando a interação entre diferentes objetos do sistema. A Figura 4.10 ilustra o diagrama de sequencia [SD01], onde mostra o processo de inicialização do framework. Antes de poder instanciar uma classe do tipo Application, o usuário precisa de um objeto implementando ApplicationListenerI. Com

64 4.3 A Arquitetura 61 isso, a Application começa o processo de criação dos diversos sistemas: entrada e saída, arquivos e gráfico. Quando esses sistemas terminarem seus processos de inicialização, a classe Application então começa a chamar os métodos da ApplicationListenerI conforme ela vai recebendo eventos do sistema operacional. Figura 4.10: [SD01] Diagrama de Sequência da inicialização do framework. Fonte: produção do próprio autor. O segundo diagrama de sequência, [SD02], mostrado na Figura 4.11, apresenta as interações de uma Aplicação Furai mínima com o framework. Essa aplicação vai apenas instanciar os objetos necessários para desenhar uma textura 2D em um plano 2D. Uma Aplicação Furai é implementada usando a interface ApplicationListenerI como base. No método oncreate, o usuário começa a criação de objetos essenciais para a aplicação. O primeiro objeto instanciado é um da classe ShaderProgram. Esse objeto é essencial pois a classe SpriteBatch precisa saber como desenhar as texturas na tela. Com o objeto do programa de shading pronto para ser usado, o usuário então prossegue instanciando a classe SpriteBatch, OrthographicCamera, Texture e UserTouchListener. O último passo dado nessa fase de criação é a inserção da instância da classe UserTouchListener no sistema que gerência entrada de dados. O método onrenderloop é usado para desenhar a textura na tela. Para atu-

65 4.3 A Arquitetura 62 Figura 4.11: [SD02] Diagrama de Sequência de um projeto mínimo implementado pelo ponto de vista do usuário. Fonte: produção do próprio autor. alizar as matrizes de projeções da câmera ortogonal, o método update da classe Camera é chamado antes de iniciar a descrição da cena. O método begin da SpriteBatch indica o início da declaração dos objetos que serão mostrados com o comando draw. No final da declaração, o método end irá enviar essas informações para GPU para então desenhar o quadro. Ao finalizar a aplicação, o método ondestroy é executado, o qual é usado para destruir corretamente os objetos criados pelo usuário.

66 63 5 Desenvolvimento Neste capítulo, detalhes da implementação deste projeto são apresentados. A Seção 5.1 documenta as principais diferenças entre as plataformas Android e NaCl. A documentação de como foi implementado o sistema de compilação multiplataforma está na Seção 5.2. Já a Seção 5.3 descreve o desenvolvimento da aplicação usada para testar a eficiência deste trabalho. 5.1 Diferenças entre Android e NaCl Ciclo de Vida da Aplicação Uma aplicação Android apresenta um ciclo de vida complexo, como visto na Seção 2.2, quando comparada com uma aplicação NaCl. Porém, é comum que uma aplicação Android tenha um comportamento típico de ficar em espera quando é colocada em background, por isso, o projeto Furai oferece duas alternativas para o desenvolvedor. A primeira alternativa esconde uma implementação que automatiza o controle da aplicação Android em background. Isso significa que ao usá-la, o desenvolvedor não é exposto a controles mais avançados da atividade Android, deixando o framework Furai executar uma operação de espera não ocupada até que o sistema operacional envie uma mensagem para aplicação informando que ela voltou a ativa. A vantagem dessa alternativa é que ela é multiplataforma, e enquanto a aplicação está em espera, ela não consome energia com processamentos. A desvantagem é que a aplicação não pode executar nenhum processamento enquanto espera. Algumas situações não são possíveis de implementar com essa solução, por exemplo onde se deseja implementar um relógio que não pára, inclusive ao receber uma chamada telefônica. A segunda alternativa oferece controle total da aplicação Android pro desenvolvedor. O uso dela é apenas para a plataforma Android, porém, as funcionalidades da primeira alternativa podem ser compartilhadas usando hierarquia de classes, mantendo

67 5.1 Diferenças entre Android e NaCl 64 a maior parte do código multiplataforma. Esse processo é feito usando a função RTTI 1, assim, em tempo de execução, o framework Furai pode identificar qual ciclo da aplicação o desenvolvedor está instanciando, e assim determinar as ações. A vantagem desse método é o maior controle, porém ele é mais complexo de ser implementado, e se o desenvolvedor não limitar o seu processamento, a aplicação pode consumir um nível alto de bateria enquanto ela não está visível ao usuário EGL e Pepper API A EGL é uma API multiplataforma para gerenciar janelas e contextos da OpenGL ES, como visto na Seção Essa API é suportada pela plataforma Android, e está disponível tanto pela Android SDK, como pela Android NDK. Já a plataforma NaCl não suporta a EGL. A gerência da janela é feita em Javascript usando elementos DOM 2, onde se define o tamanho da janela, e qual aplicação NaCl a ser carregada nela. O contexto OpenGL ES na plataforma NaCl pode ser criado de diversas formas, isso por que até a versão 15 da Pepper API, esse contexto OpenGL era criado diretamente no Chrome. A partir dessa versão introduziu-se a Pepper 3D API, assim, definindo uma solução oficial para o controle do contexto OpenGL, porém, diversos materiais, incluindo exemplos que acompanham a PAPPI, ainda usam soluções antigas e não mais suportadas pelo navegador Chrome atual. O projeto Furai faz uso da EGL para a plataforma Android e da Pepper 3D API para a plataforma NaCl, e assim, esconde essa peculiaridade de cada plataforma do desenvolvedor Pepper API fora da thread principal Um conjunto de funções da Pepper API precisa ser obrigatoriamente executado pela thread principal, como visto na Seção 2.4. Além desse problema, as funções da Pappi, mesmo quando executadas na thread principal, apenas agendam ações para serem executadas pelo navegador após o término do código do usuário. Por causa disso, se uma aplicação NaCl bloquear a thread principal na espera de um retorno de uma função da Pappi, essa 1 Habilidade do sistema para identificar em tempo de execução o tipo do objeto. 2 Convenção para representação e interação com objetos em documentos HTML, XHTML e XML.

68 5.1 Diferenças entre Android e NaCl 65 ira ficar em espera por um tempo indeterminado, pois o código da Pappi será executado apenas após a execução do código bloqueante terminar. Esse tipo de comportamento não é encontrado em outras plataformas. Para que a plataforma NaCl apresente o mesmo comportamento que a plataforma Android, o projeto Furai cria uma nova thread e a oferece ao usuário, deixando a thread principal sempre livre, assim podendo receber comandos tanto do navegador como do projeto Furai. Quando o usuário chama uma função para manipulação de arquivos usando a interface Furai pública, uma mensagem é encaminhada à thread principal para realizar a manipulação requisitada, para depois retornar uma resposta a thread secundária e então ao usuário. Porém, essa solução não se adapta bem com chamadas a OpenGL. A solução anterior funciona para manipulação de arquivos, onde o projeto Furai apresenta uma boa interface para uso nas plataformas NaCl e Android. Porém, a OpenGL ES 2.0 API é uma interface bem definida, e não seria ideal alterar ela para fazer o redirecionamento das chamadas de suas funções para a thread principal. Outro problema é o fato da sincronia entre threads prejudicar no desempenho da aplicação, assim, como é comum a OpenGL estar presente em seções criticas de desempenho, a quantidade de sincronias precisa ser reduzida. A solução implementada para as chamadas OpenGL em thread secundária, usando Pappi, pode ser vista na Figura 5.1. O primeiro problema, que é oferecer a mesma interface que a OpenGL, é solucionado interceptando as chamadas de funções da OpenGL. O compilador da Pepper API, e o conjunto de ferramentas que o acompanha, utiliza de macros da linguagem C++ para redirecionar as chamadas da OpenGL ES 2.0 para funções da Pepper API. A interceptação dessas funções pelo projeto Furai é feita forçando a definição desses macros no início da compilação, para então redefini-los. Por causa da grande quantidade de funções presentes na API da OpenGL, um parser, em Java, foi desenvolvido para analisar o arquivo original da OpenGL API e gerar, de forma automática, o código de interceptação e redirecionamento. Este parser está disponível no repositório do projeto Furai. Após interceptação da chamada da função, o projeto Furai salva o endereço de memória da função e cria uma cópia dos parâmetros usados e envia essas informações para a classe furai::naclmainthreadclass. Caso a aplicação do usuário possa continuar o processamento sem espera do retorno da função OpenGL, essa é então colocada em um

69 5.1 Diferenças entre Android e NaCl 66 Figura 5.1: Chamadas OpenGL, usando Pepper API, na thread secundária. Fonte: produção do próprio autor. buffer, assim, minimizando a quantidade de sincronias entre threads. Entretanto, algumas funções retornam valores e/ou passam valores por referência, necessitando assim de processamento imediato, então todas as funções no buffer são executadas pela thread principal, para então a função de processamento imediato ser executada e seu valor retornado ao usuário. A classe furai::naclmainthreadclass também é responsável pela troca de mensagens entre as threads para sistemas de comunicação entre Javascript e C++, e tratamentos de eventos de dispositivos de input, como teclado e mouse, assim permitindo que a aplicação NaCl do usuário seja executada inteiramente a partir de uma thread secundária, com o comportamento igual da plataforma Android quanto a funções bloqueantes Sistema de Log Quando se desenvolve uma aplicação para PC é comum enviar informações de forma textual para um terminal de texto. A plataforma Android não oferece um terminal, porém, é possível receber tais informações textuais no PC ligado ao dispositivo Android por meio do adb, como visto na Seção Aplicações NaCl também não apresentam um terminal, pois são executadas dentro de outra aplicação, o Chrome. Porém, é possível redirecionar esse texto de saída da aplicação NaCl para arquivos, ou enviar esses textos em forma de mensagens para a parte Javascript, deixando ela responsável pela apresentação ao usuário. O sistema de log do projeto Furai oferece uma interface genérica para enviar

70 5.2 Sistema de Compilação Multiplataforma 67 mensagens textuais ao desenvolvedor durante a execução da aplicação. Esse sistema é um componente fundamental no framework Furai. Ele não está projetado na arquitetura, nem incluído nos requisitos, mas foi um dos primeiros sistemas a serem desenvolvidos. A definição da função de log do projeto Furai é a mesma da função printf da linguagem C. Ou seja, o primeiro parâmetro é a formatação da mensagem, seguido de um número variável de parâmetros usados na mensagem. Essa função foi desenvolvida usando macros va list 3 da linguagem C++. A implementação dessa função na plataforma Android apenas faz a ligação dos métodos genéricos, com as funções da Android NDK. O método de log da plataforma NaCl que salva as mensagens em arquivo também segue a mesma ideia. Já o envio de mensagens para a linguagem Javascript requer uma etapa extra. Primeiramente, o texto de log recebe um cabeçalho único indicando que é um log, para então ser enviado a linguagem Javascript. Quando a parte Javascript recebe um evento, ela analisa-o verificando se a mensagem contém o mesmo cabeçalho do sistema de log. Caso sim, esse texto é então enviado ao console do navegador, onde o desenvolvedor pode abrir e ver as mensagens em tempo de execução. 5.2 Sistema de Compilação Multiplataforma O projeto Furai é um sistema multiplataforma, com a complexidade extra de gerar executáveis usando compilação cruzada, ou seja, compilação de aplicações Android e NaCl na plataforma Windows. A gerência do sistema de compilação é feita usando a ferramenta open-source CMake e seguindo o modelo proposto por Wojtczyk et. al (2008), como visto na Seção 3.4. A estrutura hierárquica dos arquivos segue a especificação do projeto vista nas Seções 4.2 e 4.3, e pode ser visualizada na Figura 5.2. O diretório raiz, ou furai na imagem, agrupa outros cinco diretórios: backends, core, graphics, io e storage. Cada um deles está relacionado a pacotes do diagrama da Figura 4.4. Os diretórios da pasta raiz, com exceção do backends, contém código-fontes independente de plataformas e a interface pública usada para comunicação com o usuário. agrupam códigos específicos a uma plataforma. Já os diretórios dentro do backends A separação de códigos específicos de plataforma em diferentes arquivos e 3 va list - C++ Reference. < (Acesso 07/11/2012).

71 5.2 Sistema de Compilação Multiplataforma 68 Figura 5.2: Estrutura hierárquica dos diretórios. Fonte: produção do próprio autor. diretórios é possível usando CMake. A Figura 5.3 mostra a sequência de diretórios que o sistema de compilação percorre. Os diretórios da pasta raiz serão sempre incluídos na compilação, porém, ao entrar no backends, a ferramenta CMake vai decidir, de acordo com a opção de plataforma alvo, qual diretório incluir na compilação do sistema, assim, por exemplo, códigos específicos para a plataforma NaCl nunca serão compilados para aplicações Android. Figura 5.3: Sequência de diretórios que o sistema de compilação percorre. Fonte: produção do próprio autor.

72 5.3 Aplicação Usada nos Testes 69 Para definir a plataforma alvo na CMake, o projeto Furai faz uso de arquivos toolchain. As plataformas NaCl e Android apresentam ferramentas de compilação distintas, cada uma apresentando suas próprias bibliotecas e geradores de instruções de máquinas, por exemplo, NaCl pode gerar instruções x86 e x86-64, enquanto Android oferece instruções para ARMv5, ARMv7a, ARMv7a with NEON, x86, MIPS e outras. Além disso, um projeto pode precisar de diferentes opções de otimizações em diferentes plataformas. Essas diferenças são definidas em arquivos toolchain da CMake. A função de tal arquivo é procurar as ferramentas de compilação para determinada plataforma alvo, encontrar as bibliotecas do sistema, definir configurações de otimizações e quaisquer outras configurações necessárias para a plataforma alvo. Esses arquivos estão disponíveis no repositório apontado no Capítulo Aplicação Usada nos Testes Para testar a eficiência deste trabalho, foi implementada uma aplicação que simule o custo computacional de videogames complexos reais. No jogo Overgrowth 4 os personagens humanóides são modelados em voxels para simulações físicas, e algoritmos para detecção de colisão. Esses voxels são então mapeados a uma malha poligonal de triângulos, para então apresentá-la ao usuário. Para a aplicação implementada neste trabalho, o modelo 3D usado é estruturado usando voxels em uma Octree usando o algoritmo Adaptive Octree. A visualização de tal modelo é feita por meio de uma malha poligonal gerada pelo algoritmo Marching Cubes usando os voxels como base. Essa aplicação foi implementada em C++ com o projeto Furai, e em Java com libgdx. O código fonte desta aplicação está disponível em A implementação está dividida em três etapas: Criação do Modelo 3D em Octree, Implementação do Algoritmo Marching Cubes e Criação da Malha Poligonal. A Seção descreve a implementação da Octree e o modelo 3D usado para testes. A implementação do algoritmo Marching Cubes é vista na Seção Já a Seção descreve como o algoritmo transforma os voxels em uma malha poligonal. 4 Overgrowth - Wolfire Games. < (Acesso 07/11/2012).

73 5.3 Aplicação Usada nos Testes Criação do Modelo 3D em Octree A implementação escolhida para gerência da Octree foi o algoritmo Adaptive Octree por causa de seu baixo consumo de memória. A implementação foi feita usando funções recursivas, onde cada nó armazena uma informação. Ao inserir um novo voxel, o algoritmo percorre da raiz até a localização espacial desejada, reservando os espaços de memória necessários. Após a inserção, o algoritmo percorre a árvore na direção inversa, das folhas até a raiz, verificando se as folhas daquele nível contêm a mesma informação, e caso sim, a informação é transferida para o nó pai, e as folhas eliminadas, assim, reduzindo o consumo de memória. A Figura 5.4 apresenta um exemplo desse processo, onde a Figura 5.4(a) mostra o estado inicial da árvore, e a Figura 5.4(b) o resultado final. Como pode ser visto, ao inserir um voxel na última célula do segundo nível da árvore, assim criando uma homogeneidade neste nível, essa informação é transmitida ao nó pai, para então eliminar todos os filhos. Outro exemplo, em um caso extremo onde a árvore é composta completamente por apenas uma informação, ela será representada apenas por um nó. Figura 5.4: Exemplo de uma redução de memória ao usar Adaptive Octree. Legenda: V = Vazio, P = Parcial e C = Cheio. a) Estado da árvore inicial. b) Estado da árvore após inserção de um voxel na última célula do segundo nível da árvore. (a) (b) Fonte: Produção do próprio autor. O modelo 3D usado nesta aplicação é construído em tempo de execução usando funções paramétricas da curva de Bézier e da esfera. Para cada iteração da curva de Bézier, é construída uma esfera referente a sua localização na curva. Esse princípio pode ser observado na Figura 5.5. No entanto, essa aplicação utiliza um número elevado de iterações, assim gerando um modelo cilíndrico. Os pontos espaciais que compõem a esfera

74 5.3 Aplicação Usada nos Testes 71 são então transformados em voxels e inseridos na Octree. Essa operação define o modelo 3D matemático, e é sempre representado por células, não havendo variações ao alterar o tamanho da Octree ou os pontos de controle da curva. O tamanho da Octree define a resolução em que o modelo 3D é estruturado na aplicação. Figura 5.5: Operação realizada para criação do modelo 3D usado na aplicação de testes. Fonte: produção do próprio autor. A curva de Bézier usada é a quadrática, a qual apresenta um ponto de controle inicial em (0, 0, 0), um ponto de controle final em (n, 0, 0), e um ponto de controle intermediário em (n; i; n), onde n é o tamanho da Octree, e i é um valor que varia a cada quadro da aplicação entre os valores 0 e n, assim gerando um efeito de que a curva é animada. Ao acessar a informação de um voxel, o algoritmo não apenas retorna a informação em si, mas também o endereço de memória da célula que a mantém. Com esse endereço, é possível acessar os nós vizinhos sem ter que visitar a árvore desde a raiz Implementação do Algoritmo Marching Cubes O algoritmo de Marching Cubes foi dividido em duas etapas: geração dos templates únicos e geração dos templates. A diferença entre templates únicos e templates normais no algoritmo MC pode ser vista na Seção 2.7. A geração de templates únicos é feita de forma manual, com um total de 14 variações, seguindo o trabalho de Lorensen, et. al (1987). Em cada template, se é inserida informações de indexação, número de triângulos e os triângulos. Cada triângulo recebe os parâmetros de vértices seguindo a regra da mão direita, e assim o cálculo do vetor unitário da normal é automatizado.