Memory leaks BE GONE!

As you might or might not know, Java (and yes, Nifty is written in Java) uses a garbage collector to clean up allocated memory which is no longer in use. This is a very nice and comfortable feature for most programs but can become a problem in realtime applications (like… let’s say… for example… a game). The garbage collection triggers whenever it feels like there is enough garbage to clean up and can’t be controlled directly leading to huge amounts of unused memory being freed at once causing the game to lag or stutter at that moment. To resolve this issue, all datastructures which are only used temporarly get recycled and reused whenever possible to prevent too much new allocations and cleanups. In the graphic below you can see the current memory usage of Nifty. After a manual garbage collection after loading the level, the used memory settles around 40MB of data with an automatic garbage collection every one to two minutes (which is much less than the previous once a second).



A nifty diary

If an image is worth a thousand words, a video must be worth quite a lot of text. This is why we decided to start a developer diary on YouTube. In these videos, we will demonstrate new features we’re currently working on, game content, experiments and more. In the first video which is linked below, we show a preview of what the game will look like. We are not yet feature complete on the engine side of things so expect some visual changes in the future, the overall art-style of the game will (most certainly) stay the same.

A nifty development

After hours of refactoring and method-matching, the android port of Nifty has no more errors (meaning no compile-time errors; it’s far away from being playable)!

There’s still a lot to do:

  • Rewriting of all shader stuff
  • Rewriting of all shaders
  • Thinking of a good way to transport draw-specific arguments through the engine
  • much more!