Background datablock loading??

#1 Bump... :) If there is no background loading methods available, are there techniques for loading of datablocks more sophisticated than breaking them down into separate files and running exec on them as needed?

Just want to make sure I am loading my assets in the most intelligent way possible.

#2 In my current game, I do load image datablocks on a per level basis. There are about 50-ish unique images to each level and there is no hiccup when loading them.

But, I do load my audio in the "background".

First, I create a SimSet of ScriptObjects.

I then have a set of functions (like "addAmbient", "addSFX", "addMusic"), which take a file name, a datablock name, and then add them to the SimSet.

I then, in the global namespace, call the "add..." functions with all of my audio. Now I have a list of ScriptObjects filled with data that I can parse later.

Finally, at run time, and on a schedule, I process a few at a time. The ScriptObject has all of the information necessary to create the appropriate datablock.

This could be adapted to image datablocks, but it might be overkill, too. If I did it, I would add a "Level" field to the ScriptObject, and then I could write functions that loaded in the current level's files and then could clean up those same datablocks later.

#3 William thank you for your feedback. I will set up my loading sequence, if I see any hiccups I will use your "scheduled loading method".

Hey one question from your response. How do you clean up a datablock when no longer needed? If you %datablockName.delete(), will that delete the datablock and release the memory used back to the larger pool TGB sets aside for itself?

#4 For image datablocks, I think you have to have the allowUnload flag set. For audio datablocks, it does (since TGB 1.7.5) release memory back to the memory pool.

#5 So I broke up the loading of my assets into different datablock files and it works great. Only thing is now that the level builder doesn't see them anymore.

Is there any way to make the level builder load datablocks from multiple files automatically?

#6 Join us on MGT's IRC server, irc.maxgaming.net, channel #garagegames. There will be active people there at certain hours :)

#7 The level builder automatically uses the data in game/managed/datablocks.cs. Your game is also automatically using game/managed/datablocks.cs (as seen in common/gameScripts/projectManagement.cs). You can keep all of your graphics in the datablocks.cs so that the level editor can see them and just have your game ignore that file by commenting out the Managed Datablocks section (around line 64 in projectManagement.cs).

#8 Thanks William thats good to know, should have thought of that myself.

I guess what would be best would be to allow the level builder to be directed to multiple datablock files , so that I would not have to keep multiple copies of datablocks in two separate files, one for Level builder, and one for my loading scheme.

Of course I can work with this, just a little less efficient.

#9 Blake, with regard to post #8, what I did was add this bit to my levelmanagement.ed.cs file, inside the T2DProject::openLevel() function right at the top under the two ifs:

%newlen = strLen(%levelName);

	%newlen-=4;

	%newstr = getSubStr(%levelName, 0, %newlen);

	%newtwo = %newstr @ "_db.cs";

	exec(%newtwo);

so for every level.t2d file in my levels directory, I've got a level_db.cs file... and those are just declarations of datablocks.

The only things I keep in my datablocks.cs file are stuff that's everywhere in my game, like HUD bits. (if I wasn't lazy I could move those out too and clean up the editor a bit).

I can't remember at the moment if I had to make any other changes to the editor to get the datablocks to show up in the editor... but I don't think so.

Bend the editor to your will!

:)

-Tim

#10 That's an awesome tip, Tim! My current game handles datablocks differently, but I'm definitely marking this for future projects.

#11 Thanks William,

I don't know that I have a clue what I'm doing, but it also seems rather convenient for cleanup wherein I just scan through the file itself looking for "MapDataBlock(" or "AudioProfile(" in a given line, and deleting the resource upon leaving the level (assuming it isn't marked as persistent).

All of these things are fun, but I'd love to see a proper source-change that allowed for truly 'background' datablock loading as the OP requests... as in, even a single datablock, threaded to not lock the system while loading, with an update callback that you could track for your loading bar or other uses. I implemented a 'whole-datablock-at-a-time' callback for a loading bar in our last game, but there were pretty massive pauses when the big files came through (especially video/flash and sound).

#12 Tim, thanks for the great tip on modifying editor behavior. If I get to implementing the changes I will post a follow-up here.

Also, yes that is what I was talking about originally, a true threaded datablock loader that would run as a background task and not slow down the main game, and give you a callback when done.