Hi everyone! I haven't posted in a while...
1. Don't tie your loading to framerate.
If you make an animated loading screen, don't sync after each and every item is loaded. Otherwise loading is capped at frames per second.
Keep track of the Timer() and use an If statement to skip SYNC if too little time has passed.
This can be a massive load time improvement.
I normally load about 1000 objects into a level. Many of these objects are supremely quick to load and many times the object list has empty sections in it too. I was using SYNC after each. I made this tiny little change and cut 95% of the load time, minutes to mere seconds.
2. Proper Asset Management
The art of skipping what you don't need to load, and doing it automatically.
Quote: "Jeff Miller: Back to your original question on conserving loading time, I recall that a previously active forum member (Cash Curtis) was working on ways to reduce time spent in loading textures and reported the following. He had several objects that used the same texture, and as each object was loaded DBP would load the very same texture again and again. I think his solution was to save out the objects without the reference to the texture, load them in bare, load the texture image ONCE, and apply the texture to the various objects within DBP. "
Yes this is where proper planning and large scale programming structure come into play.
I always load objects and texture separately. I understand that some people encode texture paths into objects and get the textures to load automatically when loading the object. I never do this. Less control. Less versatility. Harder to read.
Dark Basic Professional doesn't really give you good management tools for detecting whether an image has been loaded, let alone what the image number would be.
So you really need to make a rudimentary game engine for yourself -so to speak-. Write wrapper functions for the Load Image, Delete Image commands (and possibly for object commands too) and create a management system yourself. Generalized functionality to enhance DBP that could be dropped into any program.
Store an automated list of loaded assets, their path names, their indexes, and a counter for usage tracking. I mean create functions that are wrappers for Load Object and Load Image. You call these functions instead of directly using the commands. These functions are then able to essentially intercept your load request. They can return an object/image number that they find already loaded from a master list or they can load your image/object and store the details like path name and index so the loaded asset is "on record". Then increment that assets counter to track how many active uses there are.
Of course then a wrapper for delete object/image would delete the image/object and remove it from the master record of loaded assets. I mentioned storing a master list of assets, with a usage counter. This is because if you are deleting an image and the counter reaches 0, you know nothing else is using the image and that it can actually be deleted from memory.
You can create specialty functions for ensuring you load an asset that isn't shared if need be. It's your management system.
You also don't decide what an image/object number will be. Let your management system find and select unused ones on it's own and handle that business for you. When you call the wrapper function to load an image it returns an image number for you to use. All the complicated bits are handled by the automated system.
A system like this also allows built-in error protection. Your management system can check for problems. If you supply a bad file path for example, loading an image can then return a 0 index. You can then handle the error rather than the entire program crashing to desktop.
All in all I have found that this kind of asset management is most effective with images. Objects aren't quite as able to be shared around like images and often need to be separately loaded.
I could go into more detail, there's some more advanced stuff you can do with this and describing all of this with so few words is tough. Suffice to say I was able to reduce my memory footprint by about 75% which is a lot when you are approaching 2GB.
3. Proper Asset Management Leads To Screen Loss Recovery Capability.
Because you are now completely managing your loaded assets, when the screen device is lost, and all your assets are flushed from memory, you can easily load them back into memory in an automated process.
This is essential for a large scale program where hundreds of objects may be active in the game.
You will need to also look into how to detect and recover from screen loss issues to do this.
Screen Loss Recovery Examples Here:
http://forum.thegamecreators.com/?m=forum_view&t=202959&b=1
