Jump to content
  • Advertisement
Sign in to follow this  

Shared resources between different solutions (Music/graphics)

This topic is 727 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello there!


I'm currently still working on a game project which will be heavy on music, sounds, graphics, etc.


I've also created an editor which allows you to pick the music, sounds, graphics, etc, for each level.


Currently, however, both the editor AND the game solution contain some of the exact same resources, such as tilesets and MP3 files,

as the editor needs to show the creator how the level will "feel", and obviously the game project itself needs to contain these graphics

and sound resources.


I wondered whether it was possible to get both of these separate solutions to reference the same folder, ie: have one single folder

containing the game's soundtrack, which both of these separate solutions can access. I understand that the content pipeline in XNA

is responsible for all kinds of encoding malarkey, and it saves us a monumental amount of time, so trying to subvert the content pipeline

makes life more difficult. Is there a way to feed in a different directory to the content manager so that the music could be loaded from,

say, my desktop, for example?


I'm constantly moving the project around, either via the internet, USB, networks, etc, and all of these resources are the slowing factor,

as the solution itself is very lightweight. Any insight would be massively appreciated!



PS. It's also worth mentioning that it'd be nice to give players the freedom to be able to drag their own MP3s into a "soundtrack" folder

allowing them to change the soundtrack manually if desired.

Edited by zuhane

Share this post

Link to post
Share on other sites

Hi zuhane!

I pinned your topic in my browser but kind of forgot about it sry.

Long ago I used the XNA content pipeline as the de facto solution for handling my assets. Nowadays I manage it manually for various reasons so I can give you a tip for both workflows.

If you are using the content pipeline, use content project references just like how you would do it with code libraries, here is a project setup:

  +-* Code Reference: SharedCode
  +-* Content Reference: SharedContent
  +-- Game.cs

  +-* Code Reference: SharedCode
  +-* Content Reference: SharedContent
  +-- Editor.cs

  +-- SharedClass1.cs
  +-- SharedClass2.cs
  +-- SharedClass3.cs

  +-- SharedGraphics.png
  +-- SharedMetaData.xml
  +-- SharedSound.wav
  +-- SharedMusic.mp3

You can add content project references the same way as you add code libraries (e.g.: dll files) in visual studio, just right click on the referenced content projects of the given c# project and "add content references".

Now if you would like to minimize the amount of files copied you have to apply some "tricks" to the build process of your solutions and projects. Some of it can be done by simply editing the project preferences, like output folders, files to copy, when to copy etc...
For advanced goals and conditions you have to manually edit the msbuild xml tasks though (the .csproj files). This way you could build your project, so that with correct ordering you build the shared stuff once and output their resulting files to the correct target directory which is used by both the game and the editor application (one bunch of resulting xnb files shared by both applications).

Not using the XNA content pipeline is pretty similar project setup wise, though you will not have a "SharedContent" project (although it can be done with msbuild tricks but you have to leave visual studio when building as it does not fully support its capabilities). You have to add links to the same files (the shared content files) in both the game and the editor projects but this is just as possible to achieve (I'm using this approach for my current games). If you add the files to your project (by using "add existing items") you essentially "link" them to your project and can set them up to be copied on build to the target directory.

Now if you would like to use plain png, wav or wmv/mp3 files you have the following options to "bypass" the content pipeline:

These methods allow you to load multimedia data from files unprocessed by the build process of the XNA content pipeline, although there are two major inconveniences with this approach:

  1. You have to manually manage the life-time of these assets. The content manager class in XNA does this for you, but you are out of luck if you do not use it. Even though XNA being written in C# and the GC can take care about your allocations and unused objects, there is a huge native counterpart of the library (DirectX) and resources like textures and sound effects reserve a lot of native memory too. If you do not manually "Dispose" these resources when you release them, the native memory will not be released until the GC kicks in and the bad thing about this is that the GC does not take into account native memory to decide when it has to release unused memory, so you should be doing manual dispose immediately when releasing a resource!
  2. The content pipeline build process (what generates the xnb files) does a lot of clever processing/compression. This is especially true for textures, so expect longer load times when not using the content pipeline. The performance is not horrible or anything like that, but it is significantly slower to load a Texture2D from a vanilla png than from an xnb. The png format itself, as its name suggest, was developed with network/bandwidth in mind and not GPUs...

These limitations may sound daunting, but I shipped multiple games without using the built in content pipeline, so it is absolutely possible.
+ You can use a hybrid approach by preprocessing the assets/content you ship the game and editor with, and you use the content manager for handling those assets, but for mods and other user built content you allow to load textures/sounds/music from vanilla files.

This is not a big hustle just a little extra upfront work

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!