Jump to content
  • Advertisement
Sign in to follow this  
sonicbhoc

Loading data once and using it multiple times

This topic is 3725 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey, I am wondering about loading data once and using it multiple times in the code. I see a lot of threads about "resource managers" but from what I read, I don't want a resource manager, but a resource pool. Still not to sure what the difference is. I'm trying to make a basic shoot-em-up game (as in shmups and STGs, not first-person or third-person shooters; mention Halo and I'll kick you) for my first game in C++ and OpenGL(I have tried it before in Python+Pygame, actually, and came quite close to succeeding, but I ran into a few problems with firing bullets and time constraints). Anywho, I want to load the frequently used textures into memory at start, and then only have to load level-specific textures when needed (seeing as the majority of the game will probably use the same textures pretty much everywhere but the backgrounds and maybe a few different-looking bullets for different bosses) so that: 1. I don't have to load the textures every time a level is created 2. Not as much accessing the disk 3. It's faster than accessing the disk every time a texture needs to be loaded 4. Much less loading time, if any, between levels So, how would I go about doing that?

Share this post


Link to post
Share on other sites
Advertisement
In a school project, I also needed something similar. My proposition is to design a simple HashMap of Singleton 3D-objects. Something like a registry.

[Edited by - grnemo on June 7, 2008 10:23:48 AM]

Share this post


Link to post
Share on other sites
I think something like this could be done quite easily with the kind of resource pool I use. Here's how it works:

- The resource pool maintains all resources in a dictionary with the key being the file name (relative to the content directory) and the value being a weak pointer to a struct that contains meta-data and a pointer to the actual resource (there's some magic going on here, but it doesn't really matter for what you're trying to do)
- The resource pool also has a list of loaders that implement a common interface. These loaders do the actual loading and they also provide a method GetPlaceholder which returns a dummy resource (I use this for asynchronous loading)
- When you need to load a resource, you do something like this:

Resource<Mesh> mesh = content.Load<Mesh>("meshes/car.mesh", LOAD_ASYNC);

Now the interesting thing here is that a) the Resource class is actually a reference counted smart pointer and b) the Load method does not load the resource right away, but adds it to a load-queue ("mesh" can immediately be used as if it was an actual mesh resource though, thanks to the GetPlaceholder method mentioned earlier).

Here's how this could apply to your situation: you could simply load all levels when your game starts. This will fill up the load-queue and for resources that are shared by several levels, it will give you a reference count > 1. You can then choose to load these resources right away while keeping the other resources in the queue and loading them when they're used for the first time.

Hope that made sense

Share this post


Link to post
Share on other sites
I answered a similar question recently.

Essentially you maintain a pool of texture objects; new texture objects are created with a factory method and inserted into that pool. Texture objects are retrieved from the pool via an associated key which would probably be a string representing the file path of the texture.

You might consider loading all your commonly used textures into one manager/cache/pool and loading all your level-specific textures into another, separate, manager/cache/pool. Of course, if you use singletons this solution is not available to you - don't use singletons [smile].

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!