Resource group load/save functions

[Josh @ Dreamland]

The idea is simple in concept. GM/ENIGMA users often group objects which are related spatially or temporally in the resource tree. GM games are notorious for their huge RAM consumption, and ENIGMA games can only be so much better while operating in an arbitrary CPU/RAM use constraint. So, how do we propose a solution?

Simple. Allow selecting whether resource tree groups are preloaded or not, and give a method called [snip=EDL]resource_group_load("The name of the tree item")[/snip].

Basically, the resource group "Player" and "Enemies" — and don't lie, you've used groups by this name! — will be loaded up front, as will the resource group "Terrain" in simple games, or "Overworld 1" in more complicated games. When you need resources from the second overworld, you call [snip=EDL]resource_group_unload("Overworld 1"); resource_group_load("Overworld 2");[/snip].

Now, if you're afraid that will mean in-game load time, well, your fears are justified for extremely large games. But think of it this way—all that loading would be done at the same pace up front otherwise. You've just broken it into manageable segments at worst; no one is forcing you to call the unload() function.

To solidify the proposal, I am suggesting the following methods:

Code: (EDL) [Select]

/** Load groups of resources with the given name in the resource tree into memory.
    The group id can be from any resource folder; all matching groups will be loaded.
    To narrow the ID, the forward slash "/" can be used to denote nested groups.
   
    Hence, the string "Overworld 1" will load all resources found in any group called
    Overworld 1, while the string "Enemies/Overworld 1" will load only such a group
    contained in a group called Enemies.
   
    If a resource in the group is already loaded, no action is taken for it.
    The function returns only when all resources in the group are loaded.
    At that time, the function returns the number of matching groups loaded. */
void resource_group_load(string group_id);

/** Unload groups of resources with the given name in the resource tree from memory.
    The resource matching dynamic is identical to that of resource_group_load.
    Returns the number of groups unloaded. */
void resource_group_unload(string group_id);

/** Load groups of resources with the given name in the resource tree into memory.
    Very similar to resource_group_load, except it performs all loading operations in a
    new thread, returning immediately. */
void resource_group_load_thread(string group_id);

Perhaps later we will want to offer functions which narrow the search to individual resource tree items.

Along with tree storage, I would like to offer a function to fetch the ID of a resource by its name, and vice-versa, then allow loading or unloading an individual resource manually by ID. Those will follow later, and are not really the concern of this proposal.

What I need from Java: A way to mark groups as preloaded.

[IsmAvatar]

Is loading/unloading recursive?

[luiscubal]

I approve this concept. I've even thought about implementing this concept multiple times in my own game projects (although IIRC the idea never went ahead)

However, I'd change the API:

Code: (edl) [Select]

resource_group_id_t resource_group_load(string group_name);
void resource_group_unload(resource_group_id_t id);

resource_group_load_request_t resource_group_load_thread(string group_name);

//Wait for the loading to be finished.
resource_group_id_t request_group_thread_join(resource_group_load_request_t request_id);

//Tries to join, but does not hang if the loading is not done. Useful for loading screens.
bool request_group_thread_try_join(resource_group_load_request_t request_id, resource_group_id_t& group_id);

Feel free to change the type names (I just used these so the meaning would be easier to understand).

If a OO-style API is acceptable, then this could be further changed.

[IsmAvatar]

try_join looks like it's basically an is_alive check, so it might be more useful to just put it as that.
That said, all these advanced threading features should not be subset functions of a particular separate function API - they should have their own threading API.
That is to say, we shouldn't have _thread, _thread_join, and _thread_is_alive (or _thread_try_join) variants of particular functions, because then we'll quickly have function bloat over something that the user can just as easily wrap in a thread api, which will itself offer thread_join and thread_is_alive (or thread_try_join).
If we feel that threading resource group loading requests is going to be the de-facto standard, then simply have resource_group_load simply return a thread, and then maybe have a resource_group_load_and_wait variant. (to avoid confusion, maybe not even provide a r_g_l, and instead only provide r_g_l_thread and r_g_l_and_wait)

[Josh @ Dreamland]

I should have clarified; I intended the non-threaded load to wait for any threads which may be loading the resources.
So during a cutscene, you would call the thread version, but after the cutscene, you would call the non-threaded version and it would make sure the load finished before returning.