Subscribe

RSS Feed (xml)

Powered By

Powered by Blogger

Google
 
xnahelp.blogspot.com

Jumat, 04 April 2008

Using the Skybox

We have gone through a lot of work, but we are almost done. All we need to do now is
actually use this Skybox object inside of our game. Let’s open the Game1.cs file and add
this private member field:
private Skybox skybox;
Now we need to add a skybox texture to our content folder. Let’s create another subfolder
under Content and call it Skyboxes. This is not required but it might be helpful to remind
us to change the processor type, which we will see how to do shortly. For now, we need
to actually add an image to this Skyboxes subfolder. We can find one on this book’s CD
under the Load3DObject\Content\Skyboxes\skybox.tga inside of the Chapter 8 source
code folder. Copy this texture and paste it into the Skyboxes folder through Solution
Explorer. Inside of the properties window we need to tell XNA Game Studio Express
165
8
LISTING 8.4 Continued
Using the Skybox
which importer and processor we want it to use when loading this content. We will leave
the importer alone as it is defaulted to Texture – XNA Framework. See the sidebar
“Creating a Custom Content Pipeline Importer.”
We will change the Content Processor property, but before we do we need to tell our
project that there is a custom processor of which it needs to be aware. We do this by
double-clicking the Properties tree node under our game projects. Inside of our project
properties we can open the last tab on the bottom: Content Pipeline. We can click Add
and browse to our pipeline project, then add the assembly in the bin folder.
We will add this exact same assembly (under the x86 subfolder) to our Xbox 360 game
project as well. This is because the assembly is only run on our PC when we are actually
building our project. However, we do need to make sure that our XELibrary_Xbox360
assembly has the same name as our Windows assembly. This is important because we
have told the SkyboxWriter where to find the Skybox type and the SkyboxReader object.
We told it XELibrary, not XELibrary_Xbox360.
Alternatively, we could have left the assembly names different and added a condition to
our GetRuntimeReader method in our SkyboxCompiler class. We could have returned a
different string depending on the target platform that is passed into that method.
Now that we have added our Content Pipeline extension to our game projects we can
select SkyboxProcessor from the list of content processors that are available in the property
window when we have our skybox texture selected.
CREATING A CUSTOM CONTENT PIPELINE IMPORTER
An example of setting up a custom importer is the following code:
[ContentImporterAttribute(“.ext”, DefaultProcessor = “SomeCustomProcessor”)]
public class CustomImporter : ContentImporter
{
public override CustomType Import(string filename,
ContentImporterContext context)
{
byte[] data = File.ReadAllBytes(filename);
return (new CustomType(data));
}
}
This code is a theoretical importer that would be inside of the pipeline project if we
needed to import a type of file that the Content Pipeline could not handle. We could
open up the file that was being loaded by the Content Pipeline and extract the data to
our CustomType that could handle the data. This CustomType would also be used as
the input inside of our processor object (where we used Texture2DContent). The
reason we did not make our own importer is because the XNA Framework’ s Content
Pipeline can handle texture files automatically.
166 CHAPTER 8 Extending the Content Pipeline
We are finally ready to run our game. We should see a star-filled background instead of
our typical CornflowerBlue background. We have successfully built a Content Pipeline
extension that takes a texture file and creates a skybox for us automatically. There is no
limit to the things we can accomplish because of the Content Pipeline’s opened architecture.
We could create a level editor and save it in any format and load it in at compile
time to our game. We could write an importer for our favorite 3D model file type and
work directly with the files. There are many opportunities to use the Content Pipeline.
Whenever we can take a hit up front at build time instead of runtime is always a good
thing.

Debugging the Content Pipeline Extension
Extending the pipeline is excellent, but what happens when something goes awry? We
cannot exactly step through the code because this is a component being loaded and run
by the IDE … or can we? Fortunately, we can. We discuss how to do that in this section.
If we have the SkyboxPipeline solution opened, we can close it and then add the project
to our Load3DDemo solution. This is not required to debug, but it can make it easier to
make sure the IDE is using the latest changes to the pipeline processor. Alternatively, we
could compile and change the stand-alone SkyboxPipeline solution and then compile the
Load3DDemo. Again, it really is just personal preference.
The goal is to make sure our SkyboxPipeline code gets compiled before our game code. To
do this we can either add the dependency directly to our game code or we can add it to
our XELibrary knowing that our game code already has a dependency on the XELibrary.
We can right-click our XELibrary projects (one at a time) and select Project Dependencies.
We can then add the check box to our SkyboxPipeline project. From now on, when we
compile, the solution will compile the SkyboxPipeline first, followed by the XELibrary
and finally compile our Load3DObject project.
Now that the SkyboxPipeline project is open, we can add the following line of code at the
top of the Process method inside of our SkyboxProcessor class:
System.Diagnostics.Debugger.Launch();
This will actually launch the debugger so we can step through the code to see what is
happening. If we run our program with this line of coded added, the CLR debugger will
get executed. We can then walk through the code like any other. We cannot edit and
continue just like we cannot do that on the Xbox 360. Regardless, being able to step
through the code at runtime is very beneficial. We can set break points wherever we need
to. This is an excellent way to visualize exactly which pieces of code are calling other
pieces and see the general flow of the Content Pipeline.

0 komentar: