Nessa quarta-feira (09/05) me dediquei inteiramente a buscar maneiras de melhorar o código da engine para poder seguir em frente. Os maiores problemas envolvidos a essa iniciativa envolviam o fato de que muitas implementações mais novas estavam pouco encapsuladas (por exemplo, a classe paGameLoop acabava deixando de fazer algumas funções mais complexas, deixando essa responsabilidade para o usuário).
Outros problemas referiam-se às classes paSDL e paOpenGL. O maior deles era que a classe openGL é filha de SDL. Pensando nas relações hierarquicas "É UM", essa assertiva se torna confusa.
Buscando resolver essas coisas, comecei inicialmente tentando modificar a classe paGameLoop para fazer algumas funções de ajustes da janela, como inicializá-la, desabilitar o modo de controle de GameLoop padrão, configurar o desenho, dentre outras. Ou seja, o usuário que não desejar implementar as configurações desejadas para a janela e para a engine manualmente, poderá fazer uso desses métodos de configuração.
Nessa altura do campeonato, alguns bugs e comportamentos estranhos estavam me incomodando (para uma maior visão sobre o problema abordado a seguir, leia o post anterior). O primeiro deles envolvia a lentidão da compilação após a inserção das novas configurações de projeto ja comentadas anteriormente. Em seguida vinham erros msiteriosos que apareciam nos includes e em algumas regiões do código, mas que, ao compilar, o executável era gerado com sucesso. O ultimo problema envolvia a necessidade de gerar um novo arquivo lib a cada modificação na engine, além de que muitas vezes parecia que os arquivos acessados pelos jogos não eram os mesmos que os arquivos da engine que estava modificando
Como havia feito muitas modificações no projeto, estava difícil saber de onde vinham todos esses erros. E depois de tentar resolvê-los de centenas de maneiras diferentes, acabei desistindo e voltando para a abordagem anterior de um projeto só com a engine e os jogos em conjunto. Enquanto programava no código desta maneira, descobri que o motivo da lentidão na compilação eram os propertie managers que não faziam parte do computador que eu estava usando. Agora sei que mesmo funcionando, não é a melhor escolha manter os propertie managers de ambos os computadores no projeto.
O outro caso dos erros misteriosos se resolveu quando eu passei a dizer o endereço exato dos arquivos do tipo header no include. Como dividi o projeto em uma pasta include e outra para a lib, mantendo os arquivos cpp junto ao arquivo de projeto do visual studio, os arquivos .h, mesmo estando juntos, eram sinalizados como arquivos não encontrados pelo visual studio. O intrigante é que a teoria de que estes arquivos estavam no local certo se fazia satisfeita quando a compilação rodava normalmente.
Por exemplo, o include abaixo no paSDLSprite.h era sublinhado pelo VS como um erro:
#include "paSDL.h"
Engraçado para arquivos localizados no mesmo lugar... Mas a solução para satisfazer as vontades do VS está em especificar o endereço do arquivo de acordo com o local onde se encontra o arquivo do projeto:
#include "include/paSDL.h"
Por enquanto é só. No próximo post especificarei as demais modificações que fiz na engine...
Nenhum comentário:
Postar um comentário