Ok, the title of this post is almost misleading, this is more about the correction of some features that were slightly flawed in their design which have now been corrected. So I'm going to talk a little about it.
RuneEngine V2 has had a feature since the beginning referred to as a content reference system. The idea and purpose of this system is to be able to dynamically load content and handle such implementation as transparently as possible. Sadly, it only truly came to my attention last night it was not serving it's full purpose. It wasn't exactly wrong.. but it was defeating it's purpose in existing with the existing implementation.
Now some MAJOR changes were made, everything from the outside looks almost the same, except it is a little easier to use now. I should be taking that another notch further, but that's a completely different talk. So, what was changed? Here's a basic list from the far back perspective:
Removed--
IMaterialReference
IPostShaderReference
MaterialReferenceObject
PostShaderReferenceObject
MultimapTextureReferenceObject (rebuilt to interact with the TextureReferenceObject instead of separate)
Added--
IShaderReference (new material reference, but also serves as post shader reference)
RenderTargetReferenceObject( it was missing )
IContentContainer (this guy... does magic)
ShaderReferenceObject
Ok, that's about it. As you can see it's a pretty even exchange, but the added were completely missing or are more of a rename. The multimap texture reference and texture reference objects were completely unnecessary to be separate, I may have to do some wiggling to make it work, but it is done. Material references and post shading references were extremely redundant hence the spark to make these changes. In the process is how I found the issues.
IContentContainer was added to resolve the biggest of the issues as well as add a few functionalities that really make this feature sing. The issue was, the reference objects were calling load methods on instantiation in most cases, and if they didn't. The components were. Why not use a normal load call if I'm not going to use these for what they were added for right? So, first I stripped all calls that forced loading of the content references, then looked closely at what was missing. IContentContainer was what I came up with. This interface defines a collection of callbacks that the IContentReference objects call when they are loaded or unloaded. It has a method for making sure the reference is associated. That sort of thing.
One interface all it really took? Not a chance! Now, the IContentReference interface also has some added methods for working with the IContentContainer. Also, RuneContentManager was extended and improved to work more closely with this new interface as well.
So, rather than being super abstract about what happens let me just explain a few scenarios and how these changes have impacted them.
Scenario #1:
I'm building a game where the scene is rather simple, but the Content takes a long time to load. I do not want to make a super long load time when a level is loaded. But, I'm afraid to preload the content bogging down the CPU in the main menu. In this case I can preload the Scene files but not the content. Once the level is selected we can prioritize required content loading it first allowing the level to start with partial content and potentially even a partial scene. The reference objects allow this separation of load times, but not in a way that is forced by the engine. You can load it whenever you please.
Scenario #2:
I have a large collection of global resources that need to be loaded. I can put them in a global RuneContentManager and link it to my SceneGraphs allow the components to search through it's content as well. I can load all these global content items at startup, background or load screen. And pull them using the RuneContentManager linking systems. The amazing part here is that the contentReferences will manage unloading and reloading of those assets individually if they're not really being used. Also, the ContentReferences will pull more directly from the contentManagers now than before.
Scenario #3:
I'm building an Elder Scrolls Clone.... GG! The newest implementations actually allow full user control over when content is loaded and the IContentReference objects do all the tricky stuff. You can load a resource in anyway RuneEngine allows and the components and the IContentReferences will receive that callback letting all places that need to know, know that the resource is available and can be used now. No periodic or frame by frame update required. All of this leading to a fully seamless platform capability in a very simple way at that.
TextureContentComponent.AssetName = "assetName";
RuneContentManager.Load( "assetName" );
Done.. This like much of RuneEngine, is order independent. RuneEngine is unique in this element that I've spent a lot of time working around pre-requisite type issues. The game will not fail when resources are missing it'll just respond to it internally or with user defined code. Components can be added in any order. SceneNodes can be activated before or after components are added, it doesn't matter. The only real prequisite to any of RuneEngine is this line:
RuneManagementService.Startup();
I'm extremely enthusiastic lately watching all of these architectural designs in the engine being realized. So pardon me if I seem ranty.
Anyways, happy coding.
No comments:
Post a Comment