Resource Manager v2

Sorry, no new binary release. The last one can be found here.Sorry, no new source release. The last one can be found here.

Today is going to be all about the resource-manager. The resource-manager is basically the debug window we can open during test-runs of the game. We want to improve it by being more informative to help us locate bugs. Not just for debugging though, also for rapid development, but you get the picture.

Showing thousands of controls

Hmm that paragraph-title sounds very ominous. Usually it is a bad idea to show thousands of user-controls, but I need my resource-manager working optimally when lots and lots of objects are loaded. Even when there are just 100 loaded resources, I don't want to load those controls in a windows-form for performance reasons (with each control having their own handles). This is only an issue when the resource-manager is open obviously, which is only true during development tests, but still. Usually showing this many controls is just not possible, but these are the three most common solutions:

  1. Using GDI to draw everything manually.
    Sometimes this is a viable option. But when you want to make use of normal controls with automatic layout this is not a good option.
  2. Redesigning the GUI so no such amount of controls can exist.
    Usually the best option, but sometimes we just don't have this option.
  3. Pooling user-controls and manually handle scrollbar events.
    When we are able to know the height of the controls we will display, show only those controls that are supposed to be visible according a scrollbar-value.

I have chosen option 3 because I want to have normal user-controls, vertically stack these controls and I can sort-of known the height of the controls (even when they are a bit dynamic in height). For this to work I need to create a container-control that efficiently shows thousands of controls and is still efficient when removing random elements from the collection. I searched the internet for, like, a whole 10 minutes and could not find anything decent. Ten minutes are like an eternity man! Well okay, programming it myself took a lit bit longer than 10 minutes, but it didn't feel like it. So without further ado, this was my test (click for bigger image):

 thousandsofcontrols visualstudio-designcontrol

Yay! thousands and thousands of controls and everything works smooth, even deleting controls is quick. Whoohoow! The controls used, can still be created using the designer, exactly what I wanted. The vertical scroll container calculates the height as follows:

  • When the first element is added, create the control and check its height. Let's say the height was 150 pixels.
  • Look at the data that is bound to the control and get its 'DynamicHeight' property. In our case this is just the height of the image. Let's say this value is 90 pixels.
  • The difference 150-90=60, is the additional height that we need for each control besides the 'DynamicHeight' property of the data.

So when more data is added, we don't need to create the controls to know what height they will have. We do need to be careful though; we can't allow the text of the name-label to wrap, because that might generate more height that our container does not know about.


Audio is now also managed through the engine. It still uses XNA and XACT, but all fancy techniques like cross-fading and automatic management with reference-count's are now easy as pie. Hopefully this will also help when trying to identify weird sounds coming from the game.


In theory, 3D-sound should be possible, but more testing (and adding feedback in the resources-GUI) should be added if and when we're actually going to use it.

Render Targets

Whenever fancy shaders are used to make things look really pretty, additional render targets are introduced to contain information used to draw the final scene. Software engineers try to use as small and as few render targets as possible and even try to reuse render targets for different techniques whenever possible. Debugging video-card resources is a pain in the buttocks as I came to realize doing that fluid-simulation. Can you imagine doing fancy stuff with lighting and reflection without good feedback what the shader is actually doing? A horrifying thought! A giant infected hemorrhoid would be less pain... presumably... :) Hmm can a hemorrhoid itself get infected? Let me google.... O ... MY ... GOD ... Well I'm still not sure, I mean, are ..., the.., my..., I mean...,

Anyhoo, since I'll be skipping my lunch break, let's continue.

We can now see the render-targets in the Resource Manager so no need to second guess what the shader is doing. Yay, so professional 😀


We fixed some of the obvious flaws for the fluid-shader so it works a bit better with the Reach-profile, but it is still bugged. There is no intention to fix it (yet), as we are probably not going to use it in the near future.

Other debug info

Hmm I also have other debug-information, not just resources. Let's just move resources to a tab of its own so we can show this information. This will also remove a lot of clutter from the screen.



We also added a "States" tab, but that one is not showing much information right now. Maybe, just maybe, when I'm in a good mood, I'll implement something to show the tree-structure of the world-state and the render-states. It would be very nice, but it's a lot of work for something that I don't really need myself. But do not despair, I'll probably introduce some stupid bug somewhere for which it becomes very handy to visualize the tree, at which point I'll implement it anyways.

Next Time

Now I'm really, really hungy. Wait, did I skip lunch? Oh crap, I remember. Okay, food can wait. Next time I'll be.... hmmm, I don't know... can't think strait right now. Ah well, it'll be a suprise.

ExtrapolationGame Libraries