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

Posts I've Made

In Topic: FMOD API

08 July 2013 - 01:56 PM

Thanks for the replies!


I've been through adding a C++ library to a C program, and incomplete types are very useful in this situation. The C header may have its functions implemented in a C++ file, and that incomplete C struct could contain a C++ object inside, wherever it is actually defined. Or, they might never define it, and just force cast the pointer to whatever they use internally.


Yep - that seems to be what they're doing. I can't tell whether they use a C++ object internally or it really is implemented in C. I guess they could have done this for compatibility reasons. They actually define the C++ factory function to call the C function below. Although FMOD_SYSTEM is an incomplete struct type.

inline FMOD_RESULT System_Create(System **system) { return FMOD_System_Create((FMOD_SYSTEM **)system); }

Are you using the official FMOD SDK?  The Windows version contains .c and .cpp files for both C and C++ respectively which are both in the same folder for all the individual project files.  In the SDK version that I have there is only C code in the .c file and the headers included both have .h extensions.


I have the public SDK, which doesn't include the source code.


Is there any advantage to implementing a library like this using a C API, and then adding non-virtual C++ wrappers? I can't imagine many people want to use the C API, although I could be wrong. Possibly performance?



In Topic: XNA Render Targets

21 January 2013 - 01:59 PM

Exactly what I was looking for, thanks very much!

In Topic: XNA Render Targets

21 January 2013 - 08:02 AM

Thanks for the quick reply!


Just to clarify - are depth/stencil buffers shared in any way in EDRAM? For example, if I create a second render target with a depth/stencil attached, is this depth buffer a separate area of memory or is it shared with the backbuffer's depth?


I'm trying to avoid tiling so it would be useful to know how much EDRAM I'm using.


Thanks again.

In Topic: When to use multi-threading and when to not

24 August 2012 - 04:21 PM

There was a thread about this recently. The general wisdom seems to be that you should only use multiple threads if your game has been programmed sensibly, but still can't achieve interactive frame rates on a single thread.

Often the APIs you're using will use multiple threads internally, such as the FMOD sound system. There's no need to do it yourself.

If disk I/O is a problem, it's easier to use the asynchronous I/O provided by the operating system rather than multiple threads. If data processing is the bottleneck, it's probably better to process your data files offline and have the game read simpler binary structures from disk.

Hope that helps.

[Edit] The earlier thread (no pun intended) is here.

In Topic: Asynchronous Loading - Dependencies?

23 August 2012 - 11:59 AM

Ah thanks, that's a good idea. I'll go for that.

To add to this - I might try out a slightly different idea along with that.

My assets currently have a 'state' enum specifying whether they are loaded, pending, or encountered an error. This implies, although I hadn't previously realised, that it is valid for an asset to exist in the cache without being loaded - there are no null pointers, just empty handles.

So I can begin by loading up all the assets in bulk, in the correct order.

When a material is loaded it can kick off jobs to load any missing shader and texture dependencies if needed, get back the 'pending' handles, and then forget about them. There's only a small handful of code which actually cares whether an asset is loaded or not - so I can manually check there, which will only be the cost of testing the state enum. If the asset isn't loaded I can ignore the operation and/or return null, false or whatever - and log the problem.

I can imagine this being very useful - for example, if you start the game with a vertex shader file missing, the objects using that shader just won't draw because the asset will be marked with an error state. This would also be useful with asset swapping at runtime. If an asset change is picked up but fails to load, the objects just stop being drawn or the sound stops playing, and a warning is written to the log.

Thanks for all your help. I'll try down this path for a while and see what happens :)