Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 23 Dec 2004
Offline Last Active Jul 08 2013 05:17 PM

Topics I've Started


07 July 2013 - 01:54 PM



I've recently taken a look at the FMOD API and I've noticed that it appears to be a C API, with a really thin C++ wrapper. I'm interested in understanding how they've implemented it.


The C++ classes in the header have no virtual methods or destructor, so they're not inheriting from these classes. Which makes me think that a member function like the following is implemented by just calling the equivalent C function:

FMOD_RESULT System::createSound(...)
  return FMOD_System_CreateSound(this, ...);

That C function takes a pointer to an FMOD_SYSTEM, which is declared like this:


Which makes no sense to me. What does typedef'ing like this do, when FMOD_SYSTEM is undeclared? And how can the C function take an FMOD_SYSTEM parameter, but they must be passing a pointer to an FMOD::System class?


Many thanks!

XNA Render Targets

21 January 2013 - 07:05 AM


I've just switched to XNA, and I had a couple of questions I was hoping someone can help with :)

Could anyone explain the relationship between eDRAM and render targets on the Xbox 360? Each render target must have some VRAM assigned for the texture data. When you bind a render target with DiscardContents, this texture isn't copied into eDRAM (since this would be slow?) but the texture data is cleared to purple to show this. I guess PreserveContents would cause the texture to be copied, although this would probably be very slow.

Is this correct? At what point is the render target in eDRAM copied back to the texture store in VRAM?

Also, could anyone tell me how depth/stencil buffers are handled on the 360? If I create a render target with a depth buffer attached, where does the buffer live? Does it have a backing store in VRAM?

Thanks for any help!


Test Driven Development.. Examples?

11 January 2013 - 11:54 AM


I recently read about Test Driven Development, and I thought I'd give it a try. I've had some trouble finding meaningful test examples, and I was hoping someone could point me in the right direction with two simple interfaces from my current project.
// This interface is used to convert string identifiers to faster string IDs.
typedef unsigned int StringId;

StringId hashString(const std::string& str);
I should probably create two tests for this using known string IDs - perhaps one for an empty string, and one non-zero length known value?
// This interface is used to load game assets asynchronously.
class AssetLoadJob;

class AssetLoadThread : private boost::noncopyable
   void submitJob(AssetLoadJob *loadJob);
I'm not sure about this one. It might be an idea to use three tests - a valid job, an invalid job and a null pointer (which should trigger an assertion)?

Hopefully if I can get the feel for it using simpler interfaces, I'll have a chance of writing decent tests for the more complex ones. I know it takes enough time to write _your own_ tests, so any insight here would really be appreciated :)

Many thanks.

Organizing Assets

06 October 2012 - 06:35 AM


I'm using a package file format to group assets together on disk, and I've been thinking about how to organize the various packages. I've come up with two ways of doing this, and I was hoping someone can suggest one over the other.

The first is to divide assets into actor packages and level packages. The assets for each actor can be compiled into separate packages, as they generally need to be loaded together. Each level (which references the actors it needs) can then also be put into it's own package, along with any 'per-level' assets (skyboxes come to mind). Shader programs are shared widely between actors (and even the GUI) and would probably needs to be bundled in their own package.


The second is to divide assets into packages by type, e.g. Textures.pkg and Shaders.pkg. I could then use the game logs to (automatically) re-order the package contents in the order they will be loaded. A problem here might be that the game doesn't load in this way, by batches according to the asset type.


Any thoughts would be greatly appreciated!


Asynchronous Loading - Dependencies?

22 August 2012 - 10:13 AM


I posted a question about asynchronous resource loading previously, and got some really useful replies. I've run into a problem with resource dependencies, and I was hoping to see what others think.

My original system had several resource types, and some were dependent on others - for example, a Shader resource is dependent on a VertexShader and FragmentShader, and a Material is dependent on a Shader.

I solved this by providing the loaders access to caches of the dependent resources, which works fine when everything is synchronous:

ResourceLoader<Shader> shaderLoader;
ResourceCache<Shader> shaderCache(&shaderLoader);

// Allow the material loader to resolve shader references:
ResourceLoader<Material> materialLoader(&shaderCache);

// Now a material request will automatically load the shader if necessary.
ResourceCache<Material> materialCache(&materialLoader);
MaterialPtr material = materialCache.get("test.mat");

With asynchronous loading this isn't so straightforward. A material will be loaded and asynchronously load its dependent shader, but the shader won't be loaded right away and might even encounter an error - making the material invalid.

I could design some complicated dependency system, but I'm hoping there is a simpler way. Does anyone have any suggestions to point me in the right direction?

Many thanks!