2025-01-29 – O tamanho do executável do meu Game Engine em C++…
Vamos ver o tamanho do executável no meu Game Engine, e como posso ter um jogo a funcionar já com o Game Engine num binário centenas de vezes inferior ao de outros engines.
Pois como sabemos, podemos em certos Game Engines como o Unreal ou Unity criar executáveis com centenas de MB, mesmo que o jogo tivesse apenas um botão, e mesmo noutras frameworks como .Net (que não é a indicada para criar game engines), seriam dezenas de MB de memória ocupadas só para um programa vazio…
E o meu Game Engine, com toda a sua complexidade, ocupa 1 MB de tamanho apenas, e os 200 MB que viram ocupados de memória foram com toda a complexidade, pois com um botão apenas, carregaria talvez só uns 10 MB de memória com o peso do engine, coisa que reduzirei no Futuro ainda mais.
Podem ver pelas imagens abaixo que usando certos Game Engines, até um simples e “miserável” Jogo do Galo pode ocupar uns 150 MB de tamanho num executável! Fora as centenas de MB de memória!
Com o meu Game Engine, seria menos de 1 MB de executável e poucos MB de memória.
E podemos ver na imagem acima o que acontece hoje em dia, em que até os joguinhos mais simples chegam a ter centenas de MB de tamanho, o que considero algo absurdo. São exemplos que tirei há dias ao sacar uns joguinhos simples para me entreter no telemóvel enquanto estava numa fila de espera.
Para eu criar videojogos Retro-Gaming, eu não preciso de 1001 coisas avançadas de 3D, e seria completamente estúpido eu estar a criar jogos que agora posso criar com executáveis de 1 ou 2 ou 3 MB, centenas de MB por jogo:
Uma das coisas que acho feíssimo é ver um jogo criado bastante simples, e com centenas de MB de tamanho.
Acima podem ver que, com alguma compressão à mistura, consigo ter o Game Engine sem os recursos e sem bibliotecas estáticas (pedindo-as dinamicamente, exigindo que o sistema operativo as tenha) e sem recursos (obrigando a que as imagens do jogo e sons sejam fornecidos em conjunto com o jogo mas ficheiros àparte), com 0,47 MB, ter o executável com bibliotecas estáticas com 1,5 MB de tamanho (mas com os recursos do jogo em separado), e o jogo com as bibliotecas estáticas incluídas no executável (para funcionar em qualquer sistema mesmo que não as tenha) e com os recursos (como imagens e músicas, etc) incluídas no mesmo executável, a rondar os 10 MB de tamanho, e com jogos bem mais complexos:
Com o meu engine, não só posso criar jogos super rápidos, a ocupar pouca memória, com executáveis reduzidos, como eles até podem correr em máquinas com 20 anos de idade, e até facilmente migrados um dia para máquinas dos anos 90. 🙂
Percebem agora porque é bom ter o meu próprio Game Engine?
Há dias, vi uma pergunta no Quora estilo “Porque é que os programadores auto-didactas são tão maus?”, ao que não resisti responder:
https://www.quora.com/Why-are-self-taught-programmers-bad-at-programming/answer/Goncalo-Ferreira-7
E alguém comentou que se eu quero fazer coisas do zero, píxel a píxel, sem usar bibliotecas que foram criadas por programadores de respeito, então estou a dar tiros nos pés, afirmando que se eu evito andar nos ombros de gigantes estou a tomar má decisão em termos de programação.
Mas reparem, abaixo vou explicar como é bom eu criar o meu próprio Game Engine e as minhas próprias toolkits em vez de usar as Qt e GTK e outras.
Resumindo: É tudo feito ao meu gosto, tenho mais performance, executáveis menores, ocupo menos memória, só tenho o que preciso.
Simples!
Vamos ver…
O meu Game Engine já com o nível de testes pré-configurado, corre-me em menos de 1 MB de executável, e se incluir todas as bibliotecas embebidas no executável (no binário), como as do GCC etc, ocuparia 3 MB apenas.
Vejamos se fosse com um .Net por exemplo…
Um game engine semelhante ao meu, mas criado em .Net (menos poderoso), sem recursos incluídos, gastaria certamente só no código “compilado” em .Net, por volta de uns 10 MB no executável principal.
Ele teria de correr também com o runtime estivesse instalado no sistema, o que varia entre 50 MB e 100 MB, ou seja, já vamos para 60 a 110 MB para um engine semelhante, sem recursos incluídos, se for um .Net recente (tipo .Net 6 e .Net 7). Se fosse um .Net framework (clássico), pré-instalado em vários Windows, ocuparia uns 200 MB no total (ou seja iríamos com 210 MB no total).
Se usássemos self-contained builds (tudo embebido no executável sem precisarmos de runtimes em separado), o binário poderia chegar aos 80 MB ou 100 MB.
Comparamos assim 1 MB do meu com uns 1 MB a 15 MB do .Net (se for tão pouco), e com o meu tendo tudo estático (self-contained), compararíamos 3 MB do meu com 50 MB a 80 MB do .Net…
E mesmo que seja um executável dinâmico, o peso da CLR em tempo de execução pode ser pesado e o runtime sozinho ocupar 20 MB a 30 MB de memória, para algo muito simples.
E como referi, .Net não é tão indicado para a criação de um Game Engine quanto o é C++. 🙂
Estou a criar aos poucos um Game Engine eficiente e compacto, numa linguagem eficiente e compacta, com performance extrema.
Agora vejamos comparando com outros Game Engines do mercado, porque razão crio o meu próprio?
Sobre outros Game Engines:
- Unreal: Se eu criasse um projecto vazio no Unreal, literalmente só com uma cena com um botão, poderia gerar um executável de 100 MB ou 200 MB ou mais, porque o binário incluiria o runtime completo do Game Engine (mesmo que não usemos aquilo tudo), vários sistemas embebidos como renderização avançada, física, networking, lógica de som, etc, etc, etc, fora dependências externas que não são excluídas…
- Unity: Se eu criasse algo com apenas um botão, seriam 50 MB de runtime adicionados ao executável, e atinge facilmente centenas de MB de tamanho ao criar jogos com mais complexidade.
A meu ver, é não só impressionante mas feio como há tanto jogo tão simples a ocupar centenas de MB de tamanho.
E eu só não ocupo menos, por que um executável meu de 10 MB já tem MP3 embebidos, centenas de imagens, ficheiros de som, etc!
Fora as bibliotecas embebidas estaticamente para correr em todo o lado!
Eu detestaria ter um executável de um lado, com 1001 ficheiros a acompanhar, eu meto tudo embebido no executável, e quero-o pequeno, e a ocupar menos memória e rápido.
E já viram o que é sacar um executável de 150 MB com um game engine inteiro quando um jogo nem usa sequer 2% do que ele proporciona???
A meu ver ridículo.
Percebem agora porque é bom eu ter o meu próprio Game Engine?
Não é questão de vaidade como alguns possam pensar, não é o querer fugir de andar nos “ombros de gigantes”.
A meu ver, é mesmo bom senso.
Claro que sabe bem poder dizer que tenho o meu próprio game engine e tal.
Mas não é vaidade, eu não seria capaz de andar a criar videojogos retro, a ocupar centenas de MB de tamanho nos executáveis, ou GB de memória, quando na época eles corriam com poucos MB ou menos.
Quero jogos que caibam em disquetes. 🙂
Um Game Engine, com centenas de ficheiros, vários deles com milhares de linhas de código, onde um jogo com 200×95 tiles, a 1280×960 de resolução, com mais de 100 inimigos diversos no ecrã, com água e fogo e chuva e neve e outras coisas geradas em tempo real de forma procedimental, com tudo e mais alguma coisa, a caber (sem recursos) numa disquete, e com recursos incluídos no executável, poucos MB de tamanho.
Eficiência é importante para mim.
E era só o que faltava usar Game Engines criados por outros, com executáveis bloated cheio de coisas que não preciso, a ocupar centenas de MB de memória ou GB de memória, etc, quando posso ter tudo pequenino e eficiente com alta performance ao meu gosto.
Não é vaidade, é bom-senso. 🙂
E também é uma boa maneira de aproveitar para manter o meu cérebro activo, e divertir-me a criar tudo isto, tanto o Game Engine como os jogos que vou criar com ele, ao invés de andar apenas a aprender a usar coisas feitas por outros.
Este post é complemento do anterior, relacionado com a minha optimização de memória, em que passei de 2 GB de uso de memória para 100 MB a 200 MB, o primeiro passo ao trocar containers e outras coisas de STL do C++ por outras mais eficientes customizadas, entre outros pequenos truques:
Conclusão:
Criar um Game Engine próprio não é questão de vaidade, mas sim de eficiência e bom-senso. No meu caso, consigo ter total controlo sobre desempenho, tamanho e compatibilidade com hardware antigo. E isso, para mim, vale muito mais do que usar uma ferramenta cheia de funcionalidades que nunca irei precisar.
Hasta!
2025-01-29.
Partilhado no LinkedIn no mesmo dia em:
Post Anterior (sobre optimização de memória no meu Game Engine em C++):
Post seguinte:
(A colocar um dia).
