Projeto: USP's Game Development Kit (UGDK)

Imprevisto: estou longe da usp no momento e só consigo chegar aí depois da reunião, pq eu vou ficar preso aqui até tarde.

Eu venho quarta e, bensadeus, meu laptop chega até semana que vem. Daí eu começo a ser mais útil

Valeu e desculpa, não achei q eu ia me demorar aqui

Beleza, então hoje a reunião fica cancelada mesmo.

Dado que não teremos mais a parte 3D (OGRE), vamos ter só os módulos ugdk-core e ugdk-2d no repositório da UGDK, certo? Será que não rola separar aquilo que for específico de 2D em uma extensão à parte (como planejamos fazer para 3D e scripts)?

Bem, já tem a pyramidworks. Ela atualmente possui coisas de tratamento de colisão 2d.

Então a gente joga lá as coisas que forem específicas de 2D?

Acho que a parte mais complicada é que a classe Window tá no módulo ugdk-2d.

Tem uma implementação da Window na ugdk-2d, deveria ter uma classe base no core. Eu lembro que a ugdk-3d tinha uma Window própria.

O problema é que todas as coisas de opengl acabam dependendo da ugdk-2d eu acho, e disso tira que as coisas de UI tb.

Ah, entendi agora.

A situação atual é a seguinte. A UGDK tem:

  • ugdk-core (que inclui a pyramidworkds)
  • ugdk-2d
  • ugdk-3d
  • ugdk-script

Os módulos ugdk-3d e ugdk-script vão sair. Aí, para ser consistente, vejo duas opções.

  1. Mover a pyramid works pra fora da ugdk-core e ficar com:
  • ugdk-core
  • ugdk-2d
  • ugdk-pyramidworks
    E nesse caso, acho que seria razoável considerar mover a ugdk-2d e a ugdk-pyramidworks para outros repos
  1. Mover a ugdk-2d para dentro da ugdk-core e ficar tudo junto.

Faz sentido?

Não vejo problema em juntar a ugdk-2d e a ugdk-core.
No caso de separar em core/2d/pyramidworks, seria legal não separar em reps diferentes. Isso traz umas dores de cabeça meio desnecessárias no momento.

O @Omarillion disse que prefere manter separado, para manter um mínimo de compatibilidade com a ugdk-3d, que algum dia ele pretende continuar (separado mesmo). Mas ele também acha melhor deixar no mesmo repo de um jeito ou de outro.

A questão pra mim então é se a UGDK “canônica” vai ser uma engine “completa” por si só. Se sim, ela precisa ter a ugdk-2d inclusa. Se não, ela vai ser só uma base em cima da qual engines mais específicas podem ser implementadas. Por mim ambas opções parecem OK, e concordo que fazer em um repo só é bem menos treta.

Queria deixar marcado o ponto a partir do qual estamos fazendo nosso trabalho atual. Pensei em fazer um tag “legacy”. Ou é melhor deixar um branch?

@Henrique
@Omarillion

Enquanto compilava o Maverick, tive o seguinte erro:

Error LNK2019 unresolved external symbol _uncompress referenced in function “public: __thiscall tiled::Layer::Layer(class JSONNode const &)” (??0Layer@tiled@@QAE@ABVJSONNode@@@Z) maverick ~\maverick\build\src\tiled-reader.lib(layer.obj) 1

O tiled-reader.lib ta na pasta, tho.

~desculpa ressuscitar a thread~

Então, rapaziada,
Estava tentando fazer a ugdk aguentar fazer janelas dinamicamente, deu certo abrir e fechar manualmente (via código).

O negócio é que, se o usuário clicar no x de uma janela não-principal o mundo acaba.
Eu tava tentando fazer a ugdk levantar um evento do tipo SDL_QUIT mas não tô entendendo o sistema de eventos :l

O segfault que dá é pq o system::Run() chama um graphic::UseCanvas() num canvas que é inválido, pq ele pressupõe uma RenderScreen, que tem um smart pointer pra Window, que tem raw pointer pra uma sdl_window, que, em tese, morreu.

O problema, além de fazer soar o evento de “user requested termination” é:
na struct do SDL_QUIT não tem nem SDL_window_id, só tipo timestamp etc. Então se o usuário clicar no ‘x’, a única alternativa é matar a cena.

Ideias? Sugestões? Tô ficando bem perdido.

Na engine.cc é definido um SDLEventHandler que lida com o SDL_QUIT, mas apenas quando só tem apenas Uma (a principal) janela.

Dá segfault antes de chegar ao handler se tiver mais que uma.

SOOO folks…

Continuamos ou Hiatus? Por mim continuamos, o que vocês acham?

mas vamos ver se a gente atrai outros membros também :v