Resource management

Pictured: Soda 3 loading crystal models and crystal textures, using a soda bottle with a grid texture as a placeholder for unloading objects.

Part way through watching Soda 3's early thread test load the exact same model from the exact same file 1000 consecutive times in preparation to draw it 1000 times, I think I had an epiphany that went something along the lines of "I'm positive there's a better way to do this". Hence the resource management I eventually implemented in Soda 6 onward, and just now re-implemented better than ever in this latest version, Soda 8. Resource managed items contain only a reference to the actual stored data, which is referred to be the key used to initialize the item. Usually, this is the filename because it makes the most sense, but through the miracle of c++ template parameters and one giant 30 crash migraine I have managed to make the resource and resource-instance class so watertight that you can use a resource instance as the key (Think a terrain model generated from an image, using a standard instance of the image to be resource managed. You know, if that was what you wanted to do for some reason). I of course did this in order to have the vertex shader, [tessellation shader, geometry shader, ] and fragment shader resource handled on their own, and the compiled shader-set (often referred to as a program but I find that woefully confusing) also resource managed based on a list (std::vector in this case) of any number of member shaders. These are order specific, which is arguably a design flaw, but one I may address later, it's one hell of a rabbit hole to delve into for in practice zero reward.

Pictured: a quick view of Soda's resource handler