Olhando de novo a Gamekit

Resolvi baixar o release atual da GameKit e como sempre me surpreendo com a forma que os desenvolvedores da engine refletem meus desejos.
Alias este encontro de ideias foi oque me cativou de inicio.
Recursos
Uma das "features" implementadas é a libRoquet que tem o diferencial de usar uma base em HTML para montar a GUI do game.


Ela tem os métodos clássicos da javascript como innerRML (innerHTML) para alterar o conteúdo de uma DIV por exemplo. E pode usar Python como linguagem de script, mas duvido que eu precise disso.

Também possui TAGs próprias especiais para criar janelas e outros elementos de GUI.

As desvantagens esta no fato dela ter sido implementada no C++ mas ainda não na API de script da GameKit. Eu posso implementar os comando que preciso para essa lib mas assim fico fora do contexto dos desenvolvedores da GameKit.
E tem o CSS que fica um pouco mais carregado pois usa-se muito a propriedade background para fazer o mapeamento de texturas para as imagens dos elementos da interface (botões, barras, etc).

Imagens

Todas as imagens tem que ser de tamanho base 2 (128x128, 256x256...) pois apesar dos micros desktop não terem mais essa limitação desenvolver para Android e iPhone ainda requer este cuidado.






Facilidade meeesmo

A vantagem crucial na GameKit é a integração com o Blender, após abrir o .blend ele ainda converte a cena para a OGRE em "tempo de execução".

Escrever os atributos para um material no Editor de Texto pode assustar os preguiçosos, mas é onde dá pra fazer muito mais na engine doque simplesmente usar os materiais nativos do Blender.

Outro cuidado especial é com a Luz, nativamente a GameKit ativa o uso de lâmpadas e projeção de sombras o que reduz a performance consideravelmente pois todo objeto emite sombra. Ai é melhor desligar e fazer ajustes manuais.

Versões da GameKit
Ao baixar o demo, o editor e o código fonte vi que havia uma disparidade entre as versões.
Oque significa que se você for usar uma função mais nova, como controlar os "overlays" de imagens por exemplo, dará erro no editor.

A solução foi compilar o ultimo release de código.
Me atrapalhei todo com o CMAKE, simplesmente me perco na sintaxe de configuração dele. Acabei modificando diretamente o fonte de um dos samples para se adequar a meus propósitos.

E no presente momento ainda não consegui compilar no Windows.
A versão para Android também esta na reta e será o próximo desafio, tanto que a tela de testes se baseia na proporção da tela do Galaxy com 1024 x 600 pixels.

Por hora
Estou implementando coisas básicas como a SQLite, CURL e TinyXML pois estes são simples de inserir no sistema.
Bom, na verdade o CMake esta se mostrando muito sinistro. Só para linkar a CURL eu apanhei dele um dia inteiro.

Mas arrumado ele garante que logo soltarei um executável de testes ao menos rodando algumas animações.

Informação Bonus

Corrigindo o erro warning: the use of `tmpnam' is dangerous, better use `mkstemp':

Na linha 657 do arquivo luaconfi.h subistitua:
#define lua_tmpnam(b,e)         { e = (tmpnam(b) == NULL); }
por
#define lua_tmpnam(b,e) { e = (mkstemp(b) == NULL); }

Na linha 117 do arquivo OgreDeflate.cpp subistitua o trecho:
// Write to temp file
char tmpname[L_tmpnam];
tmpnam(tmpname);
mTempFileName = tmpname;
std::fstream *f = OGRE_NEW_T(std::fstream, MEMCATEGORY_GENERAL)();
f->open(tmpname, std::ios::binary | std::ios::out);
mTmpWriteStream = DataStreamPtr(OGRE_NEW FileStreamDataStream(f));

por
// Write to temp file
char tmpname[L_tmpnam];
mkstemp(tmpname);
mTempFileName = tmpname;
std::fstream *f = OGRE_NEW_T(std::fstream, MEMCATEGORY_GENERAL)();
f->open(tmpname, std::ios::binary | std::ios::out);
mTmpWriteStream = DataStreamPtr(OGRE_NEW FileStreamDataStream(f));

Esse errinho chato acontece por usarem uma função considerada não "standard".