OOM-Engine – Genesis

A game within 1.44 MB ? A great challenge.

This is the first time I have to write code while thinking so much about the memory (storage space, not the main memory). Nowadays computers are powerful, fast and they have a lot of storage space, often more than 1 TB.  We don’t have to constantly check the final size of the game, we intimately know there is enough space… but not in the context of this game jam. The game, uncompressed, must fit in 1.44 MB which was the size of a floppy disk (an HD one). I immediately found the challenge interesting.

The game concept is still unknown but that’s not really a problem, the game jam lasts 20 days, it lets me enough time to write a small engine that will be used to create the game while thinking about a great concept. I decided to create an handy tool inspired from recent game engine but with the least possible dependencies (in number and in size). Most game engines won’t create small binaries like all recent tools. I think you could reach 1.44MB with very old tools (before 2010 maybe ?). I could have used Java or HTML or whatever that have a lot of dependencies to heavy libraries or runtimes but I wanted to make things simple. A single .exe – click – run. Nothing else required. No extra libraries, no emulators. Technically speaking, the game is still OS dependent. But that part is really small, only a few OS specific KB.

The game code is x86 assembly that would run on almost every 32 bits processors. The problem ? Graphics. Computing graphics on processors is not really efficient. We have to do it on GPUs. That’s why I added an extra dependency to OpenGL to be able to address the  GPU.
The first difficulty was to generate a single .exe that is less than 1.44 MB. C++ compilers will generate heavy binaries on Windows. The first thing to do is the ask the compiler to strip all symbols from the final binary. It will considerably reduce the size. Symbols are not useful except if you plan to debug the game or create a library. That’s not our case. The other tricks :

  • Using GCC, compiling in release with -O3 helped a lot (Obviously)
  • Don’t use the standard library ! Including <iostream> will add at least 1 MB in release, even after all symbols being stripped out.
  • Avoid generic programming. Template are great but… they’re generating a lot of code for each different instantiation.
  • Avoid static declaration. Pretty obvious but int array[250000] will destroy the stack allocation… and add 1MB to the executable.
  • Forget about 4K textures, we’re speaking instead of 5KB jpg textures .
  • Audio is heavy. MIDI files with a real-time synthesis are maybe the most elegant solution.
  • The OpenGL loader. OpenGL is huge. It’s one of its default. I will use OpenGL 3.3 by using GLEW it could be avoided by using an older version (1.1 for example) or by using Vulkan.

After having passed a lot of time on the project setup, I finally got the first render.
A free camera and a colorful cube for only 500KB. The game is not that far.

First rendering

There’s still a lot of work like adding physics or audio or making an engine handy user interface. Stay tuned !

Aredhele 😉
Original post here

Leave a Reply

Your email address will not be published. Required fields are marked *

Copyright © 2018 Vincent STEHLY--CALISTO. All Rights Reserved.

Up ↑