32 resultados encontrados para Mario Olofo

Do 0 ao ''algum lugar''

ja leu os artigos que coloquei no forum?

http://forum.zeeboclub.com/sdk-engines-game-makers-f25/instalacao-e-configuracao-do-ambiente-de-desenvolvimento-de-jogos-para-zeebo-completo-t1629.htm

http://forum.zeeboclub.com/sdk-engines-game-makers-f25/programacao-brew-teoria-e-ola-mundo-t2432.htm

http://forum.zeeboclub.com/sdk-engines-game-makers-f25/programacao-3d-no-zeebo-habilitando-aceleracao-de-hardware-via-opengl-es-t2570.htm

Após isso só falta a lógica do game para vc ter um joguinho rodando no simulador do Zeebo.

Programação 3D no Zeebo! - Habilitando aceleração de hardware via OpenGL ES

Programação 3D no Zeebo

1 - Introdução

Este tutorial é a continuação do "Programação BREW - Teoria e Olá mundo", e é aconselhável dar uma lida novamente nele para refrescar
a memória sobre como programar o básico em BREW para rodar nosso aplicativo. Nos códigos ilustrados abaixo,
toda referência da variável app é referência a nossa estrutura de aplicação, criada no tutorial anterior.

Este tutorial tem como intuito ensinar o mínimo necessário para habilitar a aceleração 3D no Zeebo via OpenGL ES.
É pre requisito saber ao menos o básico sobre C e/ou C++.


2 - Perfis de OpenGL ES

Neste tutorial iremos ver sobre OpenGL ES versão 1.1, que é a versão utilizada no Zeebo.
O OpenGL ES vem com dois perfis diferentes: Common e Common-Lite.

Uma das principais diferenças entre os perfis é que o perfil Common-Lite é voltado a plataformas que não tem
suporte eficiente a calculos com ponto flutuante, sendo usado apenas ponto fixo para simular casas decimais.

Quem quiser dar uma lida na especificação completa desta versão do OpenGL ES pode acessar o documento em PDF
no site da Khronos (em inglês): http://www.khronos.org/registry/gles/specs/1.1/es_full_spec_1.1.12.pdf

Iremos utilizar apenas a versão Common-Lite, já que o Zeebo e a placa de vídeo dele não suportam calculos com ponto flutuante.


3 - Iniciando o OpenGL ES

O OpenGL ES apenas define a API para renderizar poligonos 2D/3D e modificar seus atributos, sendo necessário
utilizar outra API para criar uma janela com um framebuffer compativel. A API multiplataforma recomendada é a EGL,
responsável por fazer link entre o OpenGL ES e o subsistema de vídeo nativo da plataforma. A especificação da EGL
pode ser encontrada também no site da Khronos, no link (em inglês): http://www.khronos.org/registry/egl/

Primeiramente precisaremos incluir alguns cabeçalhos no nosso código para utilizar o OpenGL ES:

Código:


#include <EGL_1x.h>
#include <GLES_1x.h>
#include <gles/egl.h>
#include <gles/gl.h>
#include <gles/glESext.h>


A inicialização pode ser dividida em:
- Requisição de uma conexão com o sistema gráfico nativo;
- Seleção da configuração do formato de pixel nativo mais próximo do formato que queremos;
- Criação do buffer para renderização;
- Criação de contexto para o display ao framebuffer com aceleração 3D;

Precisaremos de três variáveis para criar e gerenciar a conexão com o OpenGL ES:

Código:


EGLDisplay  eglDisplay;  // Responsável pelo acesso ao display
EGLSurface  eglSurface;  // framebuffer com aceleração 3D em hardware
EGLContext  eglContext;  // variável de gerenciamento de contexto


Estas variáveis devem ser adicionadas a estrutura nossa aplicação para poderem ser acessadas durante
a execução do nosso programa:

Código:


typedef struct
{
   AEEApplet a;
   AEEDeviceInfo  sDeviceInfo;

   /* Add suas variáveis aqui */

   /* OpenGL ES */
   EGLDisplay  eglDisplay;
   EGLSurface  eglSurface;
   EGLContext  eglContext;
}
Game;


Na BREW, para conseguirmos utilizar as funções de EGL e OpenGL ES como funções normais sem a necessidade de um
ponteiro para a interface correspondente, devemos chamar duas funções que encapsulam a carga das interfaces do EGL e OpenGL ES,
EGL_Init e GLES_Init:

Código:


int EGL_Init( IShell* pIShell );
int GLES_Init( IShell* pShell );


Código:


if( EGL_Init( app->a.m_pIShell ) != SUCCESS )
{
   return FALSE;
}

if( GLES_Init( app->a.m_pIShell ) != SUCCESS )
{
   return FALSE;
}


Após carregar as interfaces, podemos iniciar a conexão com o display genérico chamando a função eglGetDisplay:

Código:


EGLDisplay eglGetDisplay( NativeDisplayType display_id );


Código:


app->eglDisplay = eglGetDisplay( EGL_DEFAULT_DISPLAY );


NativeDisplayType é uma tipedef de ponteiro void (ou ponteiro para uma interface IDIB, no simulador) e o define
EGL_DEFAULT_DISPLAY é um valor nulo.


Agora precisamos iniciar o sistema de rasterização 3D (no Zeebo), chamando a função eglInitialize:

Código:


EGLBoolean eglInitialize( EGLDisplay dpy, EGLint* major, EGLint* minor );


Código:


if( eglInitialize( app->eglDisplay, NULL, NULL ) != EGL_TRUE )
{
   return FALSE;
}


Os dois ultimos parâmetros da função eglInitialize são ponteiros para variáveis do tipo inteiro, usadas para retornar a versão de OpenGL ES iniciada,
mas não são obrigatórios.

NOTA: A placa gráfica do Zeebo tem um sistema de economia de energia, desabilitando alguns componentes do hardware não utilizados.
O subsistema 3D é ativado quando a rotina eglInitialize é chamada e só é desativado novamente quando fechamos a comunicação com o display via eglTerminate (descrito mais pra frente).

Para criar o framebuffer com aceleração 3D, devemos informar ao EGL qual o formato de buffer que queremos, quantos bits para
os buffers de profundidade (depth buffer) e máscara (stencil buffer), para que ele possa nos indicar o índice da melhor
configuração suportada pelo hardware que atenda aos nossos requisitos.

Para fazer isso, precisamos criar uma lista de inteiros contendo o formato de pixel que queremos, da seguinte forma:

Código:


EGLint attributos[ ] =
{
   EGL_RED_SIZE,      5,
   EGL_GREEN_SIZE,    6,
   EGL_BLUE_SIZE,      5,
   EGL_DEPTH_SIZE,    16,
   EGL_STENCIL_SIZE,  4,
   EGL_NATIVE_RENDERABLE, EGL_TRUE,
   EGL_NONE
};


A sequência é bem simples, informando o atributo que iremos configurar seguido pelo valor que queremos que ele tenha.
O fim da lista é indicado pelo valor EGL_NONE.
A configuração acima segue o formato de pixel suportado pelo Zeebo, com formato de cor RGB 565, buffer de profundidade de
16 bits e 4 bits de buffer de máscara.

Existem vários outros atributos que podem ser modificados, e estão detalhados no documento da especificação do EGL (página 13).

Para saber qual a configuração de pixel que bate com os atributos que queremos, usamos a rotina eglChooseConfig:

Código:


EGLBoolean eglChooseConfig(
   EGLDisplay    dpy,
   const EGLint* atributos,
   EGLConfig*    configs,
   EGLint        config_size,
   EGLint*      num_config );


dpy é um ponteiro para a conexão com o display, atributos é a nossa lista de atributos, configs é um ponteiro para uma lista
de estruturas de formato EGLConfig, onde as configurações que baterem com os atributos que passamos serão armazenadas,
respeitando o limite de quantidade de estruturas, passado pelo parâmetro config_size e num_config é um ponteiro para um inteiro
que receberá um número indicando quantidade de configurações que tem os requisitos mínimos passados.
No Zeebo para simplificar, passamos apenas uma estrutura pois já sabemos que este é o formato nativo suportado nele:

Código:


EGLint    numConfigs = 0;
EGLConfig config = { 0 };
EGLint atributos[ ] =
{
   EGL_RED_SIZE,      5,
   EGL_GREEN_SIZE,    6,
   EGL_BLUE_SIZE,      5,
   EGL_DEPTH_SIZE,    16,
   EGL_STENCIL_SIZE,  4,
   EGL_NATIVE_RENDERABLE, EGL_TRUE,
   EGL_NONE
};

if( eglChooseConfig( app->eglDisplay, atributos, &config, 1, &numConfigs ) != EGL_TRUE )
{
   return FALSE;
}


Estamos quase lá, agora falta criar o framebuffer onde o OpenGL ES irá renderizar.
A rotina usada para esta função é a eglCreateWindowSurface:

Código:


EGLSurface eglCreateWindowSurface(
   EGLDisplay dpy,
   EGLConfig config,
   NativeWindowType win,
   const EGLint *attrib list );


O NativeWindowType é um ponteiro void, pois é uma abstração de uma janela nativa, dependente do sistema.
Esta janela nativa deve ser criada com os mesmos atributos que queremos ter no OpenGL ES, mas no caso da BREW,
vamos passar um ponteiro para uma estrutura com informações do display nativo.
Na BREW, a interface IDisplay tem um IBitmap, que por sua vez contem internamente as definições do buffer do display, que é o que queremos:

Código:


IBitmap* pIBitmapDDB; // Bitmap do display
IDIB*    pDIB;        // Device independent bitmap, requisitado através do bitmap do display

/* Cadê o bitmap do display? */
if( IDISPLAY_GetDeviceBitmap( app->a.m_pIDisplay, &pIBitmapDDB ) != SUCCESS )
{
   return FALSE;
}

/* Hmm blz, agora eu quero ele em formato independente, com acesso aos seus pixels: */
if( IBITMAP_QueryInterface( pIBitmapDDB, AEECLSID_DIB, ( void ** )&pDIB ) != SUCCESS )
{
   /* Erro, libera para decrementar referência: */
   IBITMAP_Release( pIBitmapDDB );

   return FALSE;
}

/* Agora sim, vamos criar um framebuffer com aceleração 3D e vincular ele ao IDIB do display: */
app->eglSurface = eglCreateWindowSurface( app->eglDisplay, myConfig, ( NativeWindowType )pDIB, NULL );

/* Libera para decrementar referência: */
IDIB_Release( pDIB );
IBITMAP_Release( pIBitmapDDB );

/* Não deu certo? retorna */
if( app->eglSurface == EGL_NO_SURFACE )
{
   return FALSE;
}


Por fim, vamos criar um contexto para gerenciar a renderização no framebuffer criado. A função para isso é a eglCreateContext:

Código:


EGLContext eglCreateContext(
   EGLDisplay dpy,
   EGLConfig config,
   EGLContext share_context,
   const EGLint *attrib_list);


Os únicos parâmetros que iremos passar serão os dois primeiros, sendo o primeiro o ponteiro para o EGLDisplay criado e o segundo a referência para a estrutura com o formato de pixel que queremos:

Código:


/* Criação do contexto de gerenciamento da renderização no nosso framebuffer */
app->eglContext = eglCreateContext( app->eglDisplay, myConfig, 0, 0 );
if( app->eglContext == EGL_NO_CONTEXT )
{
   return FALSE;
}


Agora é só mudar o buffer de renderização atual para o nosso framebuffer:

Código:


/* Indica que nosso framebuffer será usado à partir de agora: */
if( eglMakeCurrent( app->eglDisplay, app->eglSurface, app->eglSurface, app->eglContext ) != EGL_TRUE )
{
   return FALSE;
}


Pronto!
À partir daqui podemos dar comandos de OpenGL ES normalmente, e eles serão interpretados e executados na placa de vídeo do Zeebo!


4 - Brincando com o OpenGL ES e exibindo a cena renderizada

Como usaremos o perfil Common-Lite, preste bem atenção nos nomes das rotinas da API do OpenGL ES.
Sempre que tiver alguma rotina que receba valores em ponto flutuante, procure a respectiva que aceite ponto fixo. Normalmente essas rotinas em ponto fixo terminam com um "x", indicando isso.

Em BREW, para conseguirmos atualizar o display repetidamente, devemos usar um timer para nos avisar quando chegar a hora de atualizar o display novamente.
A função usada para isso é a ISHELL_SetTimer:

Código:


int ISHELL_SetTimer( IShell* pShell, int milisegundos, PFNNOTIFY func, void* IApplet );


Para que o sistema nos alerte numa frequência de 30 frames por segundo fazemos o seguinte:

Código:


ISHELL_SetTimer( app->a.m_pIShell, 33, ( PFNNOTIFY )GAME_TrataTimer, ( void * )app );


Note que 33 milisegundos = ~ 1 / 30 fps

Código:


#define VAL_UM    ( 1 << 16 )
#define ADD(a,b)  ( (a) + (b) )
#define SUB(a,b)  ( (a) - (b ) )
#define MUL(a,b)  ( ( ( long long )(a) *  (b) )  >> 16)
#define DIV(a,b)  ( ( (a)<<16) / (b) )

void TrataNovoFrame( void* IApplet )
{
   int aspecto;
   Game* app = ( Game* )IApplet;
   int verts[ ] = {
   /*  x          y    z */
       0,    VAL_UM * 2 - VAL_UM / 2,  0,
    VAL_UM, -VAL_UM,  0,
   -VAL_UM, -VAL_UM,  0
   };
   int cores[ ] = {
      0xffff0000,
      0xff00ff00,
      0xff0000ff
   };

   /* vamos querer ser alertados daqui a 33 ms de novo, entao avisamos o sistema que devemos ser chamados novamente: */   
   ISHELL_SetTimer( app->a.m_pIShell, 33, ( PFNNOTIFY )TrataNovoFrame, app );

   /* Vamos usar as dimensões da tela para redimensionar a nossa área de renderização */
   app->sDeviceInfo.wStructSize = sizeof( app->sDeviceInfo );
   ISHELL_GetDeviceInfo( app->a.m_pIShell, &app->sDeviceInfo );

   aspecto = DIV( ( app->sDeviceInfo.cyScreen << 16 ), ( app->sDeviceInfo.cxScreen << 16 ) );

   glViewport( 0, 0, app->sDeviceInfo.cxScreen, app->sDeviceInfo.cyScreen );
   glMatrixMode( GL_PROJECTION );
   glLoadIdentity( );
/* Perceba o "x" no final do nome da função. Indicativo que ela recebe valores em ponto fixo */
   glFrustumx( -VAL_UM, VAL_UM, -aspecto, aspecto, VAL_UM, 50 << 16 );
   glMatrixMode( GL_MODELVIEW );
   glLoadIdentity( );
   glEnable( GL_DEPTH_TEST );
   glShadeModel( GL_SMOOTH );
   glDisable( GL_LIGHTING );

   glClear( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT );

   i = GETTIMEMS( ) / 10;
   i = ( i << 16 );
   glLoadIdentity( );
   glTranslatex( 0, 0, -VAL_UM * 4 );
   glRotatex( i, 0, 0, VAL_UM );

   glEnableClientState( GL_VERTEX_ARRAY );
   glEnableClientState( GL_COLOR_ARRAY );

   glColorPointer( 4, GL_UNSIGNED_BYTE, 4, cores );
   glVertexPointer( 3, GL_FIXED, sizeof( int ) * 3, verts );

   glDrawArrays( GL_TRIANGLES, 0, 3 );

   eglSwapBuffers( app->eglDisplay, app->eglSurface );
}


Note que devemos registrar esta rotina no início do nosso aplicativo ou chamá-la ao menos uma vez manualmente para que ela se registre para ser chamada novamente depois de alguns milisegundos.


5 - Finalizando o OpenGL ES

Finalizar o OpenGL ES é muito simples.
Devemos indicar que não iremos mais renderizar em nosso contexto, destruir o contexto e o framebuffer para liberar memória e chamar eglTerminate, que irá desligar o hardware de aceleração 3D para economizar energia:

Código:


void FinalizaOpenGLES( Game* app )
{
   if( app->eglDisplay != EGL_NO_DISPLAY )
   {
      eglMakeCurrent( EGL_NO_DISPLAY, EGL_NO_SURFACE, EGL_NO_SURFACE, EGL_NO_CONTEXT );
      eglDestroyContext( app->eglDisplay, app->eglContext );
      eglDestroySurface( app->eglDisplay, app->eglSurface );
      eglTerminate( app->eglDisplay );
      app->eglDisplay = EGL_NO_DISPLAY;

      /* Devemos liberar as interfaces do EGL e OpenGL ES nesta ordem: */
      GLES_Release( );
      EGL_Release( );
   }
}


6 - Conclusão

Basicamente é isso!
A inicialização do OpenGL ES podemos colocar no tratamento do evento EVT_APP_START, iniciando o timer para chamar nossa rotina de renderização periodicamente.
Para finalizar, colocamos a rotina FinalizaOpenGLES dentro do tratamento EVT_APP_STOP. Lembre-se de cancelar qualquer timer pendente antes de finalizar o OpenGL ES, para que o sistema não trave. Para tal basta usar a função ISHELL_CancelTimer:

Código:


ISHELL_CancelTimer( app->a.m_pIShell, NULL, ( void * )app );


É isso, com isso concluimos a sequência de tutoriais ensinando a criar o ambiente de desenvolvimento para criação de jogos para Zeebo, iniciamos o aplicativo em BREW e habilitamos aceleração 3D em hardware via OpenGL ES!

No próximo tutorial irei ensinar a tratar os eventos de joystick do Zeebo, para criarmos aplicativos mais interativos.

Mario

Programação BREW - Teoria e Olá Mundo

Programacao BREW - Teoria e Olá Mundo


1 - Introdução

Demorou mas saiu, finalmente o primeiro tutorial voltado a programadores que querem
começar a programar para o Zeebo (ou qualquer plataforma que se use BREW).

Este tutorial é uma continuação do "Instalação e Configuração do kit de desenvolvimento
de jogos para plataforma Zeebo", e é aconselhável dar uma lida novamente nele para refrescar
a memória sobre a criação de projetos e configuração dos diretórios para os games.

Este tutorial tem como intuito ensinar um pouco sobre a BREW e como criar o mínimo necessário de código para se criar um aplicativo.
É pre requisito saber pelo menos o básico sobre C e/ou C++.


ATENÇÃO:
Para facilitar e agilizar o aprendizado sobre BREW, sugiro que você deixe sempre visível no
Visual Studio uma janela chamada "Code Definition", que pode ser visualizada indo no menu
View -> Code Definition Window ( Ctrl + Shift + V ).
Esta janela exibe onde foi definido o código que estiver sobre o cursor. Com isso, quando você
parar o cursor em um trecho de código da BREW, ela irá mostrar em que arquivo a definição foi feita
e exibirá o conteúdo do arquivo, muito útil para aprender mais sobre a BREW. Isso aumenta a velocidade
de aprendizado pois, quando o cursor estiver sobre uma função de alguma interface por exemplo, você poderá
ver todas as outras funções que a interface tem, evitando ter que parar toda hora para consultar o manual da BREW.


2 - Como funciona a BREW

BREW é um sistema cooperativo e se utiliza de uma idéia bem simples, também usada na implementação COM da Microsoft: factory e interfaces.
Pode-se dizer que o sistema é orientado a objetos, apesar de ser escrito totalmente em C, mas para entender
isso é necessário entrar um pouco mais o baixo nível da criação de uma classe em C++:

Uma classe, quando tem algum método virtual, contém uma tabela de ponteiro para funções, ou seja, a classe em C++:

Código:


class Teste
{
public:
    virtual ExibeTexto( const char* pTexto ) = 0;
};



é equivalente a estrutura em C:

Código:


typedef struct
{
    void ( *ExibeTexto )( const char* pTexto );
}
TesteVtbl;  // Vtbl = abreviação de virtual table

struct Teste
{
    TesteVtbl*  Vtbl;
};

typedef struct Teste Teste;



Quando a classe é instanciada, os ponteiros para as funções virtuais são iniciados com o endereço da função
referente aquela classe, então se uma classe é extendida e o método virtual é sobreescrito, uma instância da classe base
conterá um endereço de função diferente do ponteiro da função da classe derivada.

Exemplificando, uma classe derivada:

Código:


class Derivada : public Teste
{
public:
    virtual void EscreveTexto2( const char *pTexto, int numChars ) = 0;
};



é equivalente a estrutura em C:

Código:


typedef struct
{
    // Interface base
    void ( *ExibeTexto )( const char* pTexto );
    // Derivada
    void ( *ExibeTexto2 )( const char* pTexto, int numChars );
}
DerivadaVtbl;

struct Derivada
{
    DerivadaVtbl*  Vtbl;
};

typedef struct Derivada Derivada;



Pensando agora somente em interfaces, sabemos que elas são classes abstratas, sem construtor nem destrutor, apenas métodos virtuais públicos puros
que devem ser sobreescritos por uma classe concreta. Como então ela pode ser criada e destruída?
Aí que entra o design pattern factory.

Uma factory é uma classe ou função que é capaz de "fabricar" uma instância de uma classe concreta que implementa os métodos
públicos definidos pela interface. Normalmente quando uma fabrica é uma classe, ela é criada usando o design singleton.
Vamos usar a forma mais simples, uma função, para exemplificar a criação de uma instância de uma interface.

Em C++:

Código:


// Implementa a interface Teste
class TesteImpl : public Teste
{
public:
    void EscreveTexto( const char* pTexto )
    {
        if( pTexto )
        {
            printf( pTexto );
        }
    }
};

// Cria uma instância da interface Teste
Teste*  TESTE_CriaInstancia( void )
{
    return ( new TesteImpl );
}



Em C:

Código:


// Implementação do método virtual
static void EscreveTexto( const char* pTexto )
{
    if( pTexto )
    {
        printf( pTexto );
    }
}

// Cria uma instância da interface/estrutura Teste
Teste* TESTE_CriaInstancia( void )
{
    Teste* teste = ( Teste* ) malloc( sizeof( Teste ) );

    if( teste != NULL )
    {
        teste->Vtbl = ( TesteVtbl* ) malloc( sizeof( TesteVtbl ) );

        if( teste->Vtbl != NULL )
        {
            // Inicia tabela de funções virtuais com endereço de funções válidas:
            teste->Vtbl->EscreveTexto = &EscreveTexto;
        }
        else
        {
            free( teste );
            teste = NULL;
        }
    }
    return teste;
}



Do ponto de vista de quem usa a interface, a única diferença seria que, quando compilando o sistema em
C, o acesso as funções devem ser feitas manualmente através da tabela de funções...
Para que isso seja transparente, uma simples definição pode ser feita:

Código:


#if defined( __cplusplus )
#define  TESTE_EscreveTexto( p, t )  p->EscreveTexto( t )
#else
#define  TESTE_EscreveTexto( p, t )  p->Vtbl->EscreveTexto( t )
#endif


Usando sempre a definição criada, a aplicação acessa os métodos de forma transparente
e compatível entre projetos em C e C++ ( um exemplo dessa forma de programação pode ser encontrada
nos cabeçalhos do SDK do DirectX da Microsoft ).


Você pode estar se perguntando: para quê tudo isso?!


Bom, normalmente, as interfaces/objetos são adicionados ao sistema gradualmente, com updates e upgrades,
então é sensato pensar em construí-los separadamente, em DLLs por exemplo.
Dessa forma, podemos carregar na RAM apenas as DLLs que realmente estiverem em uso, apenas uma vez só,
e gerenciar a quantidade de referencias que temos a ela, ou seja, carregamos o código da interface na RAM
uma vez e gerenciamos quantas instâncias dela temos em tempo de execução. Quando a quantidade de referências
chegar a zero, ela não está mais sendo usada por nenhuma aplicação, tornando possível removê-la da RAM para
liberar espaço.

Para esse gerenciamento, o método adotado foi incluir 2 métodos na interface base, AddRef e Release. Cada vez
que uma nova instância é criada e mapeada as funções corretas, o contador de referências é incrementado. Quando
uma interface não é mais utilizada, chamamos Release para que ela decremente seu contador de referências e
descarregue a interface da memória se a contagem chegar em zero.

Se existir alguma dúvida sobre isso, sugiro reler o tópico e fazer alguns experimentos até que essa forma
de funcionamento esteja bem claro, caso contrário, você não terá um entendimento mais aprofundado do que
está acontecendo quando entrarmos na programação em BREW.

O sistema de interface adotado na BREW pode ser encontrada nos arquivos AEEInterface.h, AEEIBase.h e AEE.h,
e o seu funcionamento é igual ao explicado aqui, tirando algumas peculiaridades ou formas diferentes de se
chegar ao mesmo resultado.


3 - Aplicativos em BREW - a estrutura AEEApplet

Nossos programas em BREW são derivados de uma 'classe' base, chamada AEEApplet.
Ela tem a tabela de funções da interface IApplet, além de atributos úteis para nossa aplicação.
Quando eu digo derivada, é porque a nossa aplicação vai conter todos os dados da nossa instância em
uma única estrutura, que tem como primeiro atributo uma variável do tipo AEEApplet.
E daí?
E daí que com isso, vamos pedir para a fábrica de applets gerar uma instância da interface IApplet,
mas passando o tamanho da nossa estrutura e um ponteiro para a nossa função de tratamento de eventos,
fazendo a estrutura gerada ser maior, sendo necessário apenas fazer um cast de IApplet para nossa estrutura para acessar todas as nossas variáveis!


Em código isso seria o seguinte:

Código:


typedef struct
{
    AEEApplet a;
    AEEDeviceInfo  sDeviceInfo;

    /* Add suas variáveis aqui */
    uint32  dPosicaoX;
    uint32  dPosicaoY;
    IBitmap* pJogadorBmp[ NUM_FRAMES ];
    /* ... */
}
Game;



Note que apesar de em C/C++ nós acessarmos a estrutura AEEApplet via variável a, internamente essa estrutura é o mesmo que:

Código:


typedef struct
{
    /* AEEApplet a; expandida abaixo */

    IAppletVtbl*  vtbl;

    AEECLSID      clsID;
    uint32        m_nRefs;
    IShell    *    m_pIShell;
    IModule  *    m_pIModule;
    IDisplay  *    m_pIDisplay;
    AEEHANDLER    pAppHandleEvent;
    PFNFREEAPPDATA pFreeAppData;

    /* Não expandida aqui pq é gigante -.- */

    AEEDeviceInfo  sDeviceInfo;

    /* Add suas variáveis aqui */

    uint32  dPosicaoX;
    uint32  dPosicaoY;
    IBitmap* pJogadorBmp0;
    IBitmap* pJogadorBmp1;
    IBitmap* pJogadorBmp2;
    IBitmap* pJogadorBmp3;
    IBitmap* pJogadorBmp4;
    IBitmap* pJogadorBmp5;
    /* IBitmap* pJogadorBmp ...  NUM_FRAMES vezes  */
}
Game;



Provando assim que 'derivamos' da classe IApplet (ou AEEApplet se quiser )


NOTA:
Esta estrutura é onde TODAS as suas variáveis globais ao seu aplicativo devem ficar, pois em BREW não existe variável global! Nunca declare uma variável global, pois vai funcionar no simulador,
mas não vai compilar em um compilador para celular.

NOTA2:
Zeebo NÃO tem suporte a ponto flutuante, ou seja, simularemos frações usando números inteiros ;D

NOTA3:
NADA NUNCA NEM SE ATREVA A USAR LAÇOS INFINITOS DE REPETIÇÃO OU MUITO DEMORADOS!
BREW é um sistema cooperativo, o que significa que temos que colaborar com os outros aplicativos que estiverem rodando também, deixando o sistema operacional gerenciar tudo e abrir a boca apenas quando ele quiser que a gente trate alguma mensagem =)

NOTA4:
SEMPRE faça casts explícitos para evitar problemas se um dia for compilar seu game para o Zeebo real.
Preste sempre atenção no tipo das variáveis, tanto quando compilando para o simulador quanto para um target, pois a maioria das variáveis tem 32 bits de tamanho no simulador para facilitar o alinhamento dos dados, quando no target original ela tem apenas 8 bits...

NOTA5:
Zeebo é big endian. PC é little endian, o que significa que se você ler um int de um arquivo,
ele estará com os Bytes em ordem invertida, podendo causar várias dores de cabeça!


4 - Olá mundo BREW


Como vamos conseguir instanciar uma aplicação nossa? Como vamos saber que realmente é a nossa aplicação que foi instanciada?

Toda interface na BREW tem um identificador único, que é definido no arquivo .bid.
A nossa aplicação não é exceção, e isso foi explicado no tutorial anterior.

Toda implementação também deve criar uma fábrica, mas deve seguir a seguinte assinatura:

Código:


int AEEClsCreateInstance( AEECLSID dId, IShell* pIShell, IModule* pMod, void** ppObj );


AEECLSID (aee class identifier) é o identificador da interface que o sistema está pedindo para instanciar.
Se este valor for diferente do qual nós informamos no arquivo .bid, simplesmente retornamos erro e fingimos que não sabemos de nada .

Se o valor estiver correto, devemos alocar memória para nossa instância, mapear a tabela da IApplet para as funções corretas, adquirir uma instância da interface de gerenciamento do display (IDisplay) e registrar nossa rotina para finalização do applet e rotina de tratamento de eventos para sermos notificados sobre novos eventos enquanto nosso aplicativo estiver com o foco:

Código:


int AEEClsCreateInstance( AEECLSID dId, IShell* pIShell, IModule* pMod, void** ppObj )
{
    if( AEEApplet_New( sizeof( Game ), dId, pIShell, pMod, ( IApplet** )ppObj, ( AEEHANDLER )GAME_TrataEvento, ( PFNFREEAPPDATA )GAME_Finaliza ) )
    {
        return AEE_SUCCESS;
    }
    return EFAILED;
}



Ahhh tá bom vai, eu quis assustar um pouquinho =P
A função AEEApplet_New faz todo o trabalho sujo para nós, e está disponível no arquivo AEEAppGen.c para os curiosos de plantão verem como ela faz toda a inicialização.

As funções GAME_TrataEvento e GAME_Finaliza serão discutidas a seguir:

Para termos a chance de liberar a memória utilizada durante a execução do nosso programa, podemos, não obrigatoriamente, registrar uma função para tal, sem retorno e com um único parâmetro que receberá a instância da aplicação que está sendo finalizada

Código:


void FreeAppData( IApplet* pIApplet );


No exemplo da criação da instância eu nomeei esta rotina de GAME_Finaliza.
Lembre-se que sempre que o parâmetro vindo do sistema for uma instância da interface IApplet, significa que esta instância na realidade é um ponteiro da nossa estrutura, podendo ser convertida com um cast sem medo.


Para ouvirmos os eventos do sistema registramos a rotina que eu nomeei no exemplo acima como GAME_TrataEvento, que tem o formato

Código:


boolean AppHandler( void* pData, AEEEvent evt, uint16 wParam, uint32 lParam );


Devemos retornar TRUE se tratarmos o evento e FALSE se não tratarmos, para que o sistema saiba quando ele mesmo deve tratar o evento ou não.
A lista de eventos possíveis está no arquivo AEEEvent.h.
Os eventos que devem ser tratados no mínimo incluem EVT_APP_START, EVT_APP_STOP, EVT_APP_NO_SLEEP, EVT_APP_SUSPEND E EVT_APP_RESUME:

Código:



/*
    Rotina de tratamento dos eventos do game.
    Todo game para BREW deve conter essa rotina para tratar
    os eventos gerados pelo sistema operacional, como
    tecla pressionada, tecla solta, etc.

    Se o evento for tratado, retorne TRUE para avisar
    o sistema operacional que você tratou o evento.
*/
boolean GAME_TrataEvento( Game* app, AEEEvent dEvento, uint16 wParam, uint32 dParam )
{
    switch( dEvento )
    {
        /* Evento recebido quando criamos nossa instância.
          Devemos carregar os dados necessários para rodar o game aqui
        */
        case EVT_APP_START:
        {
            if( GAME_Inicia( app ) == FALSE )
            {
                ISHELL_CloseApplet( app->a.m_pIShell, FALSE );
            }

            /* Escreve um olá mundo e atualiza a tela.
              É realmente aconselhável que todos tentem estudar e entender como funcionam
              as interfaces que mais utilizaremos como a IDisplay, IShell, IFileMgr, IBitmap e IDIB.
            */
            IDISPLAY_ClearScreen( app->a.m_pIDisplay );
            IDISPLAY_SetColor( app->a.m_pIDisplay, CLR_USER_TEXT, 0 );
            IDISPLAY_DrawText( app->a.m_pIDisplay, AEE_FONT_NORMAL, L"Olá mundo BREW", -1, 0, 0, NULL, 0 );
            IDISPLAY_Update( app->a.m_pIDisplay );

            return TRUE;
        }
        /* Finalizamos? se sim retornamos verdadeiro */
        case EVT_APP_STOP:
        {
            return TRUE;
        }
        /* Diz q não queremos que o sistema entre em sleep mode */
        case EVT_APP_NO_SLEEP:
        {
            return TRUE;
        }
        /* Nossa aplicação não vai tratar suspend e resume, vai simplesmente
          finalizar caso isso ocorra */
        case EVT_APP_SUSPEND:
        case EVT_APP_RESUME:
        {
            ISHELL_CloseApplet( app->a.m_pIShell, FALSE );
            return TRUE;
        }
        default:
        {
        }
    }
    return FALSE;
}



No arquivo AEEEvent.h tem a lista de todos os eventos possiveis e o que esperar nos seus parâmetros (wParam e dParam).


Com isso encerramos esta segunda parte de uma série sobre programação para o Zeebo.

O próximo artigo terá a explicação detalhada da inicialização do OpenGL ES em cima da inicialização do nosso aplicativo em BREW.

Mario

Teste de programação no Zeebo - Doom3 xD

ALisson001 escreveu:Novidades?

Então, tive que parar essas semanas por causa das provas da faculdade, mas final dessa semana terminam e eu já vou ter mais
tempo para terminar os artigos sobre brew e brew+opengl es para postar aqui na área de programação.

Gringo o escreveu:Mario,vc parece manjar dessas coisas de jogos. Que tal nos ajudar no nosso projeto de jogo, o tópico está na parte do SDK aqui do fórum, o nome do tópico é Criação de um jogo. Se tiver interesse passa lá.

Abraço.

Infelizmente como eu disse, só posso voltar a programar pro zeebo após essa semana de provas, daí vou me interar do andamento do projetos de
vocês e se tiver como eu dar uma força eu ajudarei sim sem problemas

Mario

Pra quem já tem o Zeebo: e a interface gráfica?

haha e esse negócio de telas rolando é descrito na caixa do zeebo como uma 'feature' xD
realmente a interface deveria ser mais intuitiva, logo quando vc está na tela
principal, aparecem os jogos... q estão a venda, e não os que vc tem!
daí vc vê lá em cima o game e vê um botão "jogar", vc clica e ele rola a tela
pra uma outra nada a ver! é meio estranhão né ^^

Duvida Specs do Zeebo e Iphone 3G.

[quote="ZeeboTectoy"]

Mario Olofo escreveu:
é meio abobrinha oq vc postou!.. Oq interessa é o jogo sendo criado e o resultado final!
1.6milhoes de triangulos em cada cena onde vc podera usar shaders e outros efeitos da pra se fazer coisas realmente incriveis! Oq torna isso pequeno ou ruim.. é o fato de termos consoles que rodam jogos a resoluçoes de 1080 x ? com 500milhoes de triangulos e outras coisas mais! Ps1 tinha 300mil poligonos e conseguiu ter bons titulos pq o zeebo com 1.6milhoes nao pode ter bons jogos graficamente? Poligonos nao é tudo! Criaçao sim!

Bom, cada um tem uma opinião diferente e essa é a sua e aquela é a minha.

Pense direito, você não tem 1,6M de triângulos em cada cena, divida isso pelo fps do game q normalmente é uns 30 quadros por segundo e vc tem
53.333 triangulos por frame para usar, pensa direito e veja a diferença do que se pode fazer com 1,6M ou apenas 53 mil.

Outra coisa q acho q vc nao leu direito é o fato de você dizer em usar shaders... em nenhum lugar está escrito que o Zeebo suporta shaders.
OpenGL ES 2.x suporta vertex e pixel shaders, mas o usado no Zeebo (1.0) não suporta nem ponto flutuante!

Outra, você escreveu que o PSX roda 500 mil triangulos por segundo, está meio correto, ele roda 500 mil usando todos os 'efeitos' durante renderizacao (efeitos no sentido de se ativar transparencia/translucencia, textura e luminosidade). O correto seria 1,5M para a capacidade total com poligonos simplificados.

Este tipo de polígono mais simplificado serve para ser usado em alguns lugares onde textura não ajudam em nada e só a cor do triângulo já é o suficiente
para simular o objeto, por exemplo, vocês podem ver crash bandicoot do Zeebo mesmo, muitos dos lugares do ambiente e dos personagens não tem
textura, é apenas cor.

Estes são os limitantes que eu vi e q posso dizer que dificulta a criação do jogo para o Zeebo, e tem muito fundamento o que eu disse logo q trabalho na área
Muita coisa que vc escreveu eu escrevi tbm no início do tutorial explicando como programar para Zeebo, e também acho que se conhecendo as limitações do sistema e fazendo uma versão de game exclusiva para cada sistema faz com que a qualidade seja ótima na medida do possível para cada plataforma.

Duvida Specs do Zeebo e Iphone 3G.

pavao escreveu:mas atectoy falo 4 milhoes, tectoyainda mentindo hein? ou continua a confusão?.

Onde já se viu setor de vendas e marketing dizerem a verdade? xD

Duvida Specs do Zeebo e Iphone 3G.

Vamos lá, sobre o Zeebo:

- Processador ARM11 SEM suporte a coprocessador de ponto flutuante, o que faz ele ter que 'simular' frações usando números inteiros, e isso piora um pouco os cálculos de geometria;
- 128 MB de RAM mas não sei quanto dessa memória está disponível para o game, logo que essa memória tbm é compartilhada com o SO;
- Processador gráfico da Qualcomm, com 256kb de memória interna para os framebuffers e surpreendentes 8kb de 'cache' para textura!
- OpenGL ES no Zeebo suporta 8 luzes simultâneas, mas são calculadas sem aceleração de hardware

Os maiores limitantes do Zeebo são o sistema Operacional BREW q é um sistema operacional cooperativo, e a quantidade de memória do processador gráfico para armazenar a textura atual durante a rasterização, que com 8kb suportaria no máximo uma textura de 128x128 rgb com compressão.

No "ZeeboDeveloperGuide.pdf" que vem no SDK do Zeebo eles informam o seguinte:

Polygon performance: 1.6M triangles per second;
3D pixel Fill Rate (textured): 63M polygons ( 2 textures );

Eu creio que o 'polygon performance' é a quantidade de triângulos que o Zeebo é capaz de transformar para coordenadas de rasterização por segundo e o '3D pixel fill rate' é a quantidade de polígonos que ele rasteriza por segundo, que a meu ver são coisas bem diferentes (o primeiro seria o vertex shader e o segundo o pixel shader).
O primeiro aplicaria a transformação desejada, aplicaria a projeção e converteria para coordenadas normalizadas e depois para coordenadas de rasterização. O segundo, como está descrito como quantidade de polígonos e não triangulos dá pra se deduzir que ele faça algum tipo de
ligação interna entre os triângulos e renderize mais do que um por vez, se eles não se sobrepuserem.

Quanto a anti aliasing, ele não tem, seria necessário criar algum filtro que detectasse as bordas dos objetos pelo mapa de pofundidade (zbuffer) e aplicasse uma suavização nessa área com um blur simples.

Quanto a resolução, ela é 640x480, mas isso não importa quando portarem jogos para o Zeebo se o game for 3D, pq a transformação de coordenadas normalizadas para coordenadas de tela é quem escala a cena para o tamanho da tela do sistema.

640x480 realmente é muito limitado, o serrilhado dos triângulos ficam visíveis e uma das formas de suavizar isso é aplicar um filtro ou tentar deixar o ambiente do game o mais homogêneo possível, aka Quake.

Teste de programação no Zeebo - Doom3 xD

KaLanGO escreveu:Mais fácil tacar um cenário (leia-se cubo oco) de um obj loader....
põe uma textura....e melhor impossível...

=D sim é verdade
Estou tentando fazer um script em python pra exportar um cenario para um formato bom pro zeebo, e com isso diminuir consideravelmente
o tempo necessário pra criar os cenarios para um game q estou fazendo. Modelos animados talvez eu exporte para o formato md5 mesmo por
enquanto para não perder muito tempo com scripts de exportação xD

SDK Software Developer Kit Zeebo Tectoy + Manual

Sim, com pequenas modificações para lidar com a camada mais baixo nível dependente do sistema (no caso do Zeebo, teria que portar tudo relacionado a tratamento de eventos e coisas do sistema para BREW )

Teste de programação no Zeebo - Doom3 xD

Vc fez esse modelo 3d no "3D Studios Mark"???

Nao, esse modelo eu peguei no game Doom3, da ID Software.

Quantos triângulos tem esse modelo?

2626 triangulos o corpo, fora algumas dezenas para mandíbula e língua

Daria pra carregar o cenário também? Tenta fazer um vídeo e colocar no Youtube...

Nao sei como funciona o formato dos mapas da ID Tech atual =\

Teste de programação no Zeebo - Doom3 xD

Eu escrevi o loader de md5mesh + md5anim, vou animar o modelo no simulador e fazer o dot3, dai eu posto novamente o projeto atualizado
Aparentemente nuns testes que eu escrevi com opengl es ele parece obedecer as limitações do hardware do zeebo sim, os testes que fiz foram básicos mas deu pra ter uma noção (à principio ele é consistente quanto a requisição de tamanho maximo de textura, tamanho da tela, numero de texturas simultaneas, etc)

Teste de programação no Zeebo - Doom3 xD

Iae pessoal,
To brincando aqui um pouco com OpenGL ES para o Zeebo, vejam o que já saiu:



Modelo do Doom3 no Simulador do Zeebo xD

Como eu faço pra anexar aqui a dll pra executar no Simulador para vocês verem ele girando em tempo real?

Mario

Instalação e Configuração do Ambiente de Desenvolvimento de jogos para Zeebo - COMPLETO

Olá
Cara agora o caminho para o aplicativo está correto, não foi mais informado o erro 1, mas infelizmente parece que sua placa de vídeo não suporta os requisitos mínimos do OpenGL para usar aceleração 3D no simulador da Qualcomm =\
Provavelmente os exemplos 2D rodarão perfeitamente, mas os que são relacionados a OpenGL ES não =(

Instalação e Configuração do Ambiente de Desenvolvimento de jogos para Zeebo - COMPLETO

Esse "Error 1" é um problema quando o seus arquivos estão numa hierarquia inválida, por exemplo, se vc tiver um arquivo \game.mif e nao tiver o \game\game.dll ou se tiver algum erro no mif ele vai dar esse erro.
Se nao me engano até mesmo diferença entre letra maiúscula e minúscula causa esse erro, então sugiro você tentar renomear tudo para letras minúsculas e tentar rodar novamente o programa, fechando e abrindo o Simulador novamente para a mudança fazer efeito =)

Instalação e Configuração do Ambiente de Desenvolvimento de jogos para Zeebo - COMPLETO

Para compilar os exemplos do SDK é só seguir os mesmos passos do explicado aqui para criação de projetos se vc estiver usando o visual c++ 2008.
Para rodá-los no Simulador do Zeebo basta indicar o diretório dos arquivos .mif deles. Os exemplos do BREW estão em %BREWDIR%\examples.
No pacote com o SDK do Zeebo tem um zip chamado Samples.zip
eles são os exemplos de como iniciar e habilitar a aceleração 3D de hardware usando OpenGL ES.

Cowboy: Projeto nacional de "laptop de baixo custo" pode ser usado para desenvolver para o Zeebo?

Para desenvolver pra Zeebo é necessário Visual Studio ou algum outro simular, coisa que nao tem para Windows CE =/
Talvez exista alguma versão do GCC para WinCE versão ARM, mas não sei a respeito não.
Pelo que vi até agora, a depuração dos games para zeebo rodando direto do target se dá pelo GDB, que é do pacote GCC, o que poderia fazer com que esse notebook rodando Linux teoricamente seria capaz de depurar games pro Zeebo, mas isso claro se a Qualcomm tiver um driver de linux para comunicação USB.

Aee chegou meu Zeebo... 15 min depois travou e reiniciou iauehiuahuiae

Aqui eu estou usando o WinVista premium 64, q não aceita driver sys =/
vou ver se consigo 'conversar' com ele, mas é bem provável que seja necessário um outro SDK da Qualcomm que é específico para interagir com os produtos deles, mas é fechado e precisa pagar 400 dolares para baixar e usar...

Instalação e Configuração do Ambiente de Desenvolvimento de jogos para Zeebo - COMPLETO

Muito interessante, será que esse plugin funciona com o sketchup 3D?

Não, apenas Maya, mas acho q isso não é problema, se um programador
for desenvolver um game e vc quiser usar o sketchup 3D, você pode exportar o modelo num formato simples, por exemplo, .obj, e daí o programador escreve um
codigo para carregar o modelo e converter para um formato bom para rodar
no zeebo. O mais interessante é o editor de partículas deles xD tem muitas opções

Você tem alguma pagina pessoal ou algo assim (leia-se portfolio)?

Ainda não, mas estou esperando sair o orçamento para me desenvolverem
um site para venda de produtos e jogos, e lá eu vou colocar um 'editor de jogos' gratuito para o pessoal brincar e comprar uma licença quando quiser distribuir o game criado em stand alone, se bobiar eu vou disponibilizar uma
área para os criadores venderem os jogos pelo meu site até.
Quando estiver pronto para beta teste eu aviso =D

Aee chegou meu Zeebo... 15 min depois travou e reiniciou iauehiuahuiae

Quanto tempo demora para atualizar?

Eu acho q ele faz o down do novo firmware sem voce perceber e quando ele termina ele reinicia e instala, talvez isso seja o motivo de ele 'travar' no meio dos games, mas nao descarto a possibilidade dos games serem toscos msm tbm XD
mas ai nao da pra saber quanto tempo ele realmente demora pra baixar...

Aee chegou meu Zeebo... 15 min depois travou e reiniciou iauehiuahuiae

Não, a única coisa q tem é o modelo (que aparece aqui como Zeebo apenas), código IMEI e um outro código CQ
O mais interessante é que ele tem 2 entradas USBs na frente do console, mas também tem mais duas na parte de trás, sendo uma delas uma Type 2, menorzinha, e no manual está identificada como Nao use, apenas assistencia tecnica xD.
Eu tenho quase certeza q é por essa entrada que você conecta ele ao pc e
transfere os games durante desenvolvimento e testes.
Aliás agora olhando a caixa elas não estão nem descritas nas características do video game!

Instalação e Configuração do Ambiente de Desenvolvimento de jogos para Zeebo - COMPLETO

Ufa finalmente concluído! xD
Valeu pelos elogios, tomara que com esse tuto as pessoas consigam começar a desenvolver seus projetos.
Para os modeladores e curiosos eu deixei passar despercebido neste tutorial um outro arquivo que vem no Zeebo SDK, que é um kit chamado QX que conta com plugins para exportar modelos do Maya e 3D Studio para um formato otimizado para o Zeebo, editor de partículas e texturas e outras coisinhas mais =D

Aee chegou meu Zeebo... 15 min depois travou e reiniciou iauehiuahuiae

Hmmm bom saber xD

Aee chegou meu Zeebo... 15 min depois travou e reiniciou iauehiuahuiae

Estou percebendo que tem muita gente que tem interesse em comprar mas só procura em lojas.
Eu acho que vai ser complicado as lojas quererem vender o Zeebo a não ser pelo site, pois se o Zeebo tivesse venda casada, tpo você compra o Zeebo e na loja já vê os games e novidades e acaba levando sempre mais uma coisinha, ele já estaria disponível faz tempo por aí.

Aee chegou meu Zeebo... 15 min depois travou e reiniciou iauehiuahuiae

Hmm blz, sou de SP sim vou ligar lá para ver o que eles podem fazer xD
Mas sobre o beta-tester não remunerado é verdade, praticamente é
isso mesmo que eu acho que foi feito, porque o vg já tinha atrasado para ser lançado certo? Não podia atrasar mais xP

Mario