I'm not clear on what I need to do to use XNA instead of MDX. If there is a time to do it, I suppose right now is the time. Anyone have some pointers? I would prefer to use Microsoft Visual Studio 2005 for the development; my understanding is that there are betas of XNA Game Studio or whatever it's called, but it's not geared toward professional development. Does that matteR?

I just took a peek to see if there as any updates to XNA and Visual Studio compatibility, and it appears that XNA Game Studio now works with it. The older betas apparently only worked with Visual C# Express. So maybe it is time to jump ship to XNA... gonna read some FAQs first.

I am switching my efforts to this now. What swung my opinion around:

• XNA Game Studio 2.0 no longer requires Visual C# Express to run. It's final version supports Visual Studio 2005
• Lots of example code, and a surging community. MDX is pretty dead, as others have pointed out to me
• Support for the Autodesk FBX model format, which my modeler (Modo) can export directly
• A much simplified resource management approach in the framework, which you can just drop models and resources into named folders.
• It doesn't require DirectX 10 like I thought. DirectX 9.0c.
• The tutorial for displaying a model was very straightforward, and the sample game codes are far more complete.

I think this is going to be the new hotness. I might have to go buy an XBOX 360 and controller now, because you can target that and upload games you've written. That's pretty cool.

More XNA Experiences!

I've been working through the book I mentioned, "XNA Game Programming". This book is rated rather poorly (3 stars) on Amazon.com because the author pushes the idea of unit testing (which several reviewers found useless) and the book is not easy to follow code-wise unless you download the sample code. If you try to do the examples just by entering code from the book, they will not work unless you do a little extra digging. An experienced programmer will get around this, but I could see it being maddening. I have to say, though, that the process of working out what extra things you need to add (and he does mention what they often are in passing) does help tamp things home.

The chapters I've worked through are all the 2D examples, though I did just skim the last one. What I was hoping to get from a deliberate walkthrough the code by entering everything by hand was familiarity. I've seen a few new C# constructucts, and have been getting a feel for the major objects that are being used. I also have a better sense of the way that objects are invoked in XNA to do things, and this is useful for me. I've been noting down interesting objects in a Stickies notepad on my desktop.

Some interesting things learned:

• The XACT audio tool workflow. XNA deals with audio content by loading them as "soundbanks", so you need to create these with an external tool.

• Content Workflow. Everything in Game Studio has to be in the Content directory, which gets automatically compiled. I found that I had to manually-rebuild the project to get the Audio stuff to be compiled into binary soundbanks. It's a little weird feeling to me still, but that's OK.

• Input Systems. There are several high-level objects like GamePad, Keyboard, and Mouse, with many properties.

• Major Game objects: the Graphics object is the graphic device which does all rendering. There are some system timers that I should become familiar with, and the math libraries (particularly vector math) are things I'll have to absorb. Typing in the code manually has been good in helping me identity what is actually there from a fundamental perspective.

• Practices: The author goes ahead and uses floating point numbers to represent positions on the screen, which grants resolution independence. Since sprites don't have to be drawn on pixel boundaries and performance is basically a non-issue because everything is so fast. Boggles the mind, it does.

I'm now about dive

Regarding that book and XACT: I don't think he mentions that you need to call the Update() method for the XACT system in your render loop (in your Update(), preferably). Otherwise, you'll hemorrhage memory, unless this has changed in 2.0. I found XACT to be clear enough once I banged around with the tool for a while, but IMHO it's the least intuitive area of XNA.

Regarding sprites and math libraries: You should have fun ASAP with MathHelper.Lerp() and .SmoothStep()! Use the GameTime values coming into your Update() method to drive your interpolations. The vector classes have corresponding versions of the same methods. And, no, sprites aren't necessarily on pixel boundaries, since they're actually rendered to a single quad in 3-space. Aren't modern cards amazing?

Oooh, sounds cool! I haven't even really looked at the helper classes yet...thanks for the info!

I'm about to look again at shaders, now that I seem to have a better conceptual grasp of just what they are. For this project initially, I'm not going to worry too much about them and just implement something pretty basic, though it does seem very exciting.

I might as well write down what I am expecting to do tomorrow.

Write the 3D interactive shell in pseudo code. I might as well write a first pass at this...

Initialize() -- create all the various managers LoadContent() -- load specific content Update(), Draw() -- basically invoke other managers to do the updating and the drawing.

The first manager I need to write is a game state manager, which means I should create the game states. The code will be stub code for now (placeholder)

Some topics I need to research:

• Implementing a debug panel in XNA, or learning how to do remote debugging and debug tracing.
• Implementing text input, since I don't think this is included in XNA by default.
• Implementing some really simple windowing systems.
• Basic C# class declaration, types, and other sundry differences

Dave Seah - 22 January 2008 11:56 PM

Some topics I need to research: Implementing a debug panel in XNA, or learning how to do remote debugging and debug tracing. Implementing text input, since I don't think this is included in XNA by default. Implementing some really simple windowing systems. Basic C# class declaration, types, and other sundry differences

Keyboard input is easy to handle, just like mouse input; just get a KeyboardState struct off of the Keyboard singleton in your Update() method:

Using the Visual Studio remote debugger is pretty simple; just run the remote debugging service the same as you do with any other .NET project, attach to the machine, then select your process. Another method I find very useful is to use DebugView (http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx) to show all of your System.Diagnostics.Debug.WriteLine() output when you're not running from within a debugging environment. Old-school, but functional.

Thanks Bo!

Today I am mostly importing existing sample code from the XNA book, as a way of jumpstarting some of my architecture with working code. The code, however, is written for XNA 1.0. It took me a while to realize that though I could double-click the .sln file to load the project and make the necessary changes to get it to compile, the magic Content Pipeline build wasn't working. I had to create a new Windows 2.0 Game project, and re-import the model files so they would be automatically be built. But finally I am seeing them work.

There are several classes I'm going to steal...picking through them right now. Bwa ha ha!

Some of the 3D projection stuff is coming back, but I'm still working out the model import chain. I tried making some blocks in Modo, exported that as "building.fbx", added that to the Content directory in my project, and then attempted to load it in place of another model. This didn't work with the existing rendering chain in the sample code I'm using, as it uses a custom Effect.

From what I gather, FBX models do not carry the notion of having an "effect" assigned to meshes. If I was using BaseEffect, which simulates the fixed-function drawing pipeline, it would have drawn fine. I could modify the code here, but I should find out how to assign effects if I want to do fancy stuff later. The error I am getting right now is that the Effects collection in the mesh object is null. It looks like I have to apply the effect parameters using FX Composer 2, which I haven't yet installed.

I am not clear on how effects are linked to meshparts...do they refer to a specific named effect (compiled .fx files)? If FBX format does not include effect information, how do I add it on?

In the meantime, I might just convert the code to use BasicEffect to see how that works.

This article on rendering a model with a custom effect looks useful. It describes how to create a custom content importer to assign the effects properties, which could probably programatically extract the appropropriate effect name from metadata contained in the FBX file.

Yesterday I was looking into Effects in XNA, which are what actually does the drawing to the screen. An Effect is the compiled program that runs on the 3D graphics hardware, transforming the 3d vertex lists passed to it into rendered pixels on the screen.

So how are effects actually assigned to a mesh? I can create a mesh in Modo and export it as an FBX file, which can be directly read by XNA. However, the FBX format doesn't have the notion of an "effect assignment", so this information needs to be re-applied. The workflow for exporting a model with associated UVs and textures is a little foggy, so this is something I have to piece together.

In the easiest cast, the imported Mesh file will have the Effect parameters already embedded. The .X format supports this. However, the FBX format does not. In this case, we need to manually assign the effect at runtime, or parse another file to tell us what to apply.

In this somewhat murky article on using FX Composer 2 with XNA, the author uses nVidia's FX Composer 2 (FXC2) to do the Effect development and assignment visually. He imports the FBX file into FXC2 using the Project->Import function. However, FX Composer does not actually save this information back to the FBX file. His approach is instead to parse the FXC2 .dae project file (it is Collada, which is XML) and extract the pertinent information at runtime.

So the general approach we can take for now is to hardcode our effects assignment. Initially we'll just have a collection of standard objects, so we can create an external file that details what textures and effects need to be loaded, or we can develop our own parser as the author of that article did.

A closer look at the Mesh class should clear up what needs to be loaded. Since a Mesh consists of vertices with U/V coordinates on every vertex, that should be part of what is imported. Assigning a texture then consists of loading the correct bitmap (assigning it to the Texture property of a Mesh?)...I think. It's been a while since I've done any texture mapping in a 3D app...joy.

Some questions:

• How do you do just a basic texture-mapped object? That's all I need to know...I believe BasicEffect accomplishes this.
• Is the texture resource an effect parameter that is passed to the shader? I'd like to see an implementation of BasicEffect. Or perhaps I will find a shader tutorial somewhere.

I spent some time goofing around with BasicEffect to just get my own geometry to draw. I have to set up lighting and scenes now, to see what else BasicEffect can do.

The Content Loading process looks like this:

• Load Models
• Load Effects (or use BasicEffect) and compile 'em
• set up transformation, projection, and view matrices
• translate mesh data
• set an effect either in the graphics device and render vertices...OR
• set the effect parameter of a mesh object, and call mesh.draw(), which sets the effect for you

I think the next thing I need to do is just get some textured BasicEffect cubes rotating to learn about scene setup and light setup, and ensure that texture mapping and export from Modo is working properly.

Tonight's goal is to texture map a cube in Modo, then import it clean into my code. When that works, I'll have the basis for something that I can actually use to create the skeleton. Up to now, it's been slow going for me because I insist on reading and understanding fundamentals, and without direct visual feedback the brain is pretty sluggish. Attaining what I think is "deeper understanding" has always been a handicap for me in learning new systems rapidly. when a "just follow the steps" approach would yield results quicker. It pays off, though, in the long run with better and more maintainable code. Right now I am feeling fairly impatient with myself, though...

ANYWAY, I went through a bunch of Modo video tutorials to acquaint myself with where things are in the interface. The Modo written documentation isn't so good at this, surprisingly. There is always a kind of logic to a complex UI that should be revealed right away, and it baffles me that documentation never draws this out to use as a foundation for organizing the manual. Reinforcement helps! But I digress.

I went through the following orientations:

• basic view control
• basic editing/selection control
• UV unwrapping / texture mapping.

Modo has some nice "on screen" painting. What I really want to do, though, is to:

• make a nice cube with beveled (chamfered?) edges
• apply a texture to it
• apply the UV Unwrap to it to export the texture
• edit the texture in Photoshop
• export the model as FBX
• load the model and texture in XNA
• display it

I also want to look at the FBX file to get a better sense of what's in there, because I will have to write my own loader I suspect. Also, how it handles other kind of maps (bump, normal, etc).

Some Modo notes to myself:

To create the cube, I use the cube primative, and made it 500mm on a side (we'll see how scale translated into XNA later). I beveled the edges by going into EDGE SELECTION mode (key 2) and selected all edges. Then I chose BEVEL from the "Add Geometry" menu, and interactively dragged on the screen until I liked the way it looked. Adjusted roundness value. Checked in RENDER view, looks good.

Now, to add a material to it. I'm looking at the right side of the layout, under "Shader Tree". After pecking around to find some way of "editing a material" the way I understood it, I finally opened the MATERIAL EDITOR under the Texture menu.

But first, I need to do some "UV Unwrapping" so I have an image map that makes some sense. I put Modo into UV display mode, then picked "UV" from the sideways tabs on the right of the "Tools" tab. Then I started selected edges to help the UV Unwrapper create a clean map. The way it works is by clicking UNWRAP TOOL at the top, then clicking in the UV layout. Everything magically moves around. The whole paradigm of "select tool, then click in window" seems to be a Modo way of life.

So now I have some UVs mapped cleanly. The next step is to try the paint module to lay some color down. I believe I have to actually create a material image bitmap first.

I went to the shader tree on the right panel, and chose "add layer" and then "image map", followed by "new image map". The dialog box is a bit misleading at first, but it's mostly me being dense. Upon choosing "new image", i'm prompted for a place to store it and a file type. It defaults to TGA, the ancient Targa format. I'm going to use PNG, because this is supported both by the XNA content importer AND it's easier to preview in Windows. I was prompted for a resolution, and I chose 512x512 pixels...plenty big. I had the choice of saving the format as floating point values (intriguing, didn't know this was part of the PNG spec).

I'll worry about texture optimization later (there is some tool that does this to convert to "dds" format I believe).

Since I am just painting color, I named the map "SimpleCubeDiffuse" (diffuse being the standard term for this). I see in the ShaderTree that my Image has been added, and the "Effect" being applied is "Diffuse Color". It is gratifying to see that if I right click the Diffuse Color setting, I can choose the type of Image Map it is...displacement, specular, normal, etc. This will probably come in handy later. In the meantime I'm not worrying about it.

Hm, the painting module doesn't quite work the way I expected, but I did texture the cube with some labels. Let's take a look at the image map now in Photoshop...hmm, it's empty after painting everything. When I save the scene, the diffuse map is updated, but I'm not seeing the PNG file get updated. Hmmm. Time to do a little more digging.