Memory

Punity internally uses two default memory banks:

• CORE->stack is a memory used in functions that need large amounts of work memory. The functions usually free the memory before they return. There are cases when they use this memory to pass larger amounts of data to their caller. This is generally not done in the public API, but it's quite handy trick for some situations. This memory is also emptied when frame ends.
• CORE->storage is a memory where Punity stores long-term stuff like buffers, bitmaps, fonts, audio, etc. You are free to change pointer to CORE->storage to another bank at any time, but I almost never do so. This bank is perfect for storing stuff that is supposed to live for entire game runtime.

There is also a third memory bank that feels natural for shorter-term data. Typically data that is only needed for current scene/level. It would make sense to store there overly large bitmaps, or audio that only shows/plays in one level. But so far I didn't needed that. I usually have the space for current level (tilesets, bitmaps, etc.) stored in CORE->storage. This way I don't need to bother with it. It's pretty typical for me to do the following:

typedef struct
{
	i32 index;
	i32 flags;
}
Tile;

typedef struct
{
	// Takes 8MB of CORE->storage memory.
	Tile tilemap[1024*1024];

	/* ... */
}
Game;

Game *GAME = 0;

int
init()
{
	GAME = bank_push(CORE->storage, sizeof(Game));
	/* ... */
}

The banks are not endless pits of memory, but are limited by their capacity set at compile-time. The two default banks use capacity set by PUN_STACK_CAPACITY and PUN_STORAGE_CAPACITY macros. For other banks, you are required to pass capacity to bank_init. Before you get scared, this is very common approach even in AAA games: Everything has a maximum size it has to fit into. Consider following:

• There is a maximum level size, or a maximum size of memory used for level representation.
• There is a maximum to number of entities (enemies, players).
• There is a maximum size of assets per-level (or even per-game).

That said, Punity has a Deque. It can grow, eat your whole memory and never shrink. This change was done to minimize amount of configuration in Lunity (Lua bindings for Punity) and was kept in Punity simply to keep CLOC (and implementations) low. However, Lunity is a different kind of animal with different target audience.

It might well happen that, in future, Punity will use malloc in the DEBUG mode to allow for live asset reloading. The experimental implementation has already been done in Lunity and seem to be working really well.