Sorry your browser is not supported!

Just had some thoughts about better ways of handling media, and here's my idea of a basic media management system:

Media loading is entirely up to the engine, the programmer just requests media and stores a handle to it, like so:



If the media requested is already loaded, a handle to the existing resource is returned. Naturally it will be desirable to be able to ask for a copy to be made, in the case of when a programmer wants to alter media on-the-fly.

Media can be precached, meaning any media in the precache list will be loaded when the application starts. When media isn't precached, it'll be loaded on-the-fly.

Media can be loaded in the background, similar to precaching although it happens over time. In order to accomplish this, the engine precaches a low-quality version of all the media when the application starts (this is meant to be very fast), allowing the game to use and display the media until a higher quality version is loaded, which will replace the resource automatically. If a low quality version isn't available or the programmer explicitly wants the media to be loaded at that time (in order to use it immediately), the application will pause while it loads it.

Such a system would eliminate the need to keep track of certain resources that would usually be copied manually (via clone object for meshes, for example) for optimization, as well as allowing the background-loading system to be implemented.

Thoughts?

Or copied on demand - initial loaded copy is readonly, and when accessing it normally, the media handles would use that resource. However, when you modify via the handle, the command/function would immediately create it's own copy and carry out the amendment there.

Basically (C)opy (O)n (W)rite, or COW - it's used in most C++ std::string implementations, but there are problems with it when multithreading. If the AppGameKit doesn't allow threading, then COW in this context is perfectly fine.

I basically agree, although not knowing how the executables will be packaged, we might find that this is totally unnecessary - if the media is packaged into the exe and loaded directly, ie not from the filesystem, then you already have it loaded and accessible.

Good thinking.

We're opting for a traditional model of allowing the coder to decide whether to load their media during an initial step or code to do this during the main loop. It's simpler for us, and makes it easier to know what's going on. Streaming in media in the background might have some very subtle and mysterious side effects. I remember playing with an early version of 'wildtangent' which did something like this, and I still recall the apps completely devoid of graphics or geometry but still let you play it while it streamed slowly in the background We're not ruling it out by any means, but stage one will be something more simplistic and transparent (i.e. if you load it, it will be loaded)