Godot Engine: Desenvolvimento de jogos no Linux

[Luis Cardoso]

Novas povo!
Bom, até agora o senhor reduz n reportou sobre meu problema de shaders. já montei uns mapeamentos da personagem e estou esperando por isso.
Porque sem eu poder programar direto na GPU eu não consigo o resultado gráfico que quero.

No entanto foi abordado pelo usuário chacra um tema no GitHub sobre Tweenens, depois de conversas irem e virem o reduz animou com os links q mandamos e começou a implementar na engine o sistema. https://github.com/okamstudio/godot/issues/603

A saber, tweening é a forma como a animação roda de forma variante dando a sensação de ser mais próxima a fisica do mundo real. Uma boda tem aceleração, estabilidade e deselaceração da velocidade ao longo da trajetória e isso é oque o tweening garante.
Vcs (talvez uns 1% q estao lendo) devem ter visto no codigo q mandei pro GitHub do primeiro jogo usa a forma + simples de tweening ( x = x + (xDest - x)* desaceleracao * delta ), ja o tweening proposto ali é mais elaborado.

Pelo que eu entendi isso é algo semelhante ao movimento de partículas/corpos, correcto? Se sim, eu já fiz algo semelhante mas mais próximo das fórmulas da física, tornando-o mais próximo da realidade. Fiz isso quando criei um emulador de GPU para as minhas calculadoras gráficas (TI-83 e TI-89t). Tenho de ir ver aos meus apontamentos... Porque aquilo até estava jeitoso

[Bitetti]

é, por ai msm, com animação n precisa de física verdadeira, mas só uma ilusão d q a coisa ta "orgânica". Se já tentou desenhar uma surface com certeza já viu alguns dos cálculos usados na biblioteca Tweening.

[Bitetti]

Andei tendo uma boa conversa com o Juan Alpaca (da Okan Studio) ele me deu uns toques nessa parte. Confesso q nunca havia parado p pensar em alguns detalhes da linguagem.
https://www.facebook.com/photo.php?fbid ... 517&type=1

Infelizmente o sistema de desenho é bem parrudo, mas ainda falta suporte a detalhezinhos ocmo eu acabei de fazer nesse post la no Face. Nada afinal tão comprometedor, quando eu fiz isso com a LibRocket o processo exigiu q eu criasse uma classe própria de TAG na HTML.

Quanto aos shaders, ainda estou sem resposta do Reduz, parece ser coisa realmente boba. As vezes me da vontade de me aventurar no código C++ da Engine p resolver isso, mas a maioria das vezes n... afinal passei semana passada matando zumbi em Dead Island (malditas promo do Steam)

Mas foi bom pq comecei a estudar novamente a parte de Shaders, o Defered Shader é uma técnioa mais atual e por fim mais inteligente de calculo.
Oque me obriga a rever meu shader de toon. Pucha vida, ele já estava bem parrudo.
Aqui os meus estudos atuais em função do render em função do defered shader:
http://codepen.io/bitetti/details/gimxp/

[Bitetti]

Simplesmente tava de cabeça quente, stressado com o serviço, de manhã descobri q tinha uma conta vencida de R$200 p pagar... ai chutei o balde e comecei a fuçar no código da engine (relaxar a mente como no paradoxo da coçeira).

https://github.com/okamstudio/godot/iss ... t-51266099

Como reportei nessa issue o código aqui foi esquecido

Código: Selecionar todos

String VisualServerRaster::shader_get_light_code(RID p_shader) const{
    return rasterizer->shader_get_fragment_code(p_shader);
}

Sim, onde era para pegar um valor a função pegava outro.
Esse tipo de coisa acontece quando agente ta na faze de testes, lógicamente o kra commitou e esqueceu de rever esse detalhe, ou simplesmente houve um merge errado no código.

Esse tipo de passa e repassa de chamadas a mesma função são normais no paradigma de O.O. convêncinal gerando esses incidentes... just do ruby people.

Bom, mas agora hora de partir pra porrada com os shaders. Uhullll

[Bitetti]

O vetor normal foi fácil. O efeito final do shader é + complexo um pouco. Uns cálculos de luz e um IF (sim, arcaico mas funcional).

[Bitetti]

Como nem tudo são flores dessa vez 2 empecilhos que não são culpa do ciclo de desenvolvimento da GODOT.
Primeiramente foi o senhor Blender que na versão 2.71....algumacoisa... dá um "pau medonho" ele trava e fecha ao duplicar um bone! Fiquei pasmo como isso passou pela equipe de desenvolvimento já q é uma tarefa comum dentro do programa. Mas já foi corrigido. Infelizmente não para mim, pois o repositório que ando seguindo parce não ter essa mudança ainda ~_~
Tive que abrir o modelo numa versão antiga do Blender e exportar o esqueleto para o software corrente.
Em geral isso não afeta users do Ubuntu pois o repositório oficial sempre espera para atualizar.

Segundo é a folga da Trufa que me deita entre os controles e empurra tudo pro lado me obrigando a trabalhar embodocado.

Sobre a engine estou fazendo ajustes na física do tipo "fuck mister Newton" e melhorei o algorítimo do shader.

[Bitetti]

Agora sim, o bug veio da parte da GODOT, mas tive bons retornos quanto a isso.


Além deste há tb um desagradável bug ao usar texturas em algumas condições dentro do Android, estou tentando reportar isso lá no GitHub (meu inglês é bastante limitado... não q ache q eles devam ser muito especialistas nessa língua t heehhe)

Por fim, alguns dos ultimos estudos

[Bitetti]

Começando a animar. A GODOT n lê o blend nativo... falha boba, pois a OgreKit já tem suporte a isso... bastaria adaptar as classes né.
Como mencionei lá no começo dessa thread ela usa o formato COLLADA para exportar os dados (em XML), o COLLADA nunca foi um dos meus preferidos e pelo visto não é hoje que ele vai sair desse status.

O exporter do Blender é precário, então o pessoal da GODOT criou este.
https://developer.blender.org/T41071

que ainda tem q ter alguma "mãnha" que eu não domino... ainda.

[Bitetti]

Eu tinha parado com os tutoriais, msm pq a parte 3D é assim msm, 5 vezes a complexidade da 2d.
bom, lá vai

[edit]
Quando se fala em "por o resultado na tela" o pessoal se excita.
O vídeo foi muito bem aceito la no forum da GODOT no Face, bem até demais ehehe.

[Bitetti]

Gentem, só ta faltando o Juan corrigir o segundo mapeamento UV q a coisa fica louca!